compound
Document solved problems to compound team knowledge. Creates categorized docs with YAML frontmatter. Triggers on "that worked", "it's fixed", "compound".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Document solved problems to compound team knowledge. Creates categorized docs with YAML frontmatter. Triggers on "that worked", "it's fixed", "compound".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Research codebase, validate external claims, and emit a work-ready spec.json for a new planning session. Single-pass creation with integrated validation via Context7 and locator/analyzer agents. Triggers on "create plan", "plan for", "write a plan". For exploratory requests where the user is unsure what to build, prefer brainstorm first. Once spec.json exists, use plan-review for evaluation or go straight to work. For a reviewed spec, use plan-consolidation to merge findings.
Execute spec.json (plan mode) or review.findings.json (fix-findings mode) by dispatching subagents per chunk. Triggers on "work on", "implement", "execute plan", "carry on", "continue".
Shared conventions for Flywheel subagents. Tool discipline, output format, research patterns.
Perform exhaustive code reviews using multi-agent analysis. Reviews PRs, branches, or current changes. Writes review.findings.json to the active session. Triggers on "review", "code review", "check PR".
Refine the active session's spec.json by merging reviewer findings.json into it. Backs up the pre-refinement spec to a .pre-consolidation sidecar. Triggers on "consolidate plan", "finalize plan".
Run ALL reviewer agents in parallel against a plan. Deduplicates findings semantically and writes findings.json to the active session. Triggers on "review plan", "check plan".
| name | compound |
| description | Document solved problems to compound team knowledge. Creates categorized docs with YAML frontmatter. Triggers on "that worked", "it's fixed", "compound". |
| allowed-tools | ["Read","Write","Bash","Grep","Task","AskUserQuestion"] |
Document solved problems to build searchable institutional knowledge.
Why "compound"? Each documented solution compounds your team's knowledge like compound interest. First time solving a problem takes research. Document it, and the next occurrence takes minutes.
Compounding vs Compaction: Flywheel uses two strategies (see README):
progress.json checkpoints, structured spec.json.context arrays)Preconditions:
Organization: Single-file per problem in category directory (e.g., docs/solutions/performance-issues/n-plus-one-query.md).
Auto-invoke after: "that worked", "it's fixed", "working now", "problem solved"
OR manual: /compound command
Non-trivial problems only:
Skip: Simple typos, obvious syntax errors, trivial fixes.
Additional categories:
pattern = Successful approach worth reusing → docs/solutions/patterns/mistake = Failed approach with prevention guidance → docs/solutions/mistakes/When invoked after 3-Strike escalation (error resolved with user help), capture:
This creates institutional memory from hard-won debugging sessions.
Extract from conversation history:
If critical context missing, ask user:
I need a few details to document this:
1. Which module/component?
2. What was the exact error?
3. What environment?
On first compound creation in a repo, offer to add a one-line pointer to docs/solutions/ in AGENTS.md or CLAUDE.md so future agents find the knowledge store.
Detection: ls docs/solutions/ 2>/dev/null | wc -l returns 0 AND neither AGENTS.md nor CLAUDE.md has a grep hit for docs/solutions.
If detected, AskUserQuestion: "No existing solutions directory detected. Add a one-line pointer to docs/solutions/ in AGENTS.md or CLAUDE.md so future agents find it?"
Add to AGENTS.md / Add to CLAUDE.md / SkipOn yes, Edit the chosen file to append: Past solutions & compound learnings live in `docs/solutions/`.
grep -r "exact error phrase" docs/solutions/
If similar found: Ask whether to create new doc with cross-reference or update existing.
If none: Proceed.
Before documenting, sanitize sensitive data:
[internal-url]Then validate against references/yaml-schema.md:
Determine category from problem_type, create file:
mkdir -p "docs/solutions/${CATEGORY}"
Write using template from references/resolution-template.md.
For complex issues, invoke relevant reviewer:
| Problem Type | Reviewer |
|---|---|
| performance_issue | reviewer-performance |
| database_issue | reviewer-data-integrity |
Only if the problem was particularly tricky or affects critical systems.
After documenting the solution, check if this pattern generalizes:
# Search for solutions with similar tags or problem types
grep -rl "<root-cause-keyword>" docs/solutions/ | head -5
If 2+ solutions share the same root cause type or pattern (e.g., same type of fix in the same component area), suggest creating a standard:
AskUserQuestion: "This pattern appears in [N] solutions ([list filenames]). Capture as a reusable standard?"
docs/standards/<pattern-name>.md per the format in docs/standards/README.md, user confirms contentOnly suggest when the pattern is clearly reusable, not when solutions happen to touch the same file.
Per references/decision-menu.md:
✓ Solution documented
File: docs/solutions/[category]/[filename].md
What's next?
1. Continue workflow (recommended)
2. Add to Required Reading
3. Link related issues
4. View documentation
5. Other
references/yaml-schema.md - YAML fields, enums, category mappingreferences/resolution-template.md - File template, filename rulesreferences/decision-menu.md - Post-documentation options