/ce-compound

Coordinate multiple subagents working in parallel to document a recently solved problem.

Purpose

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.

Usage

/ce-compound                    # Document the most recent fix
/ce-compound [brief context]    # Provide additional context hint

Support Files

These 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.

• references/schema.yaml — canonical frontmatter fields and enum values (read when validating YAML)
• references/yaml-schema.md — category mapping from problem_type to directory (read when classifying)
• assets/resolution-template.md — section structure for new docs (read when assembling)

When spawning subagents, pass the relevant file contents into the task prompt so they have the contract without needing cross-skill paths.

Execution Strategy

Present the user with two options before proceeding, using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension). Fall back to presenting options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

1. Full (recommended) — the complete compound workflow. Researches,
   cross-references, and reviews your solution to produce documentation
   that compounds your team's knowledge.

2. Lightweight — same documentation, single pass. Faster and uses
   fewer tokens, but won't detect duplicates or cross-reference
   existing docs. Best for simple fixes or long sessions nearing
   context limits.

Do NOT pre-select a mode. Do NOT skip this prompt. Wait for the user's choice before proceeding.

If the user chooses Full, ask one follow-up question before proceeding. Detect which harness is running (Claude Code, Codex, or Cursor) and ask:

Would you also like to search your [harness name] session history
for relevant knowledge to help the Compound process? This adds
time and token usage.

If the user says yes, dispatch the Session Historian in Phase 1. If no, skip it. Do not ask this in lightweight mode.

---

Full Mode

<critical_requirement> The primary output is ONE file - 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 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. </critical_requirement>

Phase 0.5: Auto Memory Scan

Before launching Phase 1 subagents, check the auto-memory block injected into your system prompt for notes relevant to the problem being documented.

1. Look for a block labeled "user's auto-memory" (Claude Code only) already present in your system prompt context — MEMORY.md's entries are inlined there
2. If the block is absent, empty, or this is a non-Claude-Code platform, skip this step and proceed to Phase 1 unchanged
3. Scan the entries for anything related to the problem being documented -- use semantic judgment, not keyword matching
4. If relevant entries are found, prepare a labeled excerpt block:

## 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]

5. 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.

If no relevant entries are found, proceed to Phase 1 without passing memory context.

Phase 1: Research

Launch research subagents. Each returns text data to the orchestrator.

Dispatch order:

• Launch Context Analyzer, Solution Extractor, and Related Docs Finder in parallel (background)
• Then dispatch ce-session-historian in foreground — it reads session files outside the working directory that background agents may not have access to
• The foreground dispatch runs while the background agents work, adding no wall-clock time

<parallel_tasks>

1. Context Analyzer

• Extracts conversation history
• Reads references/schema.yaml for enum validation and track classification
• Determines the track (bug or knowledge) from the problem_type
• Identifies problem type, component, and track-appropriate fields:
  • Bug track: symptoms, root_cause, resolution_type
  • Knowledge track: applies_when (symptoms/root_cause/resolution_type optional)
• Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence
• Reads references/yaml-schema.md for category mapping into docs/solutions/
• Suggests a filename using the pattern [sanitized-problem-slug]-[date].md
• Returns: YAML frontmatter skeleton (must include category: field mapped from problem_type), category directory path, suggested filename, and which track applies
• Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above
• Does not force bug-track fields onto knowledge-track learnings or vice versa

2. Solution Extractor

• Reads references/schema.yaml for track classification (bug vs knowledge)
• Adapts output structure based on the problem_type track
• 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

Bug track output sections:

• Problem: 1-2 sentence description of the issue
• Symptoms: Observable symptoms (error messages, behavior)
• What Didn't Work: Failed investigation attempts and why they failed
• Solution: The actual fix with code examples (before/after when applicable)
• Why This Works: Root cause explanation and why the solution addresses it
• Prevention: Strategies to avoid recurrence, best practices, and test cases. Include concrete code examples where applicable (e.g., gem configurations, test assertions, linting rules)

Knowledge track output sections:

• Context: What situation, gap, or friction prompted this guidance
• Guidance: The practice, pattern, or recommendation with code examples when useful
• Why This Matters: Rationale and impact of following or not following this guidance
• When to Apply: Conditions or situations where this applies
• Examples: Concrete before/after or usage examples showing the practice in action

3. Related Docs Finder

