ce-compound

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/compound

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

协调多个并行工作的subagent，记录最近解决的问题。

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.

在上下文信息清晰时记录问题解决方案，在

docs/solutions/

目录下创建带有YAML前置元数据的结构化文档，以便于搜索和后续参考。通过并行subagent实现最高效率。

为什么叫“compound”？ 每一份记录下来的解决方案都会让团队的知识实现复利积累。第一次解决问题需要调研；记录下来后，下次遇到同类问题只需要几分钟就能解决。知识就是这样复利增长的。

Usage

使用方法

bash

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

bash

/ce:compound                    # 记录最近的修复方案
/ce:compound [简要上下文]    # 提供额外的上下文提示

Execution Strategy: Context-Aware Orchestration

执行策略：上下文感知编排

Phase 0: Context Budget Check

阶段0：上下文预算检查

<critical_requirement> Run this check BEFORE launching any subagents.

The /compound command is token-heavy - it launches 5 parallel subagents that collectively consume ~10k tokens of context. Running near context limits risks compaction mid-compound, which degrades output quality significantly. </critical_requirement>

Before proceeding, the orchestrator MUST:

Assess context usage: Check how long the current conversation has been running. If there has been significant back-and-forth (many tool calls, large file reads, extensive debugging), context is likely constrained.

Warn the user:

⚠️ Context Budget Check

/compound launches 5 parallel subagents (~10k tokens). Long conversations
risk compaction mid-compound, which degrades documentation quality.

Tip: For best results, run /compound early in a session - right after
verifying a fix, before continuing other work.

Offer the user a choice:

How would you like to proceed?

1. Full compound (5 parallel subagents, ~10k tokens) - best quality
2. Compact-safe mode (single pass, ~2k tokens) - safe near context limits

If the user picks option 1 (or confirms full mode): proceed to Phase 1 below.
If the user picks option 2 (or requests compact-safe): skip to the Compact-Safe Mode section below.

<critical_requirement> 在启动任何subagent之前必须执行此检查。

/compound命令会消耗大量token——它会启动5个并行subagent，总共消耗约10k token。如果接近上下文上限，可能会在执行过程中触发压缩，严重降低输出质量。 </critical_requirement>

在继续之前，编排代理必须完成以下步骤：

评估上下文使用情况：检查当前对话已进行的时长。如果有大量的来回交互（多次工具调用、大文件读取、大量调试操作），则上下文可能已接近上限。

向用户发出警告：

⚠️ 上下文预算检查

/compound会启动5个并行subagent（约10k token）。长对话可能会在执行过程中触发上下文压缩，导致文档质量下降。

提示：为获得最佳效果，请在会话早期运行/compound——在确认修复完成后立即执行，再进行其他工作。

提供选项供用户选择：

您希望如何继续？

1. 完整模式（5个并行subagent，约10k token）——最佳质量
2. 紧凑安全模式（单次执行，约2k token）——适合上下文受限的场景

如果用户选择选项1（或确认完整模式）：继续执行下面的阶段1。
如果用户选择选项2（或要求紧凑安全模式）：直接跳转到紧凑安全模式部分。

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>

<critical_requirement> 只会生成一个文件——最终的文档。

阶段1的subagent仅向编排代理返回文本数据，不得使用Write、Edit或创建任何文件。只有编排代理（阶段2）会写入最终的文档文件。 </critical_requirement>

Phase 1: Parallel Research

阶段1：并行调研

<parallel_tasks>

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

<parallel_tasks>

并行启动以下subagent，每个subagent都会向编排代理返回文本数据。

1. Context Analyzer

1. 上下文分析器

Extracts conversation history
- Identifies problem type, component, symptoms
- Validates against schema
- Returns: YAML frontmatter skeleton

提取对话历史
- 识别问题类型、涉及组件和症状
- 根据 schema 验证信息
- 返回：YAML前置元数据骨架

2. Solution Extractor

2. 解决方案提取器

Analyzes all investigation steps
- Identifies root cause
- Extracts working solution with code examples
- Returns: Solution content block

分析所有调研步骤
- 识别根本原因
- 提取包含代码示例的可行解决方案
- 返回：解决方案内容块

