with one click
compound
// Document a solved problem as reusable institutional knowledge with parallel research. Use when the user says 'document this', 'compound', 'save learnings', or wants to capture a solution for future reference.
// Document a solved problem as reusable institutional knowledge with parallel research. Use when the user says 'document this', 'compound', 'save learnings', or wants to capture a solution for future reference.
Explore requirements and approaches through collaborative dialogue before writing a right-sized requirements document and planning implementation. Use for feature ideas, problem framing, when the user says 'let's brainstorm', or when they want to think through options before deciding what to build.
Research the codebase and create a structured implementation plan. Use when the user says 'plan this', 'create a plan', 'how should we implement', or wants to turn a feature description into a structured implementation plan.
Scaffold a new custom agent — reviewers, researchers, or workflow agents. Use when asked to create, scaffold, or add a new agent.
Enhance an existing plan with parallel research agents for depth, best practices, and implementation details. Use when the user says 'deepen the plan', 'research more', or when a plan has high-risk dimensions that need more investigation.
Review requirements or plan documents using parallel persona agents that surface role-specific issues. Use when a requirements document or plan document exists and the user wants to improve it, or when invoked by /cplan for quality gating.
Commit, push, and open a PR with an adaptive, value-first description. Use when the user says "commit and PR", "push and open a PR", "ship this", "create a PR", "open a pull request", or wants to go from working changes to an open pull request in one step. Also handles "update the PR description" or "refresh the PR description".
| name | compound |
| description | Document a solved problem as reusable institutional knowledge with parallel research. Use when the user says 'document this', 'compound', 'save learnings', or wants to capture a solution for future reference. |
| argument-hint | Brief context about the problem you just solved (optional) |
Coordinate multiple subagents working in parallel to document a recently solved problem. Creates structured documentation in docs/solutions/ with YAML frontmatter for searchability and future reference.
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.
This skill dispatches these subagents in parallel:
cexplore — codebase context analysisclearnings — searches docs/solutions/ for related documentationThese 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.
Skill-local references (always available alongside this skill):
compound.references/category-guide.md — category mapping, required frontmatter, validation rules, filename conventions (read when classifying)compound.references/solution-template.md — section structure for bug track and knowledge track docs (read when assembling)Project-level references (created by installer, may not exist in all projects):
docs/solutions/references/schema.yaml — canonical frontmatter fields and enum values (read when validating YAML, fall back to category-guide.md if missing)docs/solutions/references/yaml-schema.md — category mapping from problem_type to directory (fall back to category-guide.md if missing)docs/solutions/assets/resolution-template.md — section structure for new docs (fall back to solution-template.md if missing)When spawning subagents, pass the relevant file contents into the task prompt so they have the contract without needing cross-skill paths.
Launch these subagents in parallel. Each returns text data to the orchestrator. Subagents must NOT create, edit, or write any files.
docs/solutions/references/schema.yaml for enum validation and track classificationbuild_error, test_failure, runtime_error, performance_issue, database_issue, security_issue, ui_bug, integration_issue, logic_errorbest_practice, documentation_gap, workflow_issue, developer_experiencedocs/solutions/references/yaml-schema.md for category mapping into docs/solutions/[sanitized-problem-slug]-[date].mdcategory: field mapped from problem_type), category directory path, suggested filename, and which track appliesdocs/solutions/references/schema.yaml for track classification (bug vs knowledge)Bug track output sections:
Knowledge track output sections:
clearnings subagent)docs/solutions/ for related documentationSearch strategy:
docs/solutions/<category>/ directoryWait for all Phase 1 subagents to complete before proceeding.
The orchestrating skill performs these steps:
Collect all text results from Phase 1 subagents
Check the overlap assessment from the Related Docs Finder before deciding what to write:
| Overlap | Action |
|---|---|
| High — existing doc covers the same problem and solution | Update the existing doc with fresher context rather than creating a duplicate. Preserve its file path and structure. Add last_updated: YYYY-MM-DD to frontmatter. |
| Moderate — same area but different angle or solution | Create the new doc normally. Note the overlap for potential future consolidation. |
| Low or none | Create the new doc normally. |
Read docs/solutions/assets/resolution-template.md for section structure
Assemble complete markdown file from collected pieces
Validate YAML frontmatter against docs/solutions/references/schema.yaml
Create directory if needed: docs/solutions/[category]/
Write the file: either the updated existing doc or the new docs/solutions/[category]/[filename].md
Preserve the section order from the resolution template unless the user explicitly asks for a different structure.
After writing the new learning, decide whether older docs should be refreshed.
It makes sense to suggest a refresh when:
It does not make sense when:
If stale candidates are found, inform the user and suggest which specific docs may need updating.
After writing the doc, present a summary:
Documentation complete:
Subagent Results:
- Context Analyzer: [summary]
- Solution Extractor: [summary]
- Related Docs Finder: [summary]
File created/updated:
- docs/solutions/[category]/[filename].md
This will be searchable for future reference when similar issues occur.
Use #askQuestions to ask what the user wants to do next:
| Option | When to show |
|---|---|
Ship It (Recommended) — load the /git-commit-push-pr skill | When there's code to ship |
| Link related documentation — update cross-references | When moderate overlap was found |
| Update other references — refresh stale docs | When stale docs were flagged |
| Done — end the workflow | Always |
After the user picks a next skill, announce the handover and load the chosen skill.
docs/solutions/Build -> Test -> Find Issue -> Research -> Improve -> Document -> Deploy
^ |
+------------------------------------------------------------------+
Each unit of engineering work should make subsequent units easier — not harder.