• Searches docs/solutions/ for related documentation
• Identifies cross-references and links
• Finds related GitHub issues
• Flags any related learning or pattern docs that may now be stale, contradicted, or overly broad
• Assesses overlap with the new doc being created across five dimensions: problem statement, root cause, solution approach, referenced files, and prevention rules. Score as:
  • High: 4-5 dimensions match — essentially the same problem solved again
  • Moderate: 2-3 dimensions match — same area but different angle or solution
  • Low: 0-1 dimensions match — related but distinct
• Returns: Links, relationships, refresh candidates, and overlap assessment (score + which dimensions matched)

Search strategy (grep-first filtering for efficiency):

1. Extract keywords from the problem context: module names, technical terms, error messages, component types
2. If the problem category is clear, narrow search to the matching docs/solutions/<category>/ directory
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:
   • title:.*<keyword>
   • tags:.*(<keyword1>|<keyword2>)
   • module:.*<module name>
   • component:.*<component>
4. If search returns >25 candidates, re-run with more specific patterns. If <3, broaden to full content search
5. Read only frontmatter (first 30 lines) of candidate files to score relevance
6. Fully read only strong/moderate matches
7. Return distilled links and relationships, not raw file contents

GitHub issue search:

Prefer the gh CLI for searching related issues: gh issue list --search "<keywords>" --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.

</parallel_tasks>

4. Session Historian (foreground, after launching the above — only if the user opted in)

• Skip entirely if the user declined session history in the follow-up question
• Dispatched as ce-session-historian
• Dispatch in foreground — this agent reads session files outside the working directory (~/.claude/projects/, ~/.codex/sessions/, ~/.cursor/projects/) which background agents may not have access to
• Searches prior Claude Code, Codex, and Cursor sessions for the same project to find related investigation context
• Correlates sessions by repo name across all platforms (matches sessions from main checkouts, worktrees, and Conductor workspaces)
• In the dispatch prompt, pass:

  • A specific description of the problem being documented — not a generic topic, but the concrete issue (error messages, module names, what broke and how it was fixed). This is what the agent filters its findings against.

  • The current git branch and working directory

  • The instruction: "Only surface findings from prior sessions that are directly relevant to this specific problem. Ignore unrelated work from the same sessions or branches."

  • The output format:

    Structure your response with these sections (omit any with no findings):
    - What was tried before: prior approaches to this specific problem
    - What didn't work: failed attempts at this problem from prior sessions
    - Key decisions: choices made about this problem and their rationale
    - Related context: anything else from prior sessions that directly informs this problem's documentation
    

• Omit the mode parameter so the user's configured permission settings apply
• Dispatch on the mid-tier model (e.g., model: "sonnet" in Claude Code) — the synthesis feeds into compound assembly and doesn't need frontier reasoning
• Returns: structured digest of findings from prior sessions, or "no relevant prior sessions" if none found

Phase 2: Assembly & Write

<sequential_tasks>

WAIT for all Phase 1 subagents to complete before proceeding.

The orchestrating agent (main conversation) performs these steps:

1. Collect all text results from Phase 1 subagents

2. Check the overlap assessment from the Related Docs Finder before deciding what to write:

   Overlap	Action
   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.
   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.
   Low or none	Create the new doc normally.

   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.

   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.

3. Incorporate session history findings (if available). When the Session History Researcher returned relevant prior-session context:

   • Fold investigation dead ends and failed approaches into the What Didn't Work section (bug track) or Context section (knowledge track)
   • Use cross-session patterns to enrich the Prevention or Why This Matters sections
   • Tag session-sourced content with "(session history)" so its origin is clear to future readers
   • If findings are thin or "no relevant prior sessions," proceed without session context

4. Assemble complete markdown file from the collected pieces, reading assets/resolution-template.md for the section structure of new docs

5. Validate YAML frontmatter against references/schema.yaml, including the YAML-safety quoting rule for array items (see references/yaml-schema.md > YAML Safety Rules)

6. Create directory if needed: mkdir -p docs/solutions/[category]/

7. Write the file: either the updated existing doc or the new docs/solutions/[category]/[filename].md

When creating a new doc, preserve the section order from assets/resolution-template.md unless the user explicitly asks for a different structure.

</sequential_tasks>

Phase 2.5: Selective Refresh Check

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:

1. A related learning