Stats
Actions
Tags
From traceweaver-core
Document a recently solved problem to compound your team's knowledge
How this skill is triggered — by the user, by Claude, or both
Slash command
/traceweaver-core:ce-compound [optional: brief context] [mode:headless] [optional: brief context] [mode:headless] The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- TRACEWEAVER: file-role=packaged-skills-ce-compound-skill; req=REQ-TW-043; trace=TRACE-TW-009; ver=VER-TW-015 -->
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
/ce-compound mode:headless # Non-interactive run for automations
/ce-compound mode:headless [context] # Non-interactive run with context hint
Check $ARGUMENTS for a mode:headless token. Tokens starting with mode: are flags, not context — strip mode:headless from arguments before treating the remainder as the brief context hint.
| Mode | When | Behavior |
|---|---|---|
| Interactive (default) | No mode token present | Ask Full vs Lightweight, ask about session history (Full only), prompt for Discoverability Check consent, end with "What's next?" |
| Headless | mode:headless in arguments | No blocking questions. Run Full mode without session history. Apply the Discoverability Check edit silently if a gap exists. Skip Phase 3 specialized reviews. End with a structured terminal report — no "What's next?" menu. |
Headless mode is intended for automations and skill-to-skill invocation where no human is present to answer questions. The doc itself is identical to what an interactive Full run would produce — classification work (track, category, overlap) follows the same rules and writes nothing extra into the artifact. Once detected, headless mode applies for the entire run.
Git branch (pre-resolved): !git rev-parse --abbrev-ref HEAD 2>/dev/null || true
If the line above resolved to a plain branch name (like feat/my-branch), include it in the ce-sessions invocation payload in Phase 1 so the orchestrator does not waste a turn deriving it. If it still contains a backtick command string or is empty, omit it and let ce-sessions derive it at runtime.
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.
In headless mode, skip both questions below and go directly to Full Mode with session history disabled. Phase 1's session-history step (step 4) is omitted. Proceed straight to research.
In interactive mode, 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.
In interactive mode, do NOT pre-select a mode, do NOT skip this prompt, and wait for the user's choice before proceeding. (Headless mode bypasses this prompt per the "In headless mode" rule above and runs Full directly — these "do not skip" directives do not apply to headless.)
If the user chooses Full (interactive mode only), 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, invoke ce-sessions in Phase 1 (see step 4). If no, skip it. Do not ask this in lightweight mode or headless 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>
Before launching Phase 1 subagents, check the auto-memory block injected into your system prompt 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.
Launch research subagents. Each returns text data to the orchestrator.
Dispatch order:
Context Analyzer, Solution Extractor, and Related Docs Finder in parallel (background)ce-sessions skill via the platform's skill-invocation primitive (see step 4 below) — only if the user opted in to session history. The skill call is synchronous from this orchestrator's main-context turn, but the already-dispatched background subagents continue running in parallel underneath, so the wall-clock benefit is preserved (max(ce-sessions, slowest background subagent), not their sum). Issuing the skill call before the parallel block would serialize ce-sessions in front of the research subagents and regress wall-clock time.<parallel_tasks>
references/schema.yaml for enum validation and track classificationreferences/yaml-schema.md for category mapping into docs/solutions/[sanitized-problem-slug]-[date].mdcategory: field mapped from problem_type), category directory path, suggested filename, and which track appliesreferences/schema.yaml for track classification (bug vs knowledge)Bug track output sections:
Knowledge track output sections:
docs/solutions/ for related documentationSearch strategy (grep-first filtering for efficiency):
docs/solutions/<category>/ directorytitle:.*<keyword>tags:.*(<keyword1>|<keyword2>)module:.*<module name>component:.*<component>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>
ce-sessions (synchronous skill call, after launching the parallel block — only if the user opted in)ce-sessions skill via the platform's skill-invocation primitive (Skill in Claude Code, Skill in Codex, the equivalent on Gemini/Pi). Pass the dispatch payload below as the skill argument string. ce-sessions runs in main context — it owns discovery, branch/keyword filtering, scan-window selection, the deep-dive cap, per-session extraction to a mktemp scratch dir, and dispatch of the synthesis-only ce-session-historian subagent. The compound orchestrator only needs to pass the topic and time window and read back the findings text.Dispatch payload — keep tight. A long, keyword-rich payload licenses ce-sessions to keep widening. Use this shape:
Pre-resolved context (only if values resolved cleanly above; otherwise omit): repo name, current git branch.
Time window: explicit 7 days unless the documented problem clearly spans a longer arc.
Problem topic: one sentence naming the concrete issue — error message, module name, what broke and how it was fixed. Not a paragraph; not a bullet list of related topics.
Filter rule (one line): "Only surface findings directly relevant to this specific problem. Ignore unrelated work from the same sessions or branches."
Output schema:
Structure your response with these sections (omit any with no findings):
- What was tried before
- What didn't work
- Key decisions
- Related context
Do not append additional context blocks, exclusion lists, or topic-keyword bullets — verbose payloads give ce-sessions license to keep widening the search and rapidly compound wall time. If keyword search is needed, ce-sessions owns that decision internally based on the topic.
<sequential_tasks>
WAIT for all Phase 1 subagents to complete before proceeding.
The orchestrating agent (main conversation) performs these steps:
Collect all text results from Phase 1 subagents
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.
Incorporate session history findings (if available). When ce-sessions returned relevant prior-session context:
Assemble complete markdown file from the collected pieces, reading assets/resolution-template.md for the section structure of new docs
Validate YAML frontmatter against references/schema.yaml, including the YAML-safety quoting rule for array items (see references/yaml-schema.md > YAML Safety Rules)
Create directory if needed: mkdir -p docs/solutions/[category]/
Write the file: either the updated existing doc or the new docs/solutions/[category]/[filename].md
Run python3 scripts/validate-frontmatter.py <output-path> to catch silent-corruption parser-safety issues that the prose rules miss: malformed --- delimiter lines, unquoted # in scalar values (silent comment truncation), and unquoted : in scalar values (silent mapping confusion). Exit 0 means the doc is parser-safe; exit 1 means the script's stderr names the offending field(s) and what to fix — quote the value(s), re-write the doc, and re-run until exit 0. Do not declare success while validation fails. The script does not enforce schema rules and does not flag YAML reserved-indicator characters (those produce loud parser errors downstream rather than silent corruption — out of scope). Uses Python 3 stdlib only (no PyYAML or other deps).
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>
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 hintce-compound-refresh and never ask the user. Surface the recommended scope hint in the terminal report's "Refresh recommendation" line and let the caller decideWhen 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.
After the learning is written and the refresh decision is made, check whether the project's instruction files would lead an agent to discover and search docs/solutions/ before starting work in a documented area. This runs every time — the knowledge store only compounds value when agents can find it.
Identify which root-level instruction files exist (AGENTS.md, CLAUDE.md, or both). Read the file(s) and determine which holds the substantive content — one file may just be a shim that @-includes the other (e.g., CLAUDE.md containing only @AGENTS.md, or vice versa). The substantive file is the assessment and edit target; ignore shims. If neither file exists, skip this check entirely.
Assess whether an agent reading the instruction files would learn three things:
module, tags, problem_type)This is a semantic assessment, not a string match. The information could be a line in an architecture section, a bullet in a gotchas section, spread across multiple places, or expressed without ever using the exact path docs/solutions/. Use judgment — if an agent would reasonably discover and use the knowledge store after reading the file, the check passes.
If the spirit is already met, no action needed — move on.
If not: a. Based on the file's existing structure, tone, and density, identify where a mention fits naturally. Before creating a new section, check whether the information could be a single line in the closest related section — an architecture tree, a directory listing, a documentation section, or a conventions block. A line added to an existing section is almost always better than a new headed section. Only add a new section as a last resort when the file has clear sectioned structure and nothing is even remotely related. b. Draft the smallest addition that communicates the three things. Match the file's existing style and density. The addition should describe the knowledge store itself, not the plugin — an agent without the plugin should still find value in it.
Keep the tone informational, not imperative. Express timing as description, not instruction — "relevant when implementing or debugging in documented areas" rather than "check before implementing or debugging." Imperative directives like "always search before implementing" cause redundant reads when a workflow already includes a dedicated search step. The goal is awareness: agents learn the folder exists and what's in it, then use their own judgment about when to consult it.
Examples of calibration (not templates — adapt to the file):
When there's an existing directory listing or architecture section — add a line:
docs/solutions/ # documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (module, tags, problem_type)
When nothing in the file is a natural fit — a small headed section is appropriate:
## Documented Solutions
`docs/solutions/` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`). Relevant when implementing or debugging in documented areas.
c. In full interactive mode, explain to the user why this matters — agents working in this repo (including fresh sessions, other tools, or collaborators without the plugin) won't know to check docs/solutions/ unless the instruction file surfaces it. Show the proposed change and where it would go, then use the platform's blocking question tool to get consent before making the edit: 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 the proposal 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. In lightweight mode, output a one-liner note and move on. In headless mode, apply the edit directly without prompting and surface it in the terminal report under "Instruction-file edit"
WAIT for Phase 2 to complete before proceeding.
Skip Phase 3 entirely in headless mode to bound token usage — the caller does not have a human-in-the-loop to act on reviewer findings, and downstream automations can run specialized reviewers themselves if they want that pass.
<parallel_tasks>
Based on problem type, optionally invoke specialized agents to review the documentation:
ce-performance-oraclece-security-sentinelce-data-integrity-guardiance-code-simplicity-reviewer, and additionally run the kieran reviewer that matches the repo's primary stack:
ce-kieran-rails-reviewerce-kieran-python-reviewerce-kieran-typescript-reviewer</parallel_tasks>
<critical_requirement> Single-pass alternative — same documentation, fewer tokens.
This mode skips parallel subagents entirely. The orchestrator performs all work in a single pass, producing the same solution document without cross-referencing or duplicate detection.
Headless mode forces Full and does not enter Lightweight — automations get the cross-reference and overlap detection benefits without the interactive overhead. </critical_requirement>
The orchestrator (main conversation) performs ALL of the following in one sequential pass:
references/schema.yaml and references/yaml-schema.md, then determine track (bug vs knowledge), category, and filenamedocs/solutions/[category]/[filename].md using the appropriate track template from assets/resolution-template.md, with:
references/yaml-schema.md > YAML Safety Rules)Lightweight output:
✓ Documentation complete (lightweight mode)
File created:
- docs/solutions/[category]/[filename].md
[If discoverability check found instruction files don't surface the knowledge store:]
Tip: Your AGENTS.md/CLAUDE.md doesn't surface docs/solutions/ to agents —
a brief mention helps all agents discover these learnings.
Note: This was created in lightweight mode. For richer documentation
(cross-references, detailed prevention strategies, specialized reviews),
re-run /ce-compound in a fresh session.
No subagents are launched. No parallel tasks. One file written.
In lightweight mode, the overlap check is skipped (no Related Docs Finder subagent). This means lightweight mode may create a doc that overlaps with an existing one. That is acceptable — ce-compound-refresh will catch it later. Only suggest ce-compound-refresh if there is an obvious narrow refresh target. Do not broaden into a large refresh sweep from a lightweight session.
Organized documentation:
docs/solutions/[category]/[filename].mdCategories auto-detected from problem:
Bug track:
Knowledge track:
| ❌ 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 | One solution doc written or updated: docs/solutions/[category]/[filename].md (plus an optional small edit to a project instruction file for discoverability) |
| Creating a new doc when an existing doc covers the same problem | Check overlap assessment; update the existing doc when overlap is high |
Emit a structured terminal report and end the turn. No "What's next?" question, no blocking prompt. End with Documentation complete as the terminal signal so callers can detect completion.
✓ Documentation complete (headless mode)
File: docs/solutions/<category>/<filename>.md (created | updated)
Track: <bug | knowledge>
Category: <category>
Overlap: <none | low | moderate — see <path> | high — existing doc updated>
Instruction-file edit: <none needed | applied to <path> | gap noted, not applied>
Refresh recommendation: <none | scope hint for /ce-compound-refresh>
Documentation complete
When no doc was written (e.g., headless invoked on a session where the problem is not yet solved), emit a structured failure instead and end with Documentation skipped so callers can distinguish success from no-op:
✗ Documentation skipped (headless mode)
Reason: <one-sentence explanation — e.g., "no solved problem detected in
conversation history" or "solution not yet verified">
Documentation skipped
✓ Documentation complete
Auto memory: 2 relevant entries used as supplementary evidence
Subagent Results:
✓ Context Analyzer: Identified performance_issue in brief_system, category: performance-issues/
✓ Solution Extractor: 3 code fixes, prevention strategies
✓ Related Docs Finder: 2 related issues
✓ Session History: 3 prior sessions on same branch, 2 failed approaches surfaced
Specialized Agent Reviews (Auto-Triggered):
✓ ce-performance-oracle: Validated query optimization approach
✓ ce-kieran-rails-reviewer: Code examples meet Rails conventions
✓ ce-code-simplicity-reviewer: Solution is appropriately minimal
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
After displaying the interactive success output above, present the "What's next?" options 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 numbered 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. Do not continue the workflow or end the turn without the user's selection. (Interactive mode only — headless skips this per the headless block above.)
Alternate interactive output (when updating an existing doc due to high overlap): in headless mode, this case is communicated via the Overlap: high — existing doc updated line of the headless terminal report above, not as a separate output block.
✓ Documentation updated (existing doc refreshed with current context)
Overlap detected: docs/solutions/performance-issues/n-plus-one-queries.md
Matched dimensions: problem statement, root cause, solution, referenced files
Action: Updated existing doc with fresher code examples and prevention tips
File updated:
- docs/solutions/performance-issues/n-plus-one-queries.md (added last_updated: 2026-03-24)
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>
Writes the final learning directly into docs/solutions/.
Based on problem type, these agents can enhance documentation:
/research [topic] - Deep investigation (searches docs/solutions/ for patterns)/ce-plan - Planning workflow (references documented solutions)Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub oxiom-systems/traceweaver --plugin traceweaver-core