From compound-engineering
Document a recently solved problem to compound your team's knowledge
npx claudepluginhub apollostreetcompany/codex-compound --plugin compound-engineeringThis skill uses the workspace's default tool permissions.
Coordinate multiple subagents working in parallel to document a recently solved problem.
Coordinates subagents to document recently solved problems into searchable YAML-frontmatter Markdown files in docs/solutions/ while context is fresh.
Coordinates parallel subagents to document recent problem solutions as structured Markdown with YAML frontmatter in docs/solutions/ for team knowledge retention.
Coordinates parallel subagents to document recently solved problems into searchable YAML-frontmatter Markdown files in docs/solutions/. Offers full research/cross-reference mode or lightweight single-pass.
Share bugs, ideas, or general feedback.
Coordinate multiple subagents working in parallel to document a recently solved problem.
Captures problem solutions while context is fresh, creating structured documentation in docs/solutions/ with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.
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.
/ce:compound # Document the most recent fix
/ce:compound [brief context] # Provide additional context hint
Always run full mode by default. Proceed directly to Phase 1 unless the user explicitly requests compact-safe mode (e.g., /ce:compound --compact or "use compact mode").
Compact-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.
<critical_requirement> Only ONE file gets written - the final documentation.
Phase 1 subagents return TEXT DATA to the orchestrator. They must NOT use Write, Edit, or create any files. Only the orchestrator (Phase 2) writes the final documentation file. </critical_requirement>
Before launching Phase 1 subagents, check the auto memory directory for notes relevant to the problem being documented.
## Supplementary notes from auto memory
Treat as additional context, not primary evidence. Conversation history
and codebase findings take priority over these notes.
[relevant entries here]
If no relevant entries are found, proceed to Phase 1 without passing memory context.
<parallel_tasks>
Launch these subagents IN PARALLEL. Each returns text data to the orchestrator.
docs/solutions/ for related documentationdocs/solutions/ category</parallel_tasks>
<sequential_tasks>
WAIT for all Phase 1 subagents to complete before proceeding.
The orchestrating agent (main conversation) performs these steps:
mkdir -p docs/solutions/[category]/docs/solutions/[category]/[filename].md</sequential_tasks>
After writing the new learning, decide whether this new solution is evidence that older docs should be refreshed.
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.
It makes sense to invoke ce:compound-refresh when one or more of these are true:
It does not make sense to invoke ce:compound-refresh when:
Use these rules:
ce:compound-refresh with a narrow scope hint after the new learning is writtence:compound-refresh as the next step with a scope hintWhen invoking or recommending ce:compound-refresh, be explicit about the argument to pass. Prefer the narrowest useful scope:
docs/solutions/patterns/Examples:
/ce:compound-refresh plugin-versioning-requirements/ce:compound-refresh payments/ce:compound-refresh performance-issues/ce:compound-refresh critical-patternsA single scope hint may still expand to multiple related docs when the change is cross-cutting within one domain, category, or pattern area.
Do not invoke ce:compound-refresh without an argument unless the user explicitly wants a broad sweep.
Always capture the new learning first. Refresh is a targeted maintenance follow-up, not a prerequisite for documentation.
WAIT for Phase 2 to complete before proceeding.
<parallel_tasks>
Based on problem type, optionally invoke specialized agents to review the documentation:
performance-oraclesecurity-sentineldata-integrity-guardiancora-test-reviewerkieran-rails-reviewer + code-simplicity-reviewer</parallel_tasks>
<critical_requirement> Single-pass alternative for context-constrained sessions.
When 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. </critical_requirement>
The orchestrator (main conversation) performs ALL of the following in one sequential pass:
docs/solutions/[category]/[filename].md with:
Compact-safe output:
✓ Documentation complete (compact-safe mode)
File created:
- docs/solutions/[category]/[filename].md
Note: This was created in compact-safe mode. For richer documentation
(cross-references, detailed prevention strategies, specialized reviews),
re-run /compound in a fresh session.
No subagents are launched. No parallel tasks. One file written.
In compact-safe mode, 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.
Organized documentation:
docs/solutions/[category]/[filename].mdCategories auto-detected from problem:
| ❌ Wrong | ✅ Correct |
|---|---|
Subagents write files like context-analysis.md, solution-draft.md | Subagents return text data; orchestrator writes one final file |
| Research and assembly run in parallel | Research completes → then assembly runs |
| Multiple files created during workflow | Single file: docs/solutions/[category]/[filename].md |
✓ Documentation complete
Auto memory: 2 relevant entries used as supplementary evidence
Subagent Results:
✓ Context Analyzer: Identified performance_issue in brief_system
✓ Solution Extractor: 3 code fixes
✓ Related Docs Finder: 2 related issues
✓ Prevention Strategist: Prevention strategies, test suggestions
✓ Category Classifier: `performance-issues`
Specialized Agent Reviews (Auto-Triggered):
✓ performance-oracle: Validated query optimization approach
✓ kieran-rails-reviewer: Code examples meet Rails standards
✓ code-simplicity-reviewer: Solution is appropriately minimal
✓ every-style-editor: Documentation style verified
File created:
- docs/solutions/performance-issues/n-plus-one-brief-generation.md
This documentation will be searchable for future reference when similar
issues occur in the Email Processing or Brief System modules.
What's next?
1. Continue workflow (recommended)
2. Link related documentation
3. Update other references
4. View documentation
5. Other
This creates a compounding knowledge system:
The feedback loop:
Build → Test → Find Issue → Research → Improve → Document → Validate → Deploy
↑ ↓
└──────────────────────────────────────────────────────────────────────┘
Each unit of engineering work should make subsequent units of work easier—not harder.
<auto_invoke> <trigger_phrases> - "that worked" - "it's fixed" - "working now" - "problem solved" </trigger_phrases>
<manual_override> Use /ce:compound [context] to document immediately without waiting for auto-detection. </manual_override> </auto_invoke>
compound-docs skill
Based on problem type, these agents can enhance documentation:
compound-engineering.local.md or invoke the setup skill to configure which review agents are used across all workflows/research [topic] - Deep investigation (searches docs/solutions/ for patterns)/ce:plan - Planning workflow (references documented solutions)