3. Related Docs Finder

3. 相关文档查找器

Searches
```
docs/solutions/
```
for related documentation
- Identifies cross-references and links
- Finds related GitHub issues
- Returns: Links and relationships

在
```
docs/solutions/
```
目录下搜索相关文档
- 识别交叉引用和链接
- 查找相关的GitHub issues
- 返回：链接和关联关系

4. Prevention Strategist

4. 预防策略师

Develops prevention strategies
- Creates best practices guidance
- Generates test cases if applicable
- Returns: Prevention/testing content

制定预防策略
- 创建最佳实践指南
- 适用时生成测试用例
- 返回：预防/测试相关内容

5. Category Classifier

5. 分类器

Determines optimal
```
docs/solutions/
```
category
- Validates category against schema
- Suggests filename based on slug
- Returns: Final path and filename

</parallel_tasks>

确定
```
docs/solutions/
```
目录下的最优分类
- 根据 schema 验证分类
- 基于slug建议文件名
- 返回：最终路径和文件名

</parallel_tasks>

Phase 2: Assembly & Write

阶段2：组装与写入

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

<sequential_tasks>

等待所有阶段1的subagent完成后再继续。

编排代理（主对话）执行以下步骤：

收集阶段1所有subagent返回的文本结果
将收集到的内容组装成完整的markdown文件
根据schema验证YAML前置元数据
按需创建目录：
```
mkdir -p docs/solutions/[category]/
```
写入唯一的最终文件：
```
docs/solutions/[category]/[filename].md
```

</sequential_tasks>

Phase 3: Optional Enhancement

阶段3：可选增强

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>

等待阶段2完成后再继续。

<parallel_tasks>

根据问题类型，可选择性调用专业代理来审核文档：

performance_issue →
```
performance-oracle
```
security_issue →
```
security-sentinel
```
database_issue →
```
data-integrity-guardian
```
test_failure →
```
cora-test-reviewer
```

任何代码相关问题 →

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

<critical_requirement> 适用于上下文受限场景的单次执行替代方案。

当上下文预算紧张时，此模式会完全跳过并行subagent，由编排代理单次完成所有工作，生成一份精简但完整的解决方案文档。 </critical_requirement>

编排代理（主对话）会一次性按顺序完成以下所有步骤：

从对话中提取信息：从对话历史中识别问题、根本原因和解决方案
分类：确定分类和文件名（与完整模式的分类规则一致）
写入精简文档：创建
```
docs/solutions/[category]/[filename].md
```
，包含：
- YAML前置元数据（标题、分类、日期、标签）
- 问题描述（1-2句话）
- 根本原因（1-2句话）
- 包含关键代码片段的解决方案
- 一条预防建议
跳过专业代理审核（阶段3）以节省上下文资源

紧凑安全模式输出示例：

✓ 文档已生成（紧凑安全模式）

已创建文件：
- docs/solutions/[category]/[filename].md

说明：此文档由紧凑安全模式生成。如需更丰富的文档内容（交叉引用、详细预防策略、专业审核），请在新会话中重新运行/compound。

不会启动任何subagent，没有并行任务，仅生成一个文件。

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

前置条件

<preconditions enforcement="advisory"> <check condition="problem_solved"> Problem has been solved (not in-progress) </check> <check condition="solution_verified"> Solution has been verified working </check> <check condition="non_trivial"> Non-trivial problem (not simple typo or obvious error) </check> </preconditions>

<preconditions enforcement="advisory"> <check condition="problem_solved"> 问题已解决（非进行中状态） </check> <check condition="solution_verified"> 解决方案已验证可行 </check> <check condition="non_trivial"> 非简单问题（不是拼写错误或明显的低级错误） </check> </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/

结构化文档：

文件路径：
```
docs/solutions/[category]/[filename].md
```

根据问题自动识别分类：

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`

❌ 错误做法	✅ 正确做法
Subagent创建 `context-analysis.md` 、 `solution-draft.md` 等文件	Subagent仅返回文本数据；由编排代理写入唯一的最终文件
调研和组装并行执行	先完成调研 → 再执行组装
工作流中创建多个文件	仅生成一个文件： `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

