Menu
Document a recently solved problem to compound your team's knowledge
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
Run comprehensive agent-native architecture review with scored principles
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. Also use when a user describes a vague or ambitious feature request, asks 'what should we build', 'help me think through X', presents a problem with multiple valid solutions, or seems unsure about scope or direction — even if they don't explicitly ask to brainstorm.
Refresh stale or drifting learnings and pattern docs in docs/solutions/ by reviewing, updating, replacing, or archiving them against the current codebase. Use after refactors, migrations, dependency upgrades, or when a retrieved learning feels outdated or wrong. Also use when reviewing docs/solutions/ for accuracy, when a recently solved problem contradicts an existing learning, or when pattern docs no longer reflect current code.
Generate and critically evaluate grounded improvement ideas for the current project. Use when asking what to improve, requesting idea generation, exploring surprising improvements, or wanting the AI to proactively suggest strong project directions before brainstorming one in depth. Triggers on phrases like 'what should I improve', 'give me ideas', 'ideate on this project', 'surprise me with improvements', 'what would you change', or any request for AI-generated project improvement suggestions rather than refining the user's own idea.
Transform feature descriptions or requirements into structured implementation plans grounded in repo patterns and research. Use when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', or when a brainstorm/requirements document is ready for technical planning. Best when requirements are at least roughly defined; for exploratory or ambiguous requests, prefer ce:brainstorm first.
| name | ce:compound |
| description | Document a recently solved problem to compound your team's knowledge |
| argument-hint | [optional: brief context about the fix] |
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)