[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CY2QYAT8NZ28SPC93KB8AE":3,"skill-same:01M6CY2QYAT8NZ28SPC93KB8AE":51},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":13,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":37,"install":38,"resources":50},"01M6CY2QYAT8NZ28SPC93KB8AE","compound-refresh",null,"Refresh stale or drifting learnings and pattern docs in docs\u002Fsolutions\u002F against the current codebase","The-Rabak\u002Fcompound-engineering-plugin","The-Rabak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44833742?v=4","01M6CY211HB58Y8JNWWEV9FGN1","01M6CY2165MYWKS66VN01X82EB",1,"MIT","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fcompound-refresh\u002FSKILL.md",[],[18,19,20,21,22,23,24],"refresh","compound","compound refresh","docs","stale","learnings","pattern","2026-11-10 10:12:30",false,"---\nname: compound-refresh\ndescription: Refresh stale or drifting learnings and pattern docs in docs\u002Fsolutions\u002F against the current codebase\nmodel: claude-sonnet-5\ndisable-model-invocation: true\n---\n\n# Compound Refresh\n\nMaintain the quality of `docs\u002Fsolutions\u002F` over time. Review existing learnings against the current codebase, then refresh any derived pattern docs that depend on them.\n\n## Mode Detection\n\nCheck if `$ARGUMENTS` contains `mode:autonomous`. If present, strip it from arguments and run in **autonomous mode**.\n\n| Mode | When | Behavior |\n|------|------|----------|\n| **Interactive** (default) | User is present and can answer questions | Ask for decisions on ambiguous cases and confirm disruptive actions |\n| **Autonomous** | `mode:autonomous` in arguments | No user interaction. Apply unambiguous actions, mark ambiguous cases stale, and generate a full report |\n\n### Autonomous mode rules\n\n- Skip all user questions.\n- Process all docs in scope. If no scope hint was provided, process everything.\n- Attempt all safe actions: Keep, Update, auto-Archive, and Replace when evidence is sufficient.\n- If a write succeeds, record it as **applied**.\n- If a write fails, record it as **recommended** in the report and continue.\n- If classification is genuinely ambiguous, mark the doc stale with `status: stale`, `stale_reason`, and `stale_date`.\n- Use conservative confidence. Borderline cases become stale in autonomous mode.\n- Always generate a report with **Applied** and **Recommended** sections.\n\n## Local Grounding\n\nBefore editing anything under `docs\u002Fsolutions\u002F`, read the local guidance files in this order:\n1. `AGENTS.md`\n2. `CLAUDE.md` (if present)\n3. `README.md`\n\nUse them to preserve the repository's docs conventions, OpenViking guidance, and workflow naming.\n\n## Interaction Principles\n\nThese principles apply to interactive mode only. In autonomous mode, skip all user questions and apply the autonomous rules above.\n\nFollow the same interaction style as `\u002Fworkflows:brainstorm`:\n- ask questions one at a time\n- prefer multiple choice when natural options exist\n- start with scope and intent, then narrow only when needed\n- do not ask the user to decide before you have evidence\n- lead with a recommendation and explain it briefly\n\nThe goal is to help the user make a good maintenance decision with minimal friction.\n\n## Refresh Order\n\nRefresh in this order:\n1. review the relevant individual learning docs first\n2. note which learnings stayed valid, were updated, were replaced, or were archived\n3. then review any pattern docs that depend on those learnings\n\nWhy this order:\n- learning docs are the primary evidence\n- pattern docs are derived from one or more learnings\n- stale learnings can make a pattern look more valid than it really is\n\nIf the user starts by naming a pattern doc, you may begin there to understand the concern, but inspect the supporting learning docs before changing the pattern.\n\n## Maintenance Model\n\nFor each candidate artifact, classify it into one of four outcomes:\n\n| Outcome | Meaning | Default action |\n|---------|---------|----------------|\n| **Keep** | Still accurate and still useful | No file edit by default; report that it remains trustworthy |\n| **Update** | Core solution is still correct, but references drifted | Apply evidence-backed in-place edits |\n| **Replace** | The old artifact is now misleading, but there is a known better replacement | Create a trustworthy successor, then archive or supersede the old artifact |\n| **Archive** | No longer useful or applicable | Move the obsolete artifact to `docs\u002Fsolutions\u002F_archived\u002F` with archive metadata |\n\n## Core Rules\n\n1. **Evidence informs judgment.** Use engineering judgment; do not treat this as a mechanical scorecard.\n2. **Prefer no-write Keep.** Do not edit a doc just to leave a review breadcrumb.\n3. **Match docs to reality, not the reverse.** If current code differs from a learning, update the learning to reflect the codebase as it exists today.\n4. **Be decisive, minimize questions.** When evidence is clear, apply the update. Only ask when the action is genuinely ambiguous.\n5. **Avoid low-value churn.** Do not edit a doc for cosmetic wording or style-only cleanup.\n6. **Use Update only for meaningful, evidence-backed drift.** Paths, module names, links, code snippets, and metadata are fair game when accuracy improves materially.\n7. **Use Replace only when there is a real replacement.** The current codebase, related docs, or recent verified fixes must provide enough evidence to document the successor honestly.\n8. **Archive when the code is gone and the problem domain is gone.** Missing referenced files with no matching modern equivalent is strong archive evidence.\n\n## Scope Selection\n\nStart by discovering learnings and pattern docs under `docs\u002Fsolutions\u002F`.\n\nExclude:\n- `README.md`\n- `docs\u002Fsolutions\u002F_archived\u002F`\n\nFind all `.md` files under `docs\u002Fsolutions\u002F`, excluding `README.md` files and anything under `_archived\u002F`.\n\nIf `$ARGUMENTS` is provided, use it to narrow scope in this order:\n1. **Directory match** - a subdirectory under `docs\u002Fsolutions\u002F`\n2. **Frontmatter match** - `module`, `component`, or `tags`\n3. **Filename match** - partial filename match is fine\n4. **Content search** - keyword search inside files\n\nIf no matches are found, report that and ask the user to clarify. In autonomous mode, report the miss and stop.\n\nIf no candidate docs are found, report:\n\n```text\nNo candidate docs found in docs\u002Fsolutions\u002F.\nRun `\u002Fworkflows:compound` after solving problems to start building your knowledge base.\n```\n\n## Phase 0: Assess and Route\n\nBefore asking the user to classify anything:\n1. discover candidate artifacts\n2. estimate scope\n3. choose the lightest interaction path that fits\n\n### Route by Scope\n\n| Scope | When to use it | Interaction style |\n|-------|----------------|-------------------|\n| **Focused** | 1-2 likely files or a specific named doc | Investigate directly, then present a recommendation |\n| **Batch** | Up to about 8 mostly independent docs | Investigate first, then present grouped recommendations |\n| **Broad** | 9+ docs, ambiguous, or repo-wide stale-doc sweep | Triage first, then investigate in batches |\n\n### Broad Scope Triage\n\nWhen scope is broad:\n1. inventory frontmatter and group by module, component, or category\n2. identify dense clusters of learnings plus pattern docs\n3. spot-check whether the primary referenced files still exist\n4. recommend a starting area; in autonomous mode, process all clusters in impact order\n\nDo not ask action-selection questions yet. First gather evidence.\n\n## Phase 1: Investigate Candidate Learnings\n\nFor each learning in scope, read it, cross-reference its claims against the current codebase, and form a recommendation.\n\nA learning can go stale in several dimensions:\n- **References** - do the file paths, class names, and modules still exist or have they moved?\n- **Recommended solution** - does the fix still match how the code works today?\n- **Code examples** - if snippets exist, do they still reflect the current implementation?\n- **Related docs** - are cross-referenced learnings and patterns still present and consistent?\n- **Local guidance alignment** - does the learning still match current repository conventions documented in `AGENTS.md`, `CLAUDE.md`, and `README.md`?\n\nMatch investigation depth to the learning's specificity. A learning with exact file paths and code snippets needs more verification than one describing a general principle.\n\n### Drift Classification: Update vs Replace\n\nThe critical distinction is whether the drift is **cosmetic** or **substantive**:\n\n- **Update territory** - file paths moved, classes renamed, links broke, metadata drifted, but the core recommended approach is still correct.\n- **Replace territory** - the recommended solution conflicts with current code, the architecture changed, or the preferred pattern is different.\n\nThe boundary: if you find yourself rewriting the solution section or changing what the learning recommends, stop. That is Replace, not Update.\n\n### Judgment Guidelines\n\nThree guidelines that are easy to get wrong:\n1. **Contradiction = strong Replace signal.** If the learning conflicts with current code or a recently verified fix, it is actively misleading.\n2. **Age alone is not a stale signal.** Use age only as a prompt to inspect more carefully.\n3. **Check for successors before archiving.** Before recommending Replace or Archive, look for newer learnings, pattern docs, PRs, or issues covering the same problem space.\n\n## Phase 1.5: Investigate Pattern Docs\n\nAfter reviewing the underlying learning docs, investigate any relevant pattern docs under `docs\u002Fsolutions\u002Fpatterns\u002F`.\n\nPattern docs are high-leverage. A stale pattern is more dangerous than a stale individual learning because future work may treat it as broadly applicable guidance.\n\nA pattern doc with no clear supporting learnings is itself a stale signal.\n\n## Subagent Strategy\n\nUse subagents for context isolation when investigating multiple artifacts. Choose the lightest approach that fits:\n\n| Approach | When to use |\n|----------|-------------|\n| **Main thread only** | Small scope, short docs |\n| **Sequential subagents** | 1-2 artifacts with many supporting files |\n| **Parallel subagents** | 3+ truly independent artifacts with low overlap |\n| **Batched subagents** | Broad sweeps; narrow scope first, then investigate in batches |\n\nWhen spawning any subagent, include this instruction in its task prompt:\n\n> Use dedicated file search and read tools for all investigation. Do not use shell commands for file operations. Report: file path, evidence, recommended action, confidence, and open questions.\n\nThere are two subagent roles:\n1. **Investigation subagents** - read-only. They must not edit files or archive anything.\n2. **Replacement subagents** - write a single new learning to replace a stale one. Run these one at a time.\n\nThe orchestrator merges investigation results, detects contradictions, coordinates replacement subagents, and performs archival or metadata edits centrally.\n\n## Phase 2: Classify the Right Maintenance Action\n\nAfter gathering evidence, assign one recommended action.\n\n### Keep\n\nThe learning is still accurate and useful. Do not edit the file. Report that it remains trustworthy.\n\n### Update\n\nThe core solution is still valid but references have drifted. Apply the fixes directly.\n\n### Replace\n\nChoose **Replace** when the learning's core guidance is now misleading.\n\nAssess whether evidence is sufficient to write a trustworthy replacement:\n- **Sufficient evidence** - you understand both what the old learning recommended and what the current approach is. Proceed to write the replacement.\n- **Insufficient evidence** - you cannot confidently document the current approach. Mark the file stale in place with:\n  - `status: stale`\n  - `stale_reason`\n  - `stale_date: YYYY-MM-DD`\n\n### Archive\n\nChoose **Archive** when:\n- the code or workflow no longer exists\n- the learning is obsolete and has no modern replacement worth documenting\n- the learning is redundant and no longer useful on its own\n- there is no meaningful successor evidence suggesting it should be replaced instead\n\nAction:\n- move the file to `docs\u002Fsolutions\u002F_archived\u002F`\n- add `archived_date: YYYY-MM-DD`\n- add `archive_reason`\n\n### Before archiving: check whether the problem domain still exists\n\nIf the referenced implementation is gone but the broader problem domain is still active, that is usually **Replace**, not **Archive**.\n\nAuto-archive only when both the implementation and the problem domain are gone, or when the doc is fully superseded by a clearly better successor.\n\n## Pattern Guidance\n\nApply the same four outcomes to pattern docs, but evaluate them as derived guidance:\n- **Keep** - underlying learnings still support the generalized rule\n- **Update** - the rule holds but examples, links, or supporting references drifted\n- **Replace** - the rule is now misleading or the refreshed learnings support a different synthesis\n- **Archive** - the pattern is no longer valid, recurring, or distinct\n\n## Phase 3: Ask for Decisions\n\n### Autonomous mode\n\nSkip this entire phase. Do not ask any questions. Proceed directly to Phase 4:\n- unambiguous Keep, Update, auto-Archive, and Replace with sufficient evidence -> execute directly\n- ambiguous cases -> mark as stale\n- then generate the report\n\n### Interactive mode\n\nMost Updates should be applied directly without asking. Ask only when:\n- the right action is genuinely ambiguous\n- you are about to Archive a document and the evidence is not unambiguous\n- you are about to create a successor and want confirmation for that larger write\n\nDo not ask whether code changes were intentional or whether the user wants to fix the code. Stay focused on doc accuracy.\n\n#### Question Style\n\nAlways ask one question at a time. Prefer multiple choice. Lead with the recommended option and explain the rationale briefly.\n\n#### Focused Scope\n\nFor a single artifact, present:\n- file path\n- 2-4 bullets of evidence\n- recommended action\n\nThen ask:\n\n```text\nThis [learning\u002Fpattern] looks like a [Update\u002FKeep\u002FReplace\u002FArchive].\n\nWhy: [one-sentence rationale based on the evidence]\n\nWhat would you like to do?\n\n1. [Recommended action]\n2. [Second plausible action]\n3. Skip for now\n```\n\n#### Batch Scope\n\nFor several learnings:\n1. group obvious Keep cases together\n2. group obvious Update cases together when fixes are straightforward\n3. present Replace cases individually or in very small groups\n4. present Archive cases individually unless the archive is unambiguous and safe to auto-apply\n\n#### Broad Scope\n\nIf the user asked for a sweeping refresh:\n1. narrow scope first\n2. investigate a manageable batch\n3. present recommendations\n4. ask whether to continue to the next batch\n\n## Phase 4: Execute the Chosen Action\n\n### Keep Flow\n\nNo file edit by default. Summarize why the learning remains trustworthy.\n\n### Update Flow\n\nApply in-place edits only when the solution is still substantively correct.\n\nValid in-place updates include:\n- file or class reference renames\n- outdated links to related docs\n- refreshed implementation notes after a directory move\n- stale frontmatter or metadata that materially affects lookup accuracy\n\nDo not use Update for:\n- cosmetic wording tweaks\n- style-only cleanup\n- anti-pattern guidance that must be replaced\n- architecture changes that make the old guidance misleading\n\n### Replace Flow\n\nProcess Replace candidates one at a time.\n\nWhen evidence is sufficient:\n1. spawn a single subagent to write the replacement learning\n2. pass it:\n   - the old learning's full content\n   - investigation evidence\n   - the target path and category\n3. have it write the new learning following the `\u002Fworkflows:compound` or `compound-docs` document structure: frontmatter, problem, root cause, current solution, code examples, and prevention tips\n4. after it completes, the orchestrator:\n   - adds `superseded_by` to the old learning\n   - moves the old learning to `docs\u002Fsolutions\u002F_archived\u002F`\n\nWhen evidence is insufficient:\n1. mark the learning stale in place\n2. report what evidence was found and what is missing\n3. recommend running `\u002Fworkflows:compound` after the next real encounter with that area\n\n### Archive Flow\n\nArchive only when a learning is clearly obsolete or redundant. Do not archive a document just because it is old.\n\n## Output Format\n\nThe full report must be printed as markdown output. The report is the deliverable.\n\nAfter processing the selected scope, output:\n\n```text\nCompound Refresh Summary\n========================\nScanned: N learnings\n\nKept: X\nUpdated: Y\nReplaced: Z\nArchived: W\nSkipped: V\nMarked stale: S\n```\n\nThen for every file processed, list:\n- file path\n- classification (Keep\u002FUpdate\u002FReplace\u002FArchive\u002FStale)\n- evidence found\n- action taken or recommended\n\nFor **Keep** outcomes, list them under a reviewed-without-edits section so the result is visible without creating git churn.\n\n### Autonomous mode output\n\nIn autonomous mode, the report is the sole deliverable. Print every section in full.\n\nSplit actions into two sections:\n\n**Applied** (writes that succeeded):\n- Updated files\n- Replaced files and their successors\n- Archived files\n- Marked stale files\n\n**Recommended** (actions that could not be written):\n- same level of detail, framed as recommendations for a human to apply\n\nIf all writes succeed, the Recommended section is empty.\n\n## Phase 5: Commit Changes\n\nSkip this phase if no files were modified.\n\n### Detect git context\n\nBefore offering options, check:\n1. which branch is currently checked out\n2. whether the working tree has other uncommitted changes beyond what compound-refresh modified\n3. recent commit messages to match repo style\n\nStage only the files that `compound-refresh` modified.\n\n### Autonomous mode\n\nUse sensible defaults:\n- on main or master, create a branch named for what was refreshed, commit, and attempt to open a PR\n- on a feature branch, commit as a separate commit on the current branch\n- if git operations fail, include the recommended git commands in the report\n\n### Interactive mode\n\nIf on the default branch, offer:\n1. create a branch, commit, and open a PR (recommended)\n2. commit directly to the current branch\n3. do not commit\n\nIf on a feature branch with a clean working tree, offer:\n1. commit to the current branch as a separate commit (recommended)\n2. create a separate branch and commit\n3. do not commit\n\nIf on a feature branch with other dirty changes, offer:\n1. commit only the compound-refresh changes to the current branch\n2. do not commit\n\n### Commit message\n\nWrite a descriptive commit message that:\n- summarizes what was refreshed\n- follows the repo's existing commit conventions\n- stays succinct\n\n## Relationship to `\u002Fworkflows:compound`\n\n- `\u002Fworkflows:compound` captures a newly solved, verified problem\n- `\u002Fworkflows:compound-refresh` maintains older learnings as the codebase evolves\n\nUse **Replace** only when the refresh process has enough real evidence to write a trustworthy successor. When evidence is insufficient, mark as stale and recommend `\u002Fworkflows:compound` for when the user next encounters that problem area.\n","# Compound Refresh\n\nMaintain the quality of `docs\u002Fsolutions\u002F` over time. Review existing learnings against the current codebase, then refresh any derived pattern docs that depend on them.\n\n## Mode Detection\n\nCheck if `$ARGUMENTS` contains `mode:autonomous`. If present, strip it from arguments and run in **autonomous mode**.\n\n| Mode | When | Behavior |\n|------|------|----------|\n| **Interactive** (default) | User is present and can answer questions | Ask for decisions on ambiguous cases and confirm disruptive actions |\n| **Autonomous** | `mode:autonomous` in arguments | No user interaction. Apply unambiguous actions, mark ambiguous cases stale, and generate a full report |\n\n### Autonomous mode rules\n\n- Skip all user questions.\n- Process all docs in scope. If no scope hint was provided, process everything.\n- Attempt all safe actions: Keep, Update, auto-Archive, and Replace when evidence is sufficient.\n- If a write succeeds, record it as **applied**.\n- If a write fails, record it as **recommended** in the report and continue.\n- If classification is genuinely ambiguous, mark the doc stale with `status: stale`, `stale_reason`, and `stale_date`.\n- Use conservative confidence. Borderline cases become stale in autonomous mode.\n- Always generate a report with **Applied** and **Recommended** sections.\n\n## Local Grounding\n\nBefore editing anything under `docs\u002Fsolutions\u002F`, read the local guidance files in this order:\n1. `AGENTS.md`\n2. `CLAUDE.md` (if present)\n3. `README.md`\n\nUse them to preserve the repository's docs conventions, OpenViking guidance, and workflow naming.\n\n## Interaction Principles\n\nThese principles apply to interactive mode only. In autonomous mode, skip all user questions and apply the autonomous rules above.\n\nFollow the same interaction style as `\u002Fworkflows:brainstorm`:\n- ask questions one at a time\n- prefer multiple choice when natural options exist\n- start with scope and intent, then narrow only when needed\n- do not ask the user to decide before you have evidence\n- lead with a recommendation and explain it briefly\n\nThe goal is to help the user make a good maintenance decision with minimal friction.\n\n## Refresh Order\n\nRefresh in this order:\n1. review the relevant individual learning docs first\n2. note which learnings stayed valid, were updated, were replaced, or were archived\n3. then review any pattern docs that depend on those learnings\n\nWhy this order:\n- learning docs are the primary evidence\n- pattern docs are derived from one or more learnings\n- stale learnings can make a pattern look more valid than it really is\n\nIf the user starts by naming a pattern doc, you may begin there to understand the concern, but inspect the supporting learning docs before changing the pattern.\n\n## Maintenance Model\n\nFor each candidate artifact, classify it into one of four outcomes:\n\n| Outcome | Meaning | Default action |\n|---------|---------|----------------|\n| **Keep** | Still accurate and still useful | No file edit by default; report that it remains trustworthy |\n| **Update** | Core solution is still correct, but references drifted | Apply evidence-backed in-place edits |\n| **Replace** | The old artifact is now misleading, but there is a known better replacement | Create a trustworthy successor, then archive or supersede the old artifact |\n| **Archive** | No longer useful or applicable | Move the obsolete artifact to `docs\u002Fsolutions\u002F_archived\u002F` with archive metadata |\n\n## Core Rules\n\n1. **Evidence informs judgment.** Use engineering judgment; do not treat this as a mechanical scorecard.\n2. **Prefer no-write Keep.** Do not edit a doc just to leave a review breadcrumb.\n3. **Match docs to reality, not the reverse.** If current code differs from a learning, update the learning to reflect the codebase as it exists today.\n4. **Be decisive, minimize questions.** When evidence is clear, apply the update. Only ask when the action is genuinely ambiguous.\n5. **Avoid low-value churn.** Do not edit a doc for cosmetic wording or style-only cleanup.\n6. **Use Update only for meaningful, evidence-backed drift.** Paths, module names, links, code snippets, and metadata are fair game when accuracy improves materially.\n7. **Use Replace only when there is a real replacement.** The current codebase, related docs, or recent verified fixes must provide enough evidence to document the successor honestly.\n8. **Archive when the code is gone and the problem domain is gone.** Missing referenced files with no matching modern equivalent is strong archive evidence.\n\n## Scope Selection\n\nStart by discovering learnings and pattern docs under `docs\u002Fsolutions\u002F`.\n\nExclude:\n- `README.md`\n- `docs\u002Fsolutions\u002F_archived\u002F`\n\nFind all `.md` files under `docs\u002Fsolutions\u002F`, excluding `README.md` files and anything under `_archived\u002F`.\n\nIf `$ARGUMENTS` is provided, use it to narrow scope in this order:\n1. **Directory match** - a subdirectory under `docs\u002Fsolutions\u002F`\n2. **Frontmatter match** - `module`, `component`, or `tags`\n3. **Filename match** - partial filename match is fine\n4. **Content search** - keyword search inside files\n\nIf no matches are found, report that and ask the user to clarify. In autonomous mode, report the miss and stop.\n\nIf no candidate docs are found, report:\n\n```text\nNo candidate docs found in docs\u002Fsolutions\u002F.\nRun `\u002Fworkflows:compound` after solving problems to start building your knowledge base.\n```\n\n## Phase 0: Assess and Route\n\nBefore asking the user to classify anything:\n1. discover candidate artifacts\n2. estimate scope\n3. choose the lightest interaction path that fits\n\n### Route by Scope\n\n| Scope | When to use it | Interaction style |\n|-------|----------------|-------------------|\n| **Focused** | 1-2 likely files or a specific named doc | Investigate directly, then present a recommendation |\n| **Batch** | Up to about 8 mostly independent docs | Investigate first, then present grouped recommendations |\n| **Broad** | 9+ docs, ambiguous, or repo-wide stale-doc sweep | Triage first, then investigate in batches |\n\n### Broad Scope Triage\n\nWhen scope is broad:\n1. inventory frontmatter and group by module, component, or category\n2. identify dense clusters of learnings plus pattern docs\n3. spot-check whether the primary referenced files still exist\n4. recommend a starting area; in autonomous mode, process all clusters in impact order\n\nDo not ask action-selection questions yet. First gather evidence.\n\n## Phase 1: Investigate Candidate Learnings\n\nFor each learning in scope, read it, cross-reference its claims against the current codebase, and form a recommendation.\n\nA learning can go stale in several dimensions:\n- **References** - do the file paths, class names, and modules still exist or have they moved?\n- **Recommended solution** - does the fix still match how the code works today?\n- **Code examples** - if snippets exist, do they still reflect the current implementation?\n- **Related docs** - are cross-referenced learnings and patterns still present and consistent?\n- **Local guidance alignment** - does the learning still match current repository conventions documented in `AGENTS.md`, `CLAUDE.md`, and `README.md`?\n\nMatch investigation depth to the learning's specificity. A learning with exact file paths and code snippets needs more verification than one describing a general principle.\n\n### Drift Classification: Update vs Replace\n\nThe critical distinction is whether the drift is **cosmetic** or **substantive**:\n\n- **Update territory** - file paths moved, classes renamed, links broke, metadata drifted, but the core recommended approach is still correct.\n- **Replace territory** - the recommended solution conflicts with current code, the architecture changed, or the preferred pattern is different.\n\nThe boundary: if you find yourself rewriting the solution section or changing what the learning recommends, stop. That is Replace, not Update.\n\n### Judgment Guidelines\n\nThree guidelines that are easy to get wrong:\n1. **Contradiction = strong Replace signal.** If the learning conflicts with current code or a recently verified fix, it is actively misleading.\n2. **Age alone is not a stale signal.** Use age only as a prompt to inspect more carefully.\n3. **Check for successors before archiving.** Before recommending Replace or Archive, look for newer learnings, pattern docs, PRs, or issues covering the same problem space.\n\n## Phase 1.5: Investigate Pattern Docs\n\nAfter reviewing the underlying learning docs, investigate any relevant pattern docs under `docs\u002Fsolutions\u002Fpatterns\u002F`.\n\nPattern docs are high-leverage. A stale pattern is more dangerous than a stale individual learning because future work may treat it as broadly applicable guidance.\n\nA pattern doc with no clear supporting learnings is itself a stale signal.\n\n## Subagent Strategy\n\nUse subagents for context isolation when investigating multiple artifacts. Choose the lightest approach that fits:\n\n| Approach | When to use |\n|----------|-------------|\n| **Main thread only** | Small scope, short docs |\n| **Sequential subagents** | 1-2 artifacts with many supporting files |\n| **Parallel subagents** | 3+ truly independent artifacts with low overlap |\n| **Batched subagents** | Broad sweeps; narrow scope first, then investigate in batches |\n\nWhen spawning any subagent, include this instruction in its task prompt:\n\n> Use dedicated file search and read tools for all investigation. Do not use shell commands for file operations. Report: file path, evidence, recommended action, confidence, and open questions.\n\nThere are two subagent roles:\n1. **Investigation subagents** - read-only. They must not edit files or archive anything.\n2. **Replacement subagents** - write a single new learning to replace a stale one. Run these one at a time.\n\nThe orchestrator merges investigation results, detects contradictions, coordinates replacement subagents, and performs archival or metadata edits centrally.\n\n## Phase 2: Classify the Right Maintenance Action\n\nAfter gathering evidence, assign one recommended action.\n\n### Keep\n\nThe learning is still accurate and useful. Do not edit the file. Report that it remains trustworthy.\n\n### Update\n\nThe core solution is still valid but references have drifted. Apply the fixes directly.\n\n### Replace\n\nChoose **Replace** when the learning's core guidance is now misleading.\n\nAssess whether evidence is sufficient to write a trustworthy replacement:\n- **Sufficient evidence** - you understand both what the old learning recommended and what the current approach is. Proceed to write the replacement.\n- **Insufficient evidence** - you cannot confidently document the current approach. Mark the file stale in place with:\n  - `status: stale`\n  - `stale_reason`\n  - `stale_date: YYYY-MM-DD`\n\n### Archive\n\nChoose **Archive** when:\n- the code or workflow no longer exists\n- the learning is obsolete and has no modern replacement worth documenting\n- the learning is redundant and no longer useful on its own\n- there is no meaningful successor evidence suggesting it should be replaced instead\n\nAction:\n- move the file to `docs\u002Fsolutions\u002F_archived\u002F`\n- add `archived_date: YYYY-MM-DD`\n- add `archive_reason`\n\n### Before archiving: check whether the problem domain still exists\n\nIf the referenced implementation is gone but the broader problem domain is still active, that is usually **Replace**, not **Archive**.\n\nAuto-archive only when both the implementation and the problem domain are gone, or when the doc is fully superseded by a clearly better successor.\n\n## Pattern Guidance\n\nApply the same four outcomes to pattern docs, but evaluate them as derived guidance:\n- **Keep** - underlying learnings still support the generalized rule\n- **Update** - the rule holds but examples, links, or supporting references drifted\n- **Replace** - the rule is now misleading or the refreshed learnings support a different synthesis\n- **Archive** - the pattern is no longer valid, recurring, or distinct\n\n## Phase 3: Ask for Decisions\n\n### Autonomous mode\n\nSkip this entire phase. Do not ask any questions. Proceed directly to Phase 4:\n- unambiguous Keep, Update, auto-Archive, and Replace with sufficient evidence -> execute directly\n- ambiguous cases -> mark as stale\n- then generate the report\n\n### Interactive mode\n\nMost Updates should be applied directly without asking. Ask only when:\n- the right action is genuinely ambiguous\n- you are about to Archive a document and the evidence is not unambiguous\n- you are about to create a successor and want confirmation for that larger write\n\nDo not ask whether code changes were intentional or whether the user wants to fix the code. Stay focused on doc accuracy.\n\n#### Question Style\n\nAlways ask one question at a time. Prefer multiple choice. Lead with the recommended option and explain the rationale briefly.\n\n#### Focused Scope\n\nFor a single artifact, present:\n- file path\n- 2-4 bullets of evidence\n- recommended action\n\nThen ask:\n\n```text\nThis [learning\u002Fpattern] looks like a [Update\u002FKeep\u002FReplace\u002FArchive].\n\nWhy: [one-sentence rationale based on the evidence]\n\nWhat would you like to do?\n\n1. [Recommended action]\n2. [Second plausible action]\n3. Skip for now\n```\n\n#### Batch Scope\n\nFor several learnings:\n1. group obvious Keep cases together\n2. group obvious Update cases together when fixes are straightforward\n3. present Replace cases individually or in very small groups\n4. present Archive cases individually unless the archive is unambiguous and safe to auto-apply\n\n#### Broad Scope\n\nIf the user asked for a sweeping refresh:\n1. narrow scope first\n2. investigate a manageable batch\n3. present recommendations\n4. ask whether to continue to the next batch\n\n## Phase 4: Execute the Chosen Action\n\n### Keep Flow\n\nNo file edit by default. Summarize why the learning remains trustworthy.\n\n### Update Flow\n\nApply in-place edits only when the solution is still substantively correct.\n\nValid in-place updates include:\n- file or class reference renames\n- outdated links to related docs\n- refreshed implementation notes after a directory move\n- stale frontmatter or metadata that materially affects lookup accuracy\n\nDo not use Update for:\n- cosmetic wording tweaks\n- style-only cleanup\n- anti-pattern guidance that must be replaced\n- architecture changes that make the old guidance misleading\n\n### Replace Flow\n\nProcess Replace candidates one at a time.\n\nWhen evidence is sufficient:\n1. spawn a single subagent to write the replacement learning\n2. pass it:\n   - the old learning's full content\n   - investigation evidence\n   - the target path and category\n3. have it write the new learning following the `\u002Fworkflows:compound` or `compound-docs` document structure: frontmatter, problem, root cause, current solution, code examples, and prevention tips\n4. after it completes, the orchestrator:\n   - adds `superseded_by` to the old learning\n   - moves the old learning to `docs\u002Fsolutions\u002F_archived\u002F`\n\nWhen evidence is insufficient:\n1. mark the learning stale in place\n2. report what evidence was found and what is missing\n3. recommend running `\u002Fworkflows:compound` after the next real encounter with that area\n\n### Archive Flow\n\nArchive only when a learning is clearly obsolete or redundant. Do not archive a document just because it is old.\n\n## Output Format\n\nThe full report must be printed as markdown output. The report is the deliverable.\n\nAfter processing the selected scope, output:\n\n```text\nCompound Refresh Summary\n========================\nScanned: N learnings\n\nKept: X\nUpdated: Y\nReplaced: Z\nArchived: W\nSkipped: V\nMarked stale: S\n```\n\nThen for every file processed, list:\n- file path\n- classification (Keep\u002FUpdate\u002FReplace\u002FArchive\u002FStale)\n- evidence found\n- action taken or recommended\n\nFor **Keep** outcomes, list them under a reviewed-without-edits section so the result is visible without creating git churn.\n\n### Autonomous mode output\n\nIn autonomous mode, the report is the sole deliverable. Print every section in full.\n\nSplit actions into two sections:\n\n**Applied** (writes that succeeded):\n- Updated files\n- Replaced files and their successors\n- Archived files\n- Marked stale files\n\n**Recommended** (actions that could not be written):\n- same level of detail, framed as recommendations for a human to apply\n\nIf all writes succeed, the Recommended section is empty.\n\n## Phase 5: Commit Changes\n\nSkip this phase if no files were modified.\n\n### Detect git context\n\nBefore offering options, check:\n1. which branch is currently checked out\n2. whether the working tree has other uncommitted changes beyond what compound-refresh modified\n3. recent commit messages to match repo style\n\nStage only the files that `compound-refresh` modified.\n\n### Autonomous mode\n\nUse sensible defaults:\n- on main or master, create a branch named for what was refreshed, commit, and attempt to open a PR\n- on a feature branch, commit as a separate commit on the current branch\n- if git operations fail, include the recommended git commands in the report\n\n### Interactive mode\n\nIf on the default branch, offer:\n1. create a branch, commit, and open a PR (recommended)\n2. commit directly to the current branch\n3. do not commit\n\nIf on a feature branch with a clean working tree, offer:\n1. commit to the current branch as a separate commit (recommended)\n2. create a separate branch and commit\n3. do not commit\n\nIf on a feature branch with other dirty changes, offer:\n1. commit only the compound-refresh changes to the current branch\n2. do not commit\n\n### Commit message\n\nWrite a descriptive commit message that:\n- summarizes what was refreshed\n- follows the repo's existing commit conventions\n- stays succinct\n\n## Relationship to `\u002Fworkflows:compound`\n\n- `\u002Fworkflows:compound` captures a newly solved, verified problem\n- `\u002Fworkflows:compound-refresh` maintains older learnings as the codebase evolves\n\nUse **Replace** only when the refresh process has enough real evidence to write a trustworthy successor. When evidence is insufficient, mark as stale and recommend `\u002Fworkflows:compound` for when the user next encounters that problem area.\n",{"name":5,"model":30,"description":7,"disable-model-invocation":31},"claude-sonnet-5",true,"main","4c70ff7e10e692dfcc6d7877a6e57dd08df94d9b","plugins\u002Fcompound-engineering\u002Fskills\u002Fcompound-refresh","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin","https:\u002F\u002Fgithub.com\u002FThe-Rabak","2026-07-28 15:25:35",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":31},[40,43,46],{"tool":41,"command":42},"npx","npx skills add The-Rabak\u002Fcompound-engineering-plugin --skill compound-refresh",{"tool":44,"command":45},"bunx","bunx skills add The-Rabak\u002Fcompound-engineering-plugin --skill compound-refresh",{"tool":47,"command":48},"pnpm","pnpm dlx skills add The-Rabak\u002Fcompound-engineering-plugin --skill compound-refresh","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fcompound-refresh\u002FSKILL.md",[],[52,69,78,88,96,103],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":63,"publishedAt":25},"01M6CY858Z5RCC30TKAVBDJ6SZ","skill-one","Shared reusable skill.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-portable-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[58],{"categoryNo":59,"categoryName":60,"taxonomyType":61,"taxonomyTypeDesc":62},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[64,65,66,67,68],"skill one","shared","reusable","haiku","gpt",{"skillNo":70,"name":54,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":75,"publishedAt":25},"01M6CY843KQG3FQF6259420CCD","Sample skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[74],{"categoryNo":59,"categoryName":60,"taxonomyType":61,"taxonomyTypeDesc":62},[64,76,77],"sample","sample skill",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":85,"publishedAt":25},"01M6CY82607GGPWR5H25SY74H2","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[84],{"categoryNo":59,"categoryName":60,"taxonomyType":61,"taxonomyTypeDesc":62},[86,87],"disabled skill","model",{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":25},"01M6CY80RWMK81T97A2Q5KAFAF","default-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[94,95],"default skill","default",{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":25},"01M6CY7ZK2PMV75ES90W6YYD4S","custom-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[102],"custom skill",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":25},"01M6CY7V6C7HFCNJEVNFT1X00T","workflow-next-step","This skill should be used at the end of core compound-engineering workflows to inspect completed artifacts, show the workflow progress checklist, and give the exact next-session command with inputs.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fworkflow-next-step\u002FSKILL.md",[109],{"categoryNo":59,"categoryName":60,"taxonomyType":61,"taxonomyTypeDesc":62},[111,112,113,19,114,115,116,117,118,119,120,121],"workflow","next","workflow next step","show","checklist","session","command","engineering","artifacts","core","workflows"]