/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

Execution Strategy

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.

Full Mode

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.

Phase 1: Parallel Research

Launch these subagents IN PARALLEL. Each returns text data to the orchestrator.

1.

Context Analyzer

Extracts conversation history

Identifies problem type, component, symptoms

Validates against schema

Returns: YAML frontmatter skeleton

2.

Solution Extractor

Analyzes all investigation steps

Identifies root cause

Extracts working solution with code examples

Returns: Solution content block

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

Returns: Links, relationships, and any refresh candidates

4.

Prevention Strategist

Develops prevention strategies

Creates best practices guidance

Generates test cases if applicable

Returns: Prevention/testing content

5.

Category Classifier

Determines optimal

docs/solutions/

category

Validates category against schema

Suggests filename based on slug

Returns: Final path and filename

Phase 2: Assembly & Write

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

Assemble complete markdown file from the collected pieces

Validate YAML frontmatter against schema

Create directory if needed:

mkdir -p docs/solutions/[category]/

Write the SINGLE final file:

docs/solutions/[category]/[filename].md

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:

A related learning or pattern doc recommends an approach that the new fix now contradicts

The new fix clearly supersedes an older documented solution

The current work involved a refactor, migration, rename, or dependency upgrade that likely invalidated references in older docs

A pattern doc now looks overly broad, outdated, or no longer supported by the refreshed reality

The Related Docs Finder surfaced high-confidence refresh candidates in the same problem space

It does

not

make sense to invoke

ce:compound-refresh

when:

No related docs were found

Related docs still appear consistent with the new learning

The overlap is superficial and does not change prior guidance

Refresh would require a broad historical review with weak evidence

Use these rules:

If there is

one obvious stale candidate

, invoke

ce:compound-refresh

with a narrow scope hint after the new learning is written

If there are

multiple candidates in the same area

, ask the user whether to run a targeted refresh for that module, category, or pattern set

If context is already tight or you are in compact-safe mode, do not expand into a broad refresh automatically; instead recommend

ce:compound-refresh

as the next step with a scope hint

When invoking or recommending

ce:compound-refresh

, be explicit about the argument to pass. Prefer the narrowest useful scope:

Specific file

when one learning or pattern doc is the likely stale artifact

Module or component name

when several related docs may need review

Category name

when the drift is concentrated in one solutions area

Pattern filename or pattern topic

when the stale guidance lives in

docs/solutions/patterns/

Examples:

/ce:compound-refresh plugin-versioning-requirements

/ce:compound-refresh payments

/ce:compound-refresh performance-issues

/ce:compound-refresh critical-patterns

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

Phase 3: Optional Enhancement

WAIT for Phase 2 to complete before proceeding.

Based on problem type, optionally invoke specialized agents to review the documentation:

performance_issue

→

performance-oracle

security_issue

→

security-sentinel

database_issue

→

data-integrity-guardian

test_failure

→

cora-test-reviewer

Any code-heavy issue →

kieran-rails-reviewer

+

code-simplicity-reviewer

Compact-Safe Mode

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.

The orchestrator (main conversation) performs ALL of the following in one sequential pass:

Extract from conversation

Identify the problem, root cause, and solution from conversation history

Classify

Determine category and filename (same categories as full mode)

Write minimal doc

Create

docs/solutions/[category]/[filename].md

with:

YAML frontmatter (title, category, date, tags)

Problem description (1-2 sentences)

Root cause (1-2 sentences)

Solution with key code snippets

One prevention tip

Skip specialized agent reviews

(Phase 3) to conserve context

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.

What It Captures

Problem symptom

Exact error messages, observable behavior

Investigation steps tried

What didn't work and why

Root cause analysis

Technical explanation

Working solution

Step-by-step fix with code examples

Prevention strategies

How to avoid in future

Cross-references

Links to related issues and docs

Preconditions

What It Creates

Organized documentation:

File:

docs/solutions/[category]/[filename].md

Categories auto-detected from problem:

build-errors/

test-failures/

runtime-errors/

performance-issues/

database-issues/

security-issues/

ui-bugs/

integration-issues/

logic-errors/

Common Mistakes to Avoid

❌ 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

Success Output

✓ Documentation complete

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

The Compounding Philosophy

This creates a compounding knowledge system:

First time you solve "N+1 query in brief generation" → Research (30 min)

Document the solution → docs/solutions/performance-issues/n-plus-one-briefs.md (5 min)

Next time similar issue occurs → Quick lookup (2 min)

Knowledge compounds → Team gets smarter

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

- "that worked" - "it's fixed" - "working now" - "problem solved"

Use /ce:compound [context] to document immediately without waiting for auto-detection.

Routes To

compound-docs

skill

Applicable Specialized Agents

Based on problem type, these agents can enhance documentation:

Code Quality & Review

kieran-rails-reviewer

Reviews code examples for Rails best practices

code-simplicity-reviewer

Ensures solution code is minimal and clear

pattern-recognition-specialist

Identifies anti-patterns or repeating issues

Specific Domain Experts

performance-oracle

Analyzes performance_issue category solutions

security-sentinel

Reviews security_issue solutions for vulnerabilities

cora-test-reviewer

Creates test cases for prevention strategies

data-integrity-guardian

Reviews database_issue migrations and queries

Enhancement & Documentation

best-practices-researcher

Enriches solution with industry best practices

every-style-editor

Reviews documentation style and clarity

framework-docs-researcher

Links to Rails/gem documentation references

When to Invoke

Auto-triggered

(optional): Agents can run post-documentation for enhancement

Manual trigger

User can invoke agents after /ce:compound completes for deeper review

Customize agents

Edit compound-engineering.local.md or invoke the setup skill to configure which review agents are used across all workflows Related Commands /research [topic] - Deep investigation (searches docs/solutions/ for patterns) /ce:plan - Planning workflow (references documented solutions)