Files

Trevin Chow 4e3af07962 feat: optimize ce:compound speed and effectiveness (#370 )

2026-03-24 20:12:19 -07:00

18 KiB

Raw Blame History

name, description, argument-hint

name	description	argument-hint
ce:compound	Document a recently solved problem to compound your team's knowledge	[optional: brief context about the fix]

/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

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

Phase 0.5: Auto Memory Scan

Before launching Phase 1 subagents, check the auto memory directory for notes relevant to the problem being documented.

Read MEMORY.md from the auto memory directory (the path is known from the system prompt context)
If the directory or MEMORY.md does not exist, is empty, or is unreadable, skip this step and proceed to Phase 1 unchanged
Scan the entries for anything related to the problem being documented -- use semantic judgment, not keyword matching
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]

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: Parallel Research

<parallel_tasks>

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

1. Context Analyzer

Extracts conversation history
Identifies problem type, component, symptoms
Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence when identifying problem type, component, and symptoms
Validates all enum fields against the schema values below
Maps problem_type to the docs/solutions/ category directory
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, and suggested filename

Schema enum values (validate against these exactly):

problem_type: build_error, test_failure, runtime_error, performance_issue, database_issue, security_issue, ui_bug, integration_issue, logic_error, developer_experience, workflow_issue, best_practice, documentation_gap
component: rails_model, rails_controller, rails_view, service_object, background_job, database, frontend_stimulus, hotwire_turbo, email_processing, brief_system, assistant, authentication, payments, development_workflow, testing_framework, documentation, tooling
root_cause: missing_association, missing_include, missing_index, wrong_api, scope_issue, thread_violation, async_timing, memory_leak, config_error, logic_error, test_isolation, missing_validation, missing_permission, missing_workflow_step, inadequate_documentation, missing_tooling, incomplete_setup
resolution_type: code_fix, migration, config_change, test_fix, dependency_update, environment_setup, workflow_improvement, documentation_update, tooling_addition, seed_data_update
severity: critical, high, medium, low

Category mapping (problem_type -> directory):

problem_type	Directory
build_error	build-errors/
test_failure	test-failures/
runtime_error	runtime-errors/
performance_issue	performance-issues/
database_issue	database-issues/
security_issue	security-issues/
ui_bug	ui-bugs/
integration_issue	integration-issues/
logic_error	logic-errors/
developer_experience	developer-experience/
workflow_issue	workflow-issues/
best_practice	best-practices/
documentation_gap	documentation-gaps/

2. Solution Extractor

Analyzes all investigation steps
Identifies root cause
Extracts working solution with code examples
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
Develops prevention strategies and best practices guidance
Generates test cases if applicable
Returns: Solution content block including prevention section

Expected output sections (follow this structure):

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)

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

Search strategy (grep-first filtering for efficiency):

Extract keywords from the problem context: module names, technical terms, error messages, component types
If the problem category is clear, narrow search to the matching docs/solutions/<category>/ directory
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>
If search returns >25 candidates, re-run with more specific patterns. If <3, broaden to full content search
Read only frontmatter (first 30 lines) of candidate files to score relevance
Fully read only strong/moderate matches
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>

Phase 2: Assembly & Write

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

</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:

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.

<parallel_tasks>

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

</parallel_tasks>

Compact-Safe Mode

<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:

Extract from conversation: Identify the problem, root cause, and solution from conversation history. Also read MEMORY.md from the auto memory directory if it exists -- use any relevant notes as supplementary context alongside conversation history. Tag any memory-sourced content incorporated into the final doc with "(auto memory [claude])"
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

Problem has been solved (not in-progress) Solution has been verified working Non-trivial problem (not simple typo or obvious error)

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

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

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

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

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

/research [topic] - Deep investigation (searches docs/solutions/ for patterns)
/ce:plan - Planning workflow (references documented solutions)

18 KiB Raw Blame History