[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71ET4VN83N0WNAHJVKWHTDA":3,"skill-same:01M71ET4VN83N0WNAHJVKWHTDA":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M71ET4VN83N0WNAHJVKWHTDA","ce-compound",null,"Document a recently solved problem to compound your team's knowledge","shyamsridhar123\u002Fkevin-copilot","shyamsridhar123","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F117464342?v=4","01M71ESN8NA3Z6Z47CJS9WBT0B","Shyam Sridhar","01M71ESNA9HE4YA6ZZSCNYCGJR",8,"MIT","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fce-compound\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[24,25,26,27,28,29],"compound","ce compound","team","knowledge","document","problem","2026-11-10 10:12:30",false,"---\nname: ce-compound\ndescription: Document a recently solved problem to compound your team's knowledge\n---\n\n# \u002Fcompound\n\nCoordinate multiple subagents working in parallel to document a recently solved problem.\n\n## Purpose\n\nCaptures problem solutions while context is fresh, creating structured documentation in `docs\u002Fsolutions\u002F` with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.\n\n**Why \"compound\"?** Each documented solution compounds your team's knowledge. The first time you solve a problem takes research. Document it, and the next occurrence takes minutes. Knowledge compounds.\n\n## Usage\n\n```bash\n\u002Fce-compound                    # Document the most recent fix\n\u002Fce-compound [brief context]    # Provide additional context hint\n```\n\n## Support Files\n\nThese files are the durable contract for the workflow. Read them on-demand at the step that needs them — do not bulk-load at skill start.\n\n- `references\u002Fschema.yaml` — canonical frontmatter fields and enum values (read when validating YAML)\n- `references\u002Fyaml-schema.md` — category mapping from problem_type to directory (read when classifying)\n- `assets\u002Fresolution-template.md` — section structure for new docs (read when assembling)\n\nWhen spawning subagents, pass the relevant file contents into the task prompt so they have the contract without needing cross-skill paths.\n\n## Execution Strategy\n\n**Always run full mode by default.** Proceed directly to Phase 1 unless the user explicitly requests compact-safe mode (e.g., `\u002Fce-compound --compact` or \"use compact mode\").\n\nCompact-safe mode exists as a lightweight alternative — see the **Compact-Safe Mode** section below. It's there if the user wants it, not something to push.\n\n---\n\n### Full Mode\n\n\u003Ccritical_requirement>\n**The primary output is ONE file - the final documentation.**\n\nPhase 1 subagents return TEXT DATA to the orchestrator. They must NOT use Write, Edit, or create any files. Only the orchestrator writes files: the solution doc in Phase 2, and — if the Discoverability Check finds a gap — a small edit to a project instruction file (AGENTS.md or CLAUDE.md). The instruction-file edit is maintenance, not a second deliverable; it ensures future agents can discover the knowledge store.\n\u003C\u002Fcritical_requirement>\n\n### Phase 0.5: Auto Memory Scan\n\nBefore launching Phase 1 subagents, check the auto memory directory for notes relevant to the problem being documented.\n\n1. Read MEMORY.md from the auto memory directory (the path is known from the system prompt context)\n2. If the directory or MEMORY.md does not exist, is empty, or is unreadable, skip this step and proceed to Phase 1 unchanged\n3. Scan the entries for anything related to the problem being documented -- use semantic judgment, not keyword matching\n4. If relevant entries are found, prepare a labeled excerpt block:\n\n```\n## Supplementary notes from auto memory\nTreat as additional context, not primary evidence. Conversation history\nand codebase findings take priority over these notes.\n\n[relevant entries here]\n```\n\n5. Pass this block as additional context to the Context Analyzer and Solution Extractor task prompts in Phase 1. If any memory notes end up in the final documentation (e.g., as part of the investigation steps or root cause analysis), tag them with \"(auto memory [claude])\" so their origin is clear to future readers.\n\nIf no relevant entries are found, proceed to Phase 1 without passing memory context.\n\n### Phase 1: Parallel Research\n\n\u003Cparallel_tasks>\n\nLaunch these subagents IN PARALLEL. Each returns text data to the orchestrator.\n\n#### 1. **Context Analyzer**\n   - Extracts conversation history\n   - Reads `references\u002Fschema.yaml` for enum validation and **track classification**\n   - Determines the track (bug or knowledge) from the problem_type\n   - Identifies problem type, component, and track-appropriate fields:\n     - **Bug track**: symptoms, root_cause, resolution_type\n     - **Knowledge track**: applies_when (symptoms\u002Froot_cause\u002Fresolution_type optional)\n   - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence\n   - Reads `references\u002Fyaml-schema.md` for category mapping into `docs\u002Fsolutions\u002F`\n   - Suggests a filename using the pattern `[sanitized-problem-slug]-[date].md`\n   - Returns: YAML frontmatter skeleton (must include `category:` field mapped from problem_type), category directory path, suggested filename, and which track applies\n   - Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above\n   - Does not force bug-track fields onto knowledge-track learnings or vice versa\n\n#### 2. **Solution Extractor**\n   - Reads `references\u002Fschema.yaml` for track classification (bug vs knowledge)\n   - Adapts output structure based on the problem_type track\n   - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence -- conversation history and the verified fix take priority; if memory notes contradict the conversation, note the contradiction as cautionary context\n\n   **Bug track output sections:**\n\n   - **Problem**: 1-2 sentence description of the issue\n   - **Symptoms**: Observable symptoms (error messages, behavior)\n   - **What Didn't Work**: Failed investigation attempts and why they failed\n   - **Solution**: The actual fix with code examples (before\u002Fafter when applicable)\n   - **Why This Works**: Root cause explanation and why the solution addresses it\n   - **Prevention**: Strategies to avoid recurrence, best practices, and test cases. Include concrete code examples where applicable (e.g., gem configurations, test assertions, linting rules)\n\n   **Knowledge track output sections:**\n\n   - **Context**: What situation, gap, or friction prompted this guidance\n   - **Guidance**: The practice, pattern, or recommendation with code examples when useful\n   - **Why This Matters**: Rationale and impact of following or not following this guidance\n   - **When to Apply**: Conditions or situations where this applies\n   - **Examples**: Concrete before\u002Fafter or usage examples showing the practice in action\n\n#### 3. **Related Docs Finder**\n   - Searches `docs\u002Fsolutions\u002F` for related documentation\n   - Identifies cross-references and links\n   - Finds related GitHub issues\n   - Flags any related learning or pattern docs that may now be stale, contradicted, or overly broad\n   - **Assesses overlap** with the new doc being created across five dimensions: problem statement, root cause, solution approach, referenced files, and prevention rules. Score as:\n     - **High**: 4-5 dimensions match — essentially the same problem solved again\n     - **Moderate**: 2-3 dimensions match — same area but different angle or solution\n     - **Low**: 0-1 dimensions match — related but distinct\n   - Returns: Links, relationships, refresh candidates, and overlap assessment (score + which dimensions matched)\n\n   **Search strategy (grep-first filtering for efficiency):**\n\n   1. Extract keywords from the problem context: module names, technical terms, error messages, component types\n   2. If the problem category is clear, narrow search to the matching `docs\u002Fsolutions\u002F\u003Ccategory>\u002F` directory\n   3. Use the native content-search tool (e.g., Grep in Claude Code) to pre-filter candidate files BEFORE reading any content. Run multiple searches in parallel, case-insensitive, targeting frontmatter fields. These are template patterns -- substitute actual keywords:\n      - `title:.*\u003Ckeyword>`\n      - `tags:.*(\u003Ckeyword1>|\u003Ckeyword2>)`\n      - `module:.*\u003Cmodule name>`\n      - `component:.*\u003Ccomponent>`\n   4. If search returns >25 candidates, re-run with more specific patterns. If \u003C3, broaden to full content search\n   5. Read only frontmatter (first 30 lines) of candidate files to score relevance\n   6. Fully read only strong\u002Fmoderate matches\n   7. Return distilled links and relationships, not raw file contents\n\n   **GitHub issue search:**\n\n   Prefer the `gh` CLI for searching related issues: `gh issue list --search \"\u003Ckeywords>\" --state all --limit 5`. If `gh` is not installed, fall back to the GitHub MCP tools (e.g., `unblocked` data_retrieval) if available. If neither is available, skip GitHub issue search and note it was skipped in the output.\n\n\u003C\u002Fparallel_tasks>\n\n### Phase 2: Assembly & Write\n\n\u003Csequential_tasks>\n\n**WAIT for all Phase 1 subagents to complete before proceeding.**\n\nThe orchestrating agent (main conversation) performs these steps:\n\n1. Collect all text results from Phase 1 subagents\n2. **Check the overlap assessment** from the Related Docs Finder before deciding what to write:\n\n   | Overlap | Action |\n   |---------|--------|\n   | **High** — existing doc covers the same problem, root cause, and solution | **Update the existing doc** with fresher context (new code examples, updated references, additional prevention tips) rather than creating a duplicate. The existing doc's path and structure stay the same. |\n   | **Moderate** — same problem area but different angle, root cause, or solution | **Create the new doc** normally. Flag the overlap for Phase 2.5 to recommend consolidation review. |\n   | **Low or none** | **Create the new doc** normally. |\n\n   The reason to update rather than create: two docs describing the same problem and solution will inevitably drift apart. The newer context is fresher and more trustworthy, so fold it into the existing doc rather than creating a second one that immediately needs consolidation.\n\n   When updating an existing doc, preserve its file path and frontmatter structure. Update the solution, code examples, prevention tips, and any stale references. Add a `last_updated: YYYY-MM-DD` field to the frontmatter. Do not change the title unless the problem framing has materially shifted.\n\n3. Assemble complete markdown file from the collected pieces, reading `assets\u002Fresolution-template.md` for the section structure of new docs\n4. Validate YAML frontmatter against `references\u002Fschema.yaml`\n5. Create directory if needed: `mkdir -p docs\u002Fsolutions\u002F[category]\u002F`\n6. Write the file: either the updated existing doc or the new `docs\u002Fsolutions\u002F[category]\u002F[filename].md`\n\nWhen creating a new doc, preserve the section order from `assets\u002Fresolution-template.md` unless the user explicitly asks for a different structure.\n\n\u003C\u002Fsequential_tasks>\n\n### Phase 2.5: Selective Refresh Check\n\nAfter writing the new learning, decide whether this new solution is evidence that older docs should be refreshed.\n\n`ce-compound-refresh` is **not** a default follow-up. Use it selectively when the new learning suggests an older learning or pattern doc may now be inaccurate.\n\nIt makes sense to invoke `ce-compound-refresh` when one or more of these are true:\n\n1. A related learning or pattern doc recommends an approach that the new fix now contradicts\n2. The new fix clearly supersedes an older documented solution\n3. The current work involved a refactor, migration, rename, or dependency upgrade that likely invalidated references in older docs\n4. A pattern doc now looks overly broad, outdated, or no longer supported by the refreshed reality\n5. The Related Docs Finder surfaced high-confidence refresh candidates in the same problem space\n6. The Related Docs Finder reported **moderate overlap** with an existing doc — there may be consolidation opportunities that benefit from a focused review\n\nIt does **not** make sense to invoke `ce-compound-refresh` when:\n\n1. No related docs were found\n2. Related docs still appear consistent with the new learning\n3. The overlap is superficial and does not change prior guidance\n4. Refresh would require a broad historical review with weak evidence\n\nUse these rules:\n\n- If there is **one obvious stale candidate**, invoke `ce-compound-refresh` with a narrow scope hint after the new learning is written\n- If there are **multiple candidates in the same area**, ask the user whether to run a targeted refresh for that module, category, or pattern set\n- If context is already tight or you are in compact-safe mode, do not expand into a broad refresh automatically; instead recommend `ce-compound-refresh` as the next step with a scope hint\n\nWhen invoking or recommending `ce-compound-refresh`, be explicit about the argument to pass. Prefer the narrowest useful scope:\n\n- **Specific file** when one learning or pattern doc is the likely stale artifact\n- **Module or component name** when several related docs may need review\n- **Category name** when the drift is concentrated in one solutions area\n- **Pattern filename or pattern topic** when the stale guidance lives in `docs\u002Fsolutions\u002Fpatterns\u002F`\n\nExamples:\n\n- `\u002Fce-compound-refresh plugin-versioning-requirements`\n- `\u002Fce-compound-refresh payments`\n- `\u002Fce-compound-refresh performance-issues`\n- `\u002Fce-compound-refresh critical-patterns`\n\nA single scope hint may still expand to multiple related docs when the change is cross-cutting within one domain, category, or pattern area.\n\nDo not invoke `ce-compound-refresh` without an argument unless the user explicitly wants a broad sweep.\n\nAlways capture the new learning first. Refresh is a targeted maintenance follow-up, not a prerequisite for documentation.\n\n### Discoverability Check\n\nAfter the learning is written and the refresh decision is made, check whether the project's instruction files would lead an agent to discover and search `docs\u002Fsolutions\u002F` before starting work in a documented area. This runs every time — the knowledge store only compounds value when agents can find it.\n\n1. Identify which root-level instruction files exist (AGENTS.md, CLAUDE.md, or both). Read the file(s) and determine which holds the substantive content — one file may just be a shim that `@`-includes the other (e.g., `CLAUDE.md` containing only `@AGENTS.md`, or vice versa). The substantive file is the assessment and edit target; ignore shims. If neither file exists, skip this check entirely.\n2. Assess whether an agent reading the instruction files would learn three things:\n   - That a searchable knowledge store of documented solutions exists\n   - Enough about its structure to search effectively (category organization, YAML frontmatter fields like `module`, `tags`, `problem_type`)\n   - When to search it (before implementing features, debugging issues, or making decisions in documented areas — learnings may cover bugs, best practices, workflow patterns, or other institutional knowledge)\n\n   This is a semantic assessment, not a string match. The information could be a line in an architecture section, a bullet in a gotchas section, spread across multiple places, or expressed without ever using the exact path `docs\u002Fsolutions\u002F`. Use judgment — if an agent would reasonably discover and use the knowledge store after reading the file, the check passes.\n\n3. If the spirit is already met, no action needed — move on.\n4. If not:\n   a. Based on the file's existing structure, tone, and density, identify where a mention fits naturally. Before creating a new section, check whether the information could be a single line in the closest related section — an architecture tree, a directory listing, a documentation section, or a conventions block. A line added to an existing section is almost always better than a new headed section. Only add a new section as a last resort when the file has clear sectioned structure and nothing is even remotely related.\n   b. Draft the smallest addition that communicates the three things. Match the file's existing style and density. The addition should describe the knowledge store itself, not the plugin — an agent without the plugin should still find value in it.\n\n      Keep the tone informational, not imperative. Express timing as description, not instruction — \"relevant when implementing or debugging in documented areas\" rather than \"check before implementing or debugging.\" Imperative directives like \"always search before implementing\" cause redundant reads when a workflow already includes a dedicated search step. The goal is awareness: agents learn the folder exists and what's in it, then use their own judgment about when to consult it.\n\n      Examples of calibration (not templates — adapt to the file):\n\n      When there's an existing directory listing or architecture section — add a line:\n      ```\n      docs\u002Fsolutions\u002F  # documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (module, tags, problem_type)\n      ```\n\n      When nothing in the file is a natural fit — a small headed section is appropriate:\n      ```\n      ## Documented Solutions\n\n      `docs\u002Fsolutions\u002F` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`). Relevant when implementing or debugging in documented areas.\n      ```\n   c. In full mode, explain to the user why this matters — agents working in this repo (including fresh sessions, other tools, or collaborators without the plugin) won't know to check `docs\u002Fsolutions\u002F` unless the instruction file surfaces it. Show the proposed change and where it would go, then use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini) to get consent before making the edit. If no question tool is available, present the proposal and wait for the user's reply. In compact-safe mode, output a one-liner note and move on\n\n### Phase 3: Optional Enhancement\n\n**WAIT for Phase 2 to complete before proceeding.**\n\n\u003Cparallel_tasks>\n\nBased on problem type, optionally invoke specialized agents to review the documentation:\n\n- **performance_issue** → `performance-oracle`\n- **security_issue** → `security-sentinel`\n- **database_issue** → `data-integrity-guardian`\n- **test_failure** → `cora-test-reviewer`\n- Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`\n\n\u003C\u002Fparallel_tasks>\n\n---\n\n### Compact-Safe Mode\n\n\u003Ccritical_requirement>\n**Single-pass alternative for context-constrained sessions.**\n\nWhen context budget is tight, this mode skips parallel subagents entirely. The orchestrator performs all work in a single pass, producing a minimal but complete solution document.\n\u003C\u002Fcritical_requirement>\n\nThe orchestrator (main conversation) performs ALL of the following in one sequential pass:\n\n1. **Extract from conversation**: Identify the problem and solution from conversation history. Also read MEMORY.md from the auto memory directory if it exists -- use any relevant notes as supplementary context alongside conversation history. Tag any memory-sourced content incorporated into the final doc with \"(auto memory [claude])\"\n2. **Classify**: Read `references\u002Fschema.yaml` and `references\u002Fyaml-schema.md`, then determine track (bug vs knowledge), category, and filename\n3. **Write minimal doc**: Create `docs\u002Fsolutions\u002F[category]\u002F[filename].md` using the appropriate track template from `assets\u002Fresolution-template.md`, with:\n   - YAML frontmatter with track-appropriate fields\n   - Bug track: Problem, root cause, solution with key code snippets, one prevention tip\n   - Knowledge track: Context, guidance with key examples, one applicability note\n4. **Skip specialized agent reviews** (Phase 3) to conserve context\n\n**Compact-safe output:**\n```\n✓ Documentation complete (compact-safe mode)\n\nFile created:\n- docs\u002Fsolutions\u002F[category]\u002F[filename].md\n\n[If discoverability check found instruction files don't surface the knowledge store:]\nTip: Your AGENTS.md\u002FCLAUDE.md doesn't surface docs\u002Fsolutions\u002F to agents —\na brief mention helps all agents discover these learnings.\n\nNote: This was created in compact-safe mode. For richer documentation\n(cross-references, detailed prevention strategies, specialized reviews),\nre-run \u002Fcompound in a fresh session.\n```\n\n**No subagents are launched. No parallel tasks. One file written.**\n\nIn compact-safe mode, the overlap check is skipped (no Related Docs Finder subagent). This means compact-safe mode may create a doc that overlaps with an existing one. That is acceptable — `ce-compound-refresh` will catch it later. Only suggest `ce-compound-refresh` if there is an obvious narrow refresh target. Do not broaden into a large refresh sweep from a compact-safe session.\n\n---\n\n## What It Captures\n\n- **Problem symptom**: Exact error messages, observable behavior\n- **Investigation steps tried**: What didn't work and why\n- **Root cause analysis**: Technical explanation\n- **Working solution**: Step-by-step fix with code examples\n- **Prevention strategies**: How to avoid in future\n- **Cross-references**: Links to related issues and docs\n\n## Preconditions\n\n\u003Cpreconditions enforcement=\"advisory\">\n  \u003Ccheck condition=\"problem_solved\">\n    Problem has been solved (not in-progress)\n  \u003C\u002Fcheck>\n  \u003Ccheck condition=\"solution_verified\">\n    Solution has been verified working\n  \u003C\u002Fcheck>\n  \u003Ccheck condition=\"non_trivial\">\n    Non-trivial problem (not simple typo or obvious error)\n  \u003C\u002Fcheck>\n\u003C\u002Fpreconditions>\n\n## What It Creates\n\n**Organized documentation:**\n\n- File: `docs\u002Fsolutions\u002F[category]\u002F[filename].md`\n\n**Categories auto-detected from problem:**\n\n- build-errors\u002F\n- test-failures\u002F\n- runtime-errors\u002F\n- performance-issues\u002F\n- database-issues\u002F\n- security-issues\u002F\n- ui-bugs\u002F\n- integration-issues\u002F\n- logic-errors\u002F\n\n## Common Mistakes to Avoid\n\n| ❌ Wrong | ✅ Correct |\n|----------|-----------|\n| Subagents write files like `context-analysis.md`, `solution-draft.md` | Subagents return text data; orchestrator writes one final file |\n| Research and assembly run in parallel | Research completes → then assembly runs |\n| Multiple files created during workflow | One solution doc written or updated: `docs\u002Fsolutions\u002F[category]\u002F[filename].md` (plus an optional small edit to a project instruction file for discoverability) |\n| Creating a new doc when an existing doc covers the same problem | Check overlap assessment; update the existing doc when overlap is high |\n\n## Success Output\n\n```\n✓ Documentation complete\n\nAuto memory: 2 relevant entries used as supplementary evidence\n\nSubagent Results:\n  ✓ Context Analyzer: Identified performance_issue in brief_system, category: performance-issues\u002F\n  ✓ Solution Extractor: 3 code fixes, prevention strategies\n  ✓ Related Docs Finder: 2 related issues\n\nSpecialized Agent Reviews (Auto-Triggered):\n  ✓ performance-oracle: Validated query optimization approach\n  ✓ kieran-rails-reviewer: Code examples meet Rails standards\n  ✓ code-simplicity-reviewer: Solution is appropriately minimal\n  ✓ every-style-editor: Documentation style verified\n\nFile created:\n- docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-brief-generation.md\n\nThis documentation will be searchable for future reference when similar\nissues occur in the Email Processing or Brief System modules.\n\nWhat's next?\n1. Continue workflow (recommended)\n2. Link related documentation\n3. Update other references\n4. View documentation\n5. Other\n```\n\n**After displaying the success output, present the \"What's next?\" options using the platform's blocking question tool** (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the numbered options and wait for the user's reply before proceeding. Do not continue the workflow or end the turn without the user's selection.\n\n**Alternate output (when updating an existing doc due to high overlap):**\n\n```\n✓ Documentation updated (existing doc refreshed with current context)\n\nOverlap detected: docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-queries.md\n  Matched dimensions: problem statement, root cause, solution, referenced files\n  Action: Updated existing doc with fresher code examples and prevention tips\n\nFile updated:\n- docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-queries.md (added last_updated: 2026-03-24)\n```\n\n## The Compounding Philosophy\n\nThis creates a compounding knowledge system:\n\n1. First time you solve \"N+1 query in brief generation\" → Research (30 min)\n2. Document the solution → docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-briefs.md (5 min)\n3. Next time similar issue occurs → Quick lookup (2 min)\n4. Knowledge compounds → Team gets smarter\n\nThe feedback loop:\n\n```\nBuild → Test → Find Issue → Research → Improve → Document → Validate → Deploy\n    ↑                                                                      ↓\n    └──────────────────────────────────────────────────────────────────────┘\n```\n\n**Each unit of engineering work should make subsequent units of work easier—not harder.**\n\n## Auto-Invoke\n\n\u003Cauto_invoke> \u003Ctrigger_phrases> - \"that worked\" - \"it's fixed\" - \"working now\" - \"problem solved\" \u003C\u002Ftrigger_phrases>\n\n\u003Cmanual_override> Use \u002Fce-compound [context] to document immediately without waiting for auto-detection. \u003C\u002Fmanual_override> \u003C\u002Fauto_invoke>\n\n## Output\n\nWrites the final learning directly into `docs\u002Fsolutions\u002F`.\n\n## Applicable Specialized Agents\n\nBased on problem type, these agents can enhance documentation:\n\n### Code Quality & Review\n- **kieran-rails-reviewer**: Reviews code examples for Rails best practices\n- **code-simplicity-reviewer**: Ensures solution code is minimal and clear\n- **pattern-recognition-specialist**: Identifies anti-patterns or repeating issues\n\n### Specific Domain Experts\n- **performance-oracle**: Analyzes performance_issue category solutions\n- **security-sentinel**: Reviews security_issue solutions for vulnerabilities\n- **cora-test-reviewer**: Creates test cases for prevention strategies\n- **data-integrity-guardian**: Reviews database_issue migrations and queries\n\n### Enhancement & Documentation\n- **best-practices-researcher**: Enriches solution with industry best practices\n- **every-style-editor**: Reviews documentation style and clarity\n- **framework-docs-researcher**: Links to Rails\u002Fgem documentation references\n\n### When to Invoke\n- **Auto-triggered** (optional): Agents can run post-documentation for enhancement\n- **Manual trigger**: User can invoke agents after \u002Fce-compound completes for deeper review\n\n## Related Commands\n\n- `\u002Fresearch [topic]` - Deep investigation (searches docs\u002Fsolutions\u002F for patterns)\n- `\u002Fce-plan` - Planning workflow (references documented solutions)\n","# \u002Fcompound\n\nCoordinate multiple subagents working in parallel to document a recently solved problem.\n\n## Purpose\n\nCaptures problem solutions while context is fresh, creating structured documentation in `docs\u002Fsolutions\u002F` with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.\n\n**Why \"compound\"?** Each documented solution compounds your team's knowledge. The first time you solve a problem takes research. Document it, and the next occurrence takes minutes. Knowledge compounds.\n\n## Usage\n\n```bash\n\u002Fce-compound                    # Document the most recent fix\n\u002Fce-compound [brief context]    # Provide additional context hint\n```\n\n## Support Files\n\nThese files are the durable contract for the workflow. Read them on-demand at the step that needs them — do not bulk-load at skill start.\n\n- `references\u002Fschema.yaml` — canonical frontmatter fields and enum values (read when validating YAML)\n- `references\u002Fyaml-schema.md` — category mapping from problem_type to directory (read when classifying)\n- `assets\u002Fresolution-template.md` — section structure for new docs (read when assembling)\n\nWhen spawning subagents, pass the relevant file contents into the task prompt so they have the contract without needing cross-skill paths.\n\n## Execution Strategy\n\n**Always run full mode by default.** Proceed directly to Phase 1 unless the user explicitly requests compact-safe mode (e.g., `\u002Fce-compound --compact` or \"use compact mode\").\n\nCompact-safe mode exists as a lightweight alternative — see the **Compact-Safe Mode** section below. It's there if the user wants it, not something to push.\n\n---\n\n### Full Mode\n\n\u003Ccritical_requirement>\n**The primary output is ONE file - the final documentation.**\n\nPhase 1 subagents return TEXT DATA to the orchestrator. They must NOT use Write, Edit, or create any files. Only the orchestrator writes files: the solution doc in Phase 2, and — if the Discoverability Check finds a gap — a small edit to a project instruction file (AGENTS.md or CLAUDE.md). The instruction-file edit is maintenance, not a second deliverable; it ensures future agents can discover the knowledge store.\n\u003C\u002Fcritical_requirement>\n\n### Phase 0.5: Auto Memory Scan\n\nBefore launching Phase 1 subagents, check the auto memory directory for notes relevant to the problem being documented.\n\n1. Read MEMORY.md from the auto memory directory (the path is known from the system prompt context)\n2. If the directory or MEMORY.md does not exist, is empty, or is unreadable, skip this step and proceed to Phase 1 unchanged\n3. Scan the entries for anything related to the problem being documented -- use semantic judgment, not keyword matching\n4. If relevant entries are found, prepare a labeled excerpt block:\n\n```\n## Supplementary notes from auto memory\nTreat as additional context, not primary evidence. Conversation history\nand codebase findings take priority over these notes.\n\n[relevant entries here]\n```\n\n5. Pass this block as additional context to the Context Analyzer and Solution Extractor task prompts in Phase 1. If any memory notes end up in the final documentation (e.g., as part of the investigation steps or root cause analysis), tag them with \"(auto memory [claude])\" so their origin is clear to future readers.\n\nIf no relevant entries are found, proceed to Phase 1 without passing memory context.\n\n### Phase 1: Parallel Research\n\n\u003Cparallel_tasks>\n\nLaunch these subagents IN PARALLEL. Each returns text data to the orchestrator.\n\n#### 1. **Context Analyzer**\n   - Extracts conversation history\n   - Reads `references\u002Fschema.yaml` for enum validation and **track classification**\n   - Determines the track (bug or knowledge) from the problem_type\n   - Identifies problem type, component, and track-appropriate fields:\n     - **Bug track**: symptoms, root_cause, resolution_type\n     - **Knowledge track**: applies_when (symptoms\u002Froot_cause\u002Fresolution_type optional)\n   - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence\n   - Reads `references\u002Fyaml-schema.md` for category mapping into `docs\u002Fsolutions\u002F`\n   - Suggests a filename using the pattern `[sanitized-problem-slug]-[date].md`\n   - Returns: YAML frontmatter skeleton (must include `category:` field mapped from problem_type), category directory path, suggested filename, and which track applies\n   - Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above\n   - Does not force bug-track fields onto knowledge-track learnings or vice versa\n\n#### 2. **Solution Extractor**\n   - Reads `references\u002Fschema.yaml` for track classification (bug vs knowledge)\n   - Adapts output structure based on the problem_type track\n   - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence -- conversation history and the verified fix take priority; if memory notes contradict the conversation, note the contradiction as cautionary context\n\n   **Bug track output sections:**\n\n   - **Problem**: 1-2 sentence description of the issue\n   - **Symptoms**: Observable symptoms (error messages, behavior)\n   - **What Didn't Work**: Failed investigation attempts and why they failed\n   - **Solution**: The actual fix with code examples (before\u002Fafter when applicable)\n   - **Why This Works**: Root cause explanation and why the solution addresses it\n   - **Prevention**: Strategies to avoid recurrence, best practices, and test cases. Include concrete code examples where applicable (e.g., gem configurations, test assertions, linting rules)\n\n   **Knowledge track output sections:**\n\n   - **Context**: What situation, gap, or friction prompted this guidance\n   - **Guidance**: The practice, pattern, or recommendation with code examples when useful\n   - **Why This Matters**: Rationale and impact of following or not following this guidance\n   - **When to Apply**: Conditions or situations where this applies\n   - **Examples**: Concrete before\u002Fafter or usage examples showing the practice in action\n\n#### 3. **Related Docs Finder**\n   - Searches `docs\u002Fsolutions\u002F` for related documentation\n   - Identifies cross-references and links\n   - Finds related GitHub issues\n   - Flags any related learning or pattern docs that may now be stale, contradicted, or overly broad\n   - **Assesses overlap** with the new doc being created across five dimensions: problem statement, root cause, solution approach, referenced files, and prevention rules. Score as:\n     - **High**: 4-5 dimensions match — essentially the same problem solved again\n     - **Moderate**: 2-3 dimensions match — same area but different angle or solution\n     - **Low**: 0-1 dimensions match — related but distinct\n   - Returns: Links, relationships, refresh candidates, and overlap assessment (score + which dimensions matched)\n\n   **Search strategy (grep-first filtering for efficiency):**\n\n   1. Extract keywords from the problem context: module names, technical terms, error messages, component types\n   2. If the problem category is clear, narrow search to the matching `docs\u002Fsolutions\u002F\u003Ccategory>\u002F` directory\n   3. Use the native content-search tool (e.g., Grep in Claude Code) to pre-filter candidate files BEFORE reading any content. Run multiple searches in parallel, case-insensitive, targeting frontmatter fields. These are template patterns -- substitute actual keywords:\n      - `title:.*\u003Ckeyword>`\n      - `tags:.*(\u003Ckeyword1>|\u003Ckeyword2>)`\n      - `module:.*\u003Cmodule name>`\n      - `component:.*\u003Ccomponent>`\n   4. If search returns >25 candidates, re-run with more specific patterns. If \u003C3, broaden to full content search\n   5. Read only frontmatter (first 30 lines) of candidate files to score relevance\n   6. Fully read only strong\u002Fmoderate matches\n   7. Return distilled links and relationships, not raw file contents\n\n   **GitHub issue search:**\n\n   Prefer the `gh` CLI for searching related issues: `gh issue list --search \"\u003Ckeywords>\" --state all --limit 5`. If `gh` is not installed, fall back to the GitHub MCP tools (e.g., `unblocked` data_retrieval) if available. If neither is available, skip GitHub issue search and note it was skipped in the output.\n\n\u003C\u002Fparallel_tasks>\n\n### Phase 2: Assembly & Write\n\n\u003Csequential_tasks>\n\n**WAIT for all Phase 1 subagents to complete before proceeding.**\n\nThe orchestrating agent (main conversation) performs these steps:\n\n1. Collect all text results from Phase 1 subagents\n2. **Check the overlap assessment** from the Related Docs Finder before deciding what to write:\n\n   | Overlap | Action |\n   |---------|--------|\n   | **High** — existing doc covers the same problem, root cause, and solution | **Update the existing doc** with fresher context (new code examples, updated references, additional prevention tips) rather than creating a duplicate. The existing doc's path and structure stay the same. |\n   | **Moderate** — same problem area but different angle, root cause, or solution | **Create the new doc** normally. Flag the overlap for Phase 2.5 to recommend consolidation review. |\n   | **Low or none** | **Create the new doc** normally. |\n\n   The reason to update rather than create: two docs describing the same problem and solution will inevitably drift apart. The newer context is fresher and more trustworthy, so fold it into the existing doc rather than creating a second one that immediately needs consolidation.\n\n   When updating an existing doc, preserve its file path and frontmatter structure. Update the solution, code examples, prevention tips, and any stale references. Add a `last_updated: YYYY-MM-DD` field to the frontmatter. Do not change the title unless the problem framing has materially shifted.\n\n3. Assemble complete markdown file from the collected pieces, reading `assets\u002Fresolution-template.md` for the section structure of new docs\n4. Validate YAML frontmatter against `references\u002Fschema.yaml`\n5. Create directory if needed: `mkdir -p docs\u002Fsolutions\u002F[category]\u002F`\n6. Write the file: either the updated existing doc or the new `docs\u002Fsolutions\u002F[category]\u002F[filename].md`\n\nWhen creating a new doc, preserve the section order from `assets\u002Fresolution-template.md` unless the user explicitly asks for a different structure.\n\n\u003C\u002Fsequential_tasks>\n\n### Phase 2.5: Selective Refresh Check\n\nAfter writing the new learning, decide whether this new solution is evidence that older docs should be refreshed.\n\n`ce-compound-refresh` is **not** a default follow-up. Use it selectively when the new learning suggests an older learning or pattern doc may now be inaccurate.\n\nIt makes sense to invoke `ce-compound-refresh` when one or more of these are true:\n\n1. A related learning or pattern doc recommends an approach that the new fix now contradicts\n2. The new fix clearly supersedes an older documented solution\n3. The current work involved a refactor, migration, rename, or dependency upgrade that likely invalidated references in older docs\n4. A pattern doc now looks overly broad, outdated, or no longer supported by the refreshed reality\n5. The Related Docs Finder surfaced high-confidence refresh candidates in the same problem space\n6. The Related Docs Finder reported **moderate overlap** with an existing doc — there may be consolidation opportunities that benefit from a focused review\n\nIt does **not** make sense to invoke `ce-compound-refresh` when:\n\n1. No related docs were found\n2. Related docs still appear consistent with the new learning\n3. The overlap is superficial and does not change prior guidance\n4. Refresh would require a broad historical review with weak evidence\n\nUse these rules:\n\n- If there is **one obvious stale candidate**, invoke `ce-compound-refresh` with a narrow scope hint after the new learning is written\n- If there are **multiple candidates in the same area**, ask the user whether to run a targeted refresh for that module, category, or pattern set\n- If context is already tight or you are in compact-safe mode, do not expand into a broad refresh automatically; instead recommend `ce-compound-refresh` as the next step with a scope hint\n\nWhen invoking or recommending `ce-compound-refresh`, be explicit about the argument to pass. Prefer the narrowest useful scope:\n\n- **Specific file** when one learning or pattern doc is the likely stale artifact\n- **Module or component name** when several related docs may need review\n- **Category name** when the drift is concentrated in one solutions area\n- **Pattern filename or pattern topic** when the stale guidance lives in `docs\u002Fsolutions\u002Fpatterns\u002F`\n\nExamples:\n\n- `\u002Fce-compound-refresh plugin-versioning-requirements`\n- `\u002Fce-compound-refresh payments`\n- `\u002Fce-compound-refresh performance-issues`\n- `\u002Fce-compound-refresh critical-patterns`\n\nA single scope hint may still expand to multiple related docs when the change is cross-cutting within one domain, category, or pattern area.\n\nDo not invoke `ce-compound-refresh` without an argument unless the user explicitly wants a broad sweep.\n\nAlways capture the new learning first. Refresh is a targeted maintenance follow-up, not a prerequisite for documentation.\n\n### Discoverability Check\n\nAfter the learning is written and the refresh decision is made, check whether the project's instruction files would lead an agent to discover and search `docs\u002Fsolutions\u002F` before starting work in a documented area. This runs every time — the knowledge store only compounds value when agents can find it.\n\n1. Identify which root-level instruction files exist (AGENTS.md, CLAUDE.md, or both). Read the file(s) and determine which holds the substantive content — one file may just be a shim that `@`-includes the other (e.g., `CLAUDE.md` containing only `@AGENTS.md`, or vice versa). The substantive file is the assessment and edit target; ignore shims. If neither file exists, skip this check entirely.\n2. Assess whether an agent reading the instruction files would learn three things:\n   - That a searchable knowledge store of documented solutions exists\n   - Enough about its structure to search effectively (category organization, YAML frontmatter fields like `module`, `tags`, `problem_type`)\n   - When to search it (before implementing features, debugging issues, or making decisions in documented areas — learnings may cover bugs, best practices, workflow patterns, or other institutional knowledge)\n\n   This is a semantic assessment, not a string match. The information could be a line in an architecture section, a bullet in a gotchas section, spread across multiple places, or expressed without ever using the exact path `docs\u002Fsolutions\u002F`. Use judgment — if an agent would reasonably discover and use the knowledge store after reading the file, the check passes.\n\n3. If the spirit is already met, no action needed — move on.\n4. If not:\n   a. Based on the file's existing structure, tone, and density, identify where a mention fits naturally. Before creating a new section, check whether the information could be a single line in the closest related section — an architecture tree, a directory listing, a documentation section, or a conventions block. A line added to an existing section is almost always better than a new headed section. Only add a new section as a last resort when the file has clear sectioned structure and nothing is even remotely related.\n   b. Draft the smallest addition that communicates the three things. Match the file's existing style and density. The addition should describe the knowledge store itself, not the plugin — an agent without the plugin should still find value in it.\n\n      Keep the tone informational, not imperative. Express timing as description, not instruction — \"relevant when implementing or debugging in documented areas\" rather than \"check before implementing or debugging.\" Imperative directives like \"always search before implementing\" cause redundant reads when a workflow already includes a dedicated search step. The goal is awareness: agents learn the folder exists and what's in it, then use their own judgment about when to consult it.\n\n      Examples of calibration (not templates — adapt to the file):\n\n      When there's an existing directory listing or architecture section — add a line:\n      ```\n      docs\u002Fsolutions\u002F  # documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (module, tags, problem_type)\n      ```\n\n      When nothing in the file is a natural fit — a small headed section is appropriate:\n      ```\n      ## Documented Solutions\n\n      `docs\u002Fsolutions\u002F` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`). Relevant when implementing or debugging in documented areas.\n      ```\n   c. In full mode, explain to the user why this matters — agents working in this repo (including fresh sessions, other tools, or collaborators without the plugin) won't know to check `docs\u002Fsolutions\u002F` unless the instruction file surfaces it. Show the proposed change and where it would go, then use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini) to get consent before making the edit. If no question tool is available, present the proposal and wait for the user's reply. In compact-safe mode, output a one-liner note and move on\n\n### Phase 3: Optional Enhancement\n\n**WAIT for Phase 2 to complete before proceeding.**\n\n\u003Cparallel_tasks>\n\nBased on problem type, optionally invoke specialized agents to review the documentation:\n\n- **performance_issue** → `performance-oracle`\n- **security_issue** → `security-sentinel`\n- **database_issue** → `data-integrity-guardian`\n- **test_failure** → `cora-test-reviewer`\n- Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`\n\n\u003C\u002Fparallel_tasks>\n\n---\n\n### Compact-Safe Mode\n\n\u003Ccritical_requirement>\n**Single-pass alternative for context-constrained sessions.**\n\nWhen context budget is tight, this mode skips parallel subagents entirely. The orchestrator performs all work in a single pass, producing a minimal but complete solution document.\n\u003C\u002Fcritical_requirement>\n\nThe orchestrator (main conversation) performs ALL of the following in one sequential pass:\n\n1. **Extract from conversation**: Identify the problem and solution from conversation history. Also read MEMORY.md from the auto memory directory if it exists -- use any relevant notes as supplementary context alongside conversation history. Tag any memory-sourced content incorporated into the final doc with \"(auto memory [claude])\"\n2. **Classify**: Read `references\u002Fschema.yaml` and `references\u002Fyaml-schema.md`, then determine track (bug vs knowledge), category, and filename\n3. **Write minimal doc**: Create `docs\u002Fsolutions\u002F[category]\u002F[filename].md` using the appropriate track template from `assets\u002Fresolution-template.md`, with:\n   - YAML frontmatter with track-appropriate fields\n   - Bug track: Problem, root cause, solution with key code snippets, one prevention tip\n   - Knowledge track: Context, guidance with key examples, one applicability note\n4. **Skip specialized agent reviews** (Phase 3) to conserve context\n\n**Compact-safe output:**\n```\n✓ Documentation complete (compact-safe mode)\n\nFile created:\n- docs\u002Fsolutions\u002F[category]\u002F[filename].md\n\n[If discoverability check found instruction files don't surface the knowledge store:]\nTip: Your AGENTS.md\u002FCLAUDE.md doesn't surface docs\u002Fsolutions\u002F to agents —\na brief mention helps all agents discover these learnings.\n\nNote: This was created in compact-safe mode. For richer documentation\n(cross-references, detailed prevention strategies, specialized reviews),\nre-run \u002Fcompound in a fresh session.\n```\n\n**No subagents are launched. No parallel tasks. One file written.**\n\nIn compact-safe mode, the overlap check is skipped (no Related Docs Finder subagent). This means compact-safe mode may create a doc that overlaps with an existing one. That is acceptable — `ce-compound-refresh` will catch it later. Only suggest `ce-compound-refresh` if there is an obvious narrow refresh target. Do not broaden into a large refresh sweep from a compact-safe session.\n\n---\n\n## What It Captures\n\n- **Problem symptom**: Exact error messages, observable behavior\n- **Investigation steps tried**: What didn't work and why\n- **Root cause analysis**: Technical explanation\n- **Working solution**: Step-by-step fix with code examples\n- **Prevention strategies**: How to avoid in future\n- **Cross-references**: Links to related issues and docs\n\n## Preconditions\n\n\u003Cpreconditions enforcement=\"advisory\">\n  \u003Ccheck condition=\"problem_solved\">\n    Problem has been solved (not in-progress)\n  \u003C\u002Fcheck>\n  \u003Ccheck condition=\"solution_verified\">\n    Solution has been verified working\n  \u003C\u002Fcheck>\n  \u003Ccheck condition=\"non_trivial\">\n    Non-trivial problem (not simple typo or obvious error)\n  \u003C\u002Fcheck>\n\u003C\u002Fpreconditions>\n\n## What It Creates\n\n**Organized documentation:**\n\n- File: `docs\u002Fsolutions\u002F[category]\u002F[filename].md`\n\n**Categories auto-detected from problem:**\n\n- build-errors\u002F\n- test-failures\u002F\n- runtime-errors\u002F\n- performance-issues\u002F\n- database-issues\u002F\n- security-issues\u002F\n- ui-bugs\u002F\n- integration-issues\u002F\n- logic-errors\u002F\n\n## Common Mistakes to Avoid\n\n| ❌ Wrong | ✅ Correct |\n|----------|-----------|\n| Subagents write files like `context-analysis.md`, `solution-draft.md` | Subagents return text data; orchestrator writes one final file |\n| Research and assembly run in parallel | Research completes → then assembly runs |\n| Multiple files created during workflow | One solution doc written or updated: `docs\u002Fsolutions\u002F[category]\u002F[filename].md` (plus an optional small edit to a project instruction file for discoverability) |\n| Creating a new doc when an existing doc covers the same problem | Check overlap assessment; update the existing doc when overlap is high |\n\n## Success Output\n\n```\n✓ Documentation complete\n\nAuto memory: 2 relevant entries used as supplementary evidence\n\nSubagent Results:\n  ✓ Context Analyzer: Identified performance_issue in brief_system, category: performance-issues\u002F\n  ✓ Solution Extractor: 3 code fixes, prevention strategies\n  ✓ Related Docs Finder: 2 related issues\n\nSpecialized Agent Reviews (Auto-Triggered):\n  ✓ performance-oracle: Validated query optimization approach\n  ✓ kieran-rails-reviewer: Code examples meet Rails standards\n  ✓ code-simplicity-reviewer: Solution is appropriately minimal\n  ✓ every-style-editor: Documentation style verified\n\nFile created:\n- docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-brief-generation.md\n\nThis documentation will be searchable for future reference when similar\nissues occur in the Email Processing or Brief System modules.\n\nWhat's next?\n1. Continue workflow (recommended)\n2. Link related documentation\n3. Update other references\n4. View documentation\n5. Other\n```\n\n**After displaying the success output, present the \"What's next?\" options using the platform's blocking question tool** (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the numbered options and wait for the user's reply before proceeding. Do not continue the workflow or end the turn without the user's selection.\n\n**Alternate output (when updating an existing doc due to high overlap):**\n\n```\n✓ Documentation updated (existing doc refreshed with current context)\n\nOverlap detected: docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-queries.md\n  Matched dimensions: problem statement, root cause, solution, referenced files\n  Action: Updated existing doc with fresher code examples and prevention tips\n\nFile updated:\n- docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-queries.md (added last_updated: 2026-03-24)\n```\n\n## The Compounding Philosophy\n\nThis creates a compounding knowledge system:\n\n1. First time you solve \"N+1 query in brief generation\" → Research (30 min)\n2. Document the solution → docs\u002Fsolutions\u002Fperformance-issues\u002Fn-plus-one-briefs.md (5 min)\n3. Next time similar issue occurs → Quick lookup (2 min)\n4. Knowledge compounds → Team gets smarter\n\nThe feedback loop:\n\n```\nBuild → Test → Find Issue → Research → Improve → Document → Validate → Deploy\n    ↑                                                                      ↓\n    └──────────────────────────────────────────────────────────────────────┘\n```\n\n**Each unit of engineering work should make subsequent units of work easier—not harder.**\n\n## Auto-Invoke\n\n\u003Cauto_invoke> \u003Ctrigger_phrases> - \"that worked\" - \"it's fixed\" - \"working now\" - \"problem solved\" \u003C\u002Ftrigger_phrases>\n\n\u003Cmanual_override> Use \u002Fce-compound [context] to document immediately without waiting for auto-detection. \u003C\u002Fmanual_override> \u003C\u002Fauto_invoke>\n\n## Output\n\nWrites the final learning directly into `docs\u002Fsolutions\u002F`.\n\n## Applicable Specialized Agents\n\nBased on problem type, these agents can enhance documentation:\n\n### Code Quality & Review\n- **kieran-rails-reviewer**: Reviews code examples for Rails best practices\n- **code-simplicity-reviewer**: Ensures solution code is minimal and clear\n- **pattern-recognition-specialist**: Identifies anti-patterns or repeating issues\n\n### Specific Domain Experts\n- **performance-oracle**: Analyzes performance_issue category solutions\n- **security-sentinel**: Reviews security_issue solutions for vulnerabilities\n- **cora-test-reviewer**: Creates test cases for prevention strategies\n- **data-integrity-guardian**: Reviews database_issue migrations and queries\n\n### Enhancement & Documentation\n- **best-practices-researcher**: Enriches solution with industry best practices\n- **every-style-editor**: Reviews documentation style and clarity\n- **framework-docs-researcher**: Links to Rails\u002Fgem documentation references\n\n### When to Invoke\n- **Auto-triggered** (optional): Agents can run post-documentation for enhancement\n- **Manual trigger**: User can invoke agents after \u002Fce-compound completes for deeper review\n\n## Related Commands\n\n- `\u002Fresearch [topic]` - Deep investigation (searches docs\u002Fsolutions\u002F for patterns)\n- `\u002Fce-plan` - Planning workflow (references documented solutions)\n",{"name":5,"description":7},"main","0256fccfa68825bb93a1b37467a7377bd34280af",".github\u002Fskills\u002Fce-compound",1,"https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123","Engineer, Printf Debugger, Vibe Coder, AI Enthusiast","2026-08-25 22:42:12",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add shyamsridhar123\u002Fkevin-copilot --skill ce-compound",{"tool":49,"command":50},"bunx","bunx skills add shyamsridhar123\u002Fkevin-copilot --skill ce-compound",{"tool":52,"command":53},"pnpm","pnpm dlx skills add shyamsridhar123\u002Fkevin-copilot --skill ce-compound","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fce-compound\u002FSKILL.md",true,[57,63,69],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"assets\u002Fresolution-template.md","ASSET","资产文件",1996,"https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fce-compound\u002Fassets\u002Fresolution-template.md",{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fschema.yaml","REFERENCE","参考文档",6980,"https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fce-compound\u002Freferences\u002Fschema.yaml",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fyaml-schema.md",4511,"https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fce-compound\u002Freferences\u002Fyaml-schema.md",[74,90,109,123,141,154],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":30},"01M71EW4N5RQ70SERKYZB2GBDM","kevin-review","Review a diff and emit concise, evidence-backed findings.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-review\u002FSKILL.md",[],[81,82,83,84,85,86,87,88,89],"kevin review","review","request","concise","evidence","diff","branch","pull","pull request",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":30},"01M71EW36CP1KVDES6KGB8APZZ","kevin-merit","Audit a diff for over-engineering and report it as a corporate merit cycle. Satire; the subject is the code, never a person.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-merit\u002FSKILL.md",[],[97,86,89,98,99,88,100,101,87,102,103,104,105,106,107,108,83],"kevin merit","code","report","audit","engineering","never","cycle","as","it","corporate","for","person",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":30},"01M71EW0YHNR57136MENKW4YSD","kevin-help","Show Kevin modes, commands, and runtime controls.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-help\u002FSKILL.md",[],[116,117,118,119,120,121,122],"kevin help","help","commands","modes","show","runtime","controls",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":30},"01M71EVYYH5QASNZ1KB6C3GMDJ","kevin-enlighten","Explain a topic to someone with no background as a self-contained HTML picture explainer.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-enlighten\u002FSKILL.md",[],[130,131,132,133,134,135,136,104,137,138,139,140],"kevin enlighten","enlighten","repository","explainer","explain","html","self","with","path","self-contained","background",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":30},"01M71EVX29VAGHZJZKAKQ97M7X","kevin-compress","Compress an answer without losing required information or safety warnings.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-compress\u002FSKILL.md",[],[148,149,150,151,152,153],"kevin compress","compress","Safety","text","information","answer",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":30},"01M71EVVDWF888W10KA0D3N4W5","kevin-commit","Generate a terse Conventional Commits message from the staged diff.","https:\u002F\u002Fgithub.com\u002Fshyamsridhar123\u002Fkevin-copilot\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fkevin-commit\u002FSKILL.md",[],[161,162,163,164,86,165,166,167,168,169],"commit","kevin commit","generate","commits","conventional commits","message","focus","staged","terse"]