/ce-compound

name: ce:compound
description: Document a recently solved problem to compound your team's knowledge

/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, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the options and wait for the user's reply.

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 directory for notes relevant to the problem being documented.

1. Read MEMORY.md from the auto memory directory (the path is known from the system prompt context) 2. If the directory or MEMORY.md does not exist, is empty, or is unreadable, 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 `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)

-