✓ 文档已生成

Subagent执行结果：
  ✓ 上下文分析器：识别到brief_system中的performance_issue
  ✓ 解决方案提取器：提取3处代码修复方案
  ✓ 相关文档查找器：找到2个关联问题
  ✓ 预防策略师：提供预防策略和测试建议
  ✓ 分类器：归类为`performance-issues`

自动触发的专业代理审核：
  ✓ performance-oracle：验证了查询优化方案
  ✓ kieran-rails-reviewer：代码示例符合Rails最佳实践
  ✓ code-simplicity-reviewer：解决方案精简清晰
  ✓ every-style-editor：文档格式和清晰度已验证

已创建文件：
- docs/solutions/performance-issues/n-plus-one-brief-generation.md

当邮件处理或Brief System模块出现类似问题时，此文档可作为可搜索的参考资料。

下一步操作？
1. 继续当前工作流（推荐）
2. 关联相关文档
3. 更新其他参考资料
4. 查看文档
5. 其他

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.

此工具构建了一个复利式知识系统：

第一次解决“Brief生成中的N+1查询问题” → 调研（30分钟）
记录解决方案 → 生成docs/solutions/performance-issues/n-plus-one-briefs.md（5分钟）
下次遇到同类问题 → 快速查阅（2分钟）
知识复利积累 → 团队能力持续提升

反馈循环：

构建 → 测试 → 发现问题 → 调研 → 优化 → 记录 → 验证 → 部署
    ↑                                                                      ↓
    └──────────────────────────────────────────────────────────────────────┘

每一项工程工作都应该让后续工作更轻松，而不是更困难。

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>

<auto_invoke> <trigger_phrases> - "that worked" - "it's fixed" - "working now" - "problem solved" </trigger_phrases>

<manual_override> 使用/ce:compound [上下文]可立即记录，无需等待自动检测。 </manual_override> </auto_invoke>

Routes To

关联技能

compound-docs

skill

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

kieran-rails-reviewer：审核代码示例是否符合Rails最佳实践
code-simplicity-reviewer：确保解决方案代码精简清晰
pattern-recognition-specialist：识别反模式或重复出现的问题

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

performance-oracle：分析performance_issue分类的解决方案
security-sentinel：审核security_issue解决方案的安全性
cora-test-reviewer：为预防策略创建测试用例
data-integrity-guardian：审核database_issue的迁移和查询语句

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

best-practices-researcher：用行业最佳实践丰富解决方案内容
every-style-editor：审核文档格式和清晰度
framework-docs-researcher：关联Rails/ gem官方文档参考链接

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

自动触发（可选）：文档生成后自动运行代理以增强内容
手动触发：用户可在/ce:compound完成后调用代理进行深度审核
自定义代理：编辑
```
compound-engineering.local.md
```
或调用
```
setup
```
skill，配置所有工作流中使用的审核代理

ce-compound

Original

Translation

/compound

/compound

Purpose

目的

Usage

使用方法

Execution Strategy: Context-Aware Orchestration

执行策略：上下文感知编排

Phase 0: Context Budget Check

阶段0：上下文预算检查

Full Mode

完整模式

Phase 1: Parallel Research

阶段1：并行调研

1. Context Analyzer

1. 上下文分析器

2. Solution Extractor

2. 解决方案提取器

3. Related Docs Finder

3. 相关文档查找器

4. Prevention Strategist

4. 预防策略师

5. Category Classifier

5. 分类器

Phase 2: Assembly & Write

阶段2：组装与写入

Phase 3: Optional Enhancement

阶段3：可选增强

Compact-Safe Mode

紧凑安全模式

What It Captures

记录内容

Preconditions

前置条件

What It Creates

生成内容

Common Mistakes to Avoid

需避免的常见错误

Success Output

成功输出示例

The Compounding Philosophy

复利理念

Auto-Invoke

自动触发

Routes To

关联技能

Applicable Specialized Agents

适用的专业代理

Code Quality & Review

代码质量与审核

Specific Domain Experts

特定领域专家

Enhancement & Documentation

增强与文档优化

When to Invoke

触发时机

Related Commands

相关命令