ce:compound

/compound

协调多个子 Agent 并行工作，记录近期解决的问题。

目的

趁着上下文仍然清晰，记录问题的解决方案，在 docs/solutions/ 中创建带有 YAML frontmatter 的结构化文档，便于搜索和日后参考。通过并行子 Agent 提高效率。

为什么叫“compound”？ 每份解决方案文档都会累积团队的知识。第一次解决问题需要调研。记录下来后，下次遇到同样的问题，几分钟就能解决。知识会不断累积。

用法

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

支持文件

这些文件是工作流的持久契约。仅在相应步骤需要时按需读取——不要在技能启动时一次性全部加载。

• references/schema.yaml — frontmatter 字段及枚举值的规范定义（验证 YAML 时读取）
• references/yaml-schema.md — 将 problem_type 映射到目录的分类规则（分类时读取）
• assets/resolution-template.md — 新文档的章节结构（整理文档时读取）

启动子 Agent 时，将相关文件内容传入任务提示词，让它们无需跨技能路径也能获取契约内容。

执行策略

继续之前，使用平台的阻塞式提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）向用户提供两个选项。如果没有可用的提问工具，则展示选项并等待用户回复。

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.

不要预先选择模式。不要跳过此提示。等待用户选择后再继续。

如果用户选择全量模式，继续之前先询问一个后续问题。检测当前运行的 harness（Claude Code、Codex 或 Cursor），并询问：

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.

如果用户回答是，则在阶段 1 中调度 Session Historian。如果回答否，则跳过。轻量模式下不要询问此问题。

---

全量模式

<critical_requirement> 主要产出是一个文件——最终文档。

阶段 1 的子 Agent 向协调器返回文本数据。它们不得使用 Write、Edit 或创建任何文件。只有协调器可以写入文件：在阶段 2 中写入解决方案文档；如果可发现性检查发现缺口，则对项目指令文件（AGENTS.md 或 CLAUDE.md）进行小幅编辑。对指令文件的编辑属于维护工作，不是第二项交付物；此举可确保未来的 Agent 能找到知识库。 </critical_requirement>

阶段 0.5：自动记忆扫描

启动阶段 1 的子 Agent 之前，检查注入系统提示词的自动记忆区块，查找与要记录的问题相关的笔记。

1. 查找系统提示词上下文中已存在的“user's auto-memory”标记区块（仅 Claude Code）——其中内联了 MEMORY.md 的条目
2. 如果区块不存在、为空，或当前不是 Claude Code 平台，则跳过此步骤，直接进入阶段 1，不做任何更改
3. 扫描条目，查找与要记录的问题相关的内容——依据语义判断，而非关键词匹配
4. 如果找到相关条目，准备一个带标签的摘录区块：

## 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. 将此区块作为额外上下文传入阶段 1 的上下文分析器和解决方案提取器任务提示词。如果任何记忆笔记最终进入文档（例如，作为调查步骤或根本原因分析的一部分），请标注“(auto memory [claude])”，以便未来的读者了解其来源。

如果没有找到相关条目，则进入阶段 1，不传入记忆上下文。

阶段 1：调研

启动调研子 Agent。每个子 Agent 都向协调器返回文本数据。

调度顺序：

• 并行（后台）启动 Context Analyzer、Solution Extractor 和 Related Docs Finder
• 然后在前台调度 session-historian——它会读取工作目录之外的会话文件，后台 Agent 可能无法访问这些文件
• 前台调度会与后台 Agent 并行运行，不会增加实际耗时

<parallel_tasks>

1. 上下文分析器

• 提取对话历史
• 读取 references/schema.yaml，用于枚举值验证和轨道分类
• 根据 problem_type 确定轨道（bug 或知识）
• 识别问题类型、组件以及适用轨道的字段：
  • Bug 轨道：symptoms、root_cause、resolution_type
  • 知识轨道：applies_when（symptoms/root_cause/resolution_type 可选）
• 将自动记忆摘录（如果编排器提供）作为补充证据
• 读取 references/yaml-schema.md，将类别映射到 docs/solutions/
• 按照 [sanitized-problem-slug]-[date].md 模式建议文件名
• 返回：YAML frontmatter 骨架（必须包含从 problem_type 映射而来的 category: 字段）、类别目录路径、建议文件名，以及适用的轨道
• 不根据记忆臆造枚举值、类别或 frontmatter 字段；应读取上述架构和映射文件
• 不要将 bug 轨道的字段强加给知识轨道的经验，反之亦然

2. 解决方案提取器

• 读取 references/schema.yaml 以进行轨道分类（bug 与知识）
• 根据 problem_type 所属轨道调整输出结构
• 将自动记忆摘录（如果编排器提供）作为补充证据——对话历史和已验证的修复优先；如果记忆笔记与对话相矛盾，应将该矛盾注明为注意事项

Bug 轨道输出章节：

• 问题：用 1-2 句话描述问题
• 症状：可观察到的症状（错误消息、行为）
• 哪些方法无效：失败的调查尝试及其失败原因
• 解决方案：实际修复方案，附带代码示例（适用时提供修复前后对比）
• 为何有效：根本原因说明，以及该解决方案为何能解决问题
• 预防：避免问题再次发生的策略、最佳实践和测试用例。适用时提供具体代码示例（例如 gem 配置、测试断言、lint 规则）

知识轨道输出章节：

• 上下文：促使提出此指导的情境、知识缺口或阻碍
• 指导：实践、模式或建议；适用时提供代码示例
• 为何重要：遵循或不遵循此指导的原因和影响
• 适用时机：适用的条件或情境
• 示例：通过具体的前后对比或用法示例展示实践

3. 相关文档查找器

• 在 docs/solutions/ 中搜索相关文档
• 识别交叉引用和链接
• 查找相关 GitHub issue
• 标记可能已过时、与当前内容矛盾或范围过宽的相关学习文档或模式文档
• 评估新建文档与现有文档在以下五个维度上的重叠程度：问题陈述、根本原因、解决方案、引用文件和预防规则。评分如下：
  • 高：4–5 个维度匹配 — 本质上是再次解决同一个问题
  • 中：2–3 个维度匹配 — 属于同一领域，但切入点或解决方案不同
  • 低：0–1 个维度匹配 — 相关但有所区别
• 返回：链接、关联关系、需要更新的候选文档，以及重叠评估（分数 + 匹配的维度）

搜索策略（优先使用 grep 筛选以提高效率）：

1. 从问题上下文中提取关键词：模块名称、技术术语、错误消息、组件类型
2. 如果问题类别明确，将搜索范围缩小到匹配的 docs/solutions/<category>/ 目录
3. 使用原生内容搜索工具（例如 Claude Code 中的 Grep），在阅读任何内容之前预先筛选候选文件。并行执行多次搜索，忽略大小写，并针对 frontmatter 字段。以下为模板模式，请替换为实际关键词：
   • title:.*<keyword>
   • tags:.*(<keyword1>|<keyword2>)
   • module:.*<module name>
   • component:.*<component>
4. 如果搜索结果超过 25 个候选文件，使用更具体的模式重新搜索。如果少于 3 个，则扩大范围，搜索全文内容
5. 仅阅读候选文件的 frontmatter（前 30 行），以评估相关性
6. 仅完整阅读高度或中度匹配的文件
7. 返回提炼后的链接和关联关系，而非原始文件内容

GitHub issue 搜索：

优先使用 gh CLI 搜索相关 issue：gh issue list --search "<keywords>" --state all --limit 5。如果未安装 gh，则在可用时改用 GitHub MCP 工具（例如 unblocked data_retrieval）。如果两者都不可用，则跳过 GitHub issue 搜索，并在输出中注明已跳过。

</parallel_tasks>

4. Session Historian（前台，在启动上述 Agent 后运行——仅当用户选择加入时）

• 如果用户在后续问题中拒绝保留会话历史，则完全跳过
• 以 compound-engineering:research:session-historian 的形式调度
• 在前台调度——此 Agent 会读取工作目录之外的会话文件（~/.claude/projects/、~/.codex/sessions/、~/.cursor/projects/），后台 Agent 可能无法访问这些文件
• 搜索同一项目的 Claude Code、Codex 和 Cursor 先前会话，查找相关调查背景
• 按仓库名称关联所有平台上的会话（匹配来自主检出目录、工作树和 Conductor 工作区的会话）
• 在调度提示词中传入：

  • 对所记录问题的具体描述——不要使用泛泛的主题，而应描述具体问题（错误消息、模块名称、故障情况以及修复方法）。Agent 会根据此内容筛选其发现。

  • 当前 Git 分支和工作目录

  • 指令：“仅提取与此特定问题直接相关的先前会话发现。忽略同一会话或分支中的无关工作。”

  • 输出格式：

    Structure your response with these sections (omit any with no findings):
    - What was tried before: prior approaches to this specific problem
    - What didn't work: failed attempts at this problem from prior sessions
    - Key decisions: choices made about this problem and their rationale
    - Related context: anything else from prior sessions that directly informs this problem's documentation
    

• 省略 mode 参数，以应用用户配置的权限设置
• 使用中端模型调度（例如，在 Claude Code 中设置 model: "sonnet"）——综合结果会用于组合组装，无需前沿推理能力
• 返回：先前会话发现的结构化摘要；如果没有发现相关内容，则返回“no relevant prior sessions”

阶段 2：汇总与写入

<sequential_tasks>

等待阶段 1 的所有子 Agent 完成后，再继续。

负责统筹的 Agent（主对话）执行以下步骤：

1. 收集阶段 1 子 Agent 的所有文本结果

2. 在决定写入内容之前，检查相关文档查找器提供的重叠评估：

   重叠程度	操作
   高 — 现有文档涵盖相同的问题、根本原因和解决方案	更新现有文档，补充更新的背景信息（新的代码示例、更新的参考资料、额外的预防建议），而不是创建重复文档。保留现有文档的路径和结构。
   中 — 问题领域相同，但切入角度、根本原因或解决方案不同	正常创建新文档。标记此重叠情况，以便阶段 2.5 建议审查是否需要整合。
   低或无	正常创建新文档。

   选择更新而非新建的原因：描述相同问题和解决方案的两篇文档不可避免地会逐渐产生差异。较新的背景信息更新、更可信，因此应将其并入现有文档，而不是创建一篇很快就需要整合的第二篇文档。

   更新现有文档时，保留其文件路径和 frontmatter 结构。更新解决方案、代码示例、预防建议和过时的参考资料。在 frontmatter 中添加 last_updated: YYYY-MM-DD 字段。除非问题的表述发生了实质性变化，否则不要更改标题。

3. 纳入会话历史调查结果（如有）。如果会话历史研究员返回了相关的过往会话背景：

   • 将调查中的无果尝试和失败方案纳入「未奏效的方法」部分（问题追踪文档）或「背景」部分（知识文档）
   • 利用跨会话模式充实「预防」或「为何重要」部分
   • 为来自会话的内容加上「（会话历史）」标记，以便未来读者了解其来源
   • 如果调查结果不充分，或显示「没有相关的过往会话」，则不纳入会话背景，继续后续步骤

4. 根据收集到的内容汇总完整的 Markdown 文件；新文档的章节结构请参阅 assets/resolution-template.md

5. 根据 references/schema.yaml 验证 YAML frontmatter

6. 如有需要，创建目录：mkdir -p docs/solutions/[category]/

7. 写入文件：更新现有文档，或新建 docs/solutions/[category]/[filename].md

创建新文档时，除非用户明确要求采用其他结构，否则应保留 assets/resolution-template.md 中的章节顺序。

</sequential_tasks>

阶段 2.5：选择性刷新检查

写入新的经验后，判断这项新经验是否表明旧文档需要刷新。

ce:compound-refresh 不是默认的后续步骤。只有当新经验表明旧的经验文档或模式文档可能已不准确时，才选择性地使用它。

符合以下一项或多项情况时，可以调用 ce:compound-refresh：

1. 相关经验文档或模式文档推荐的方法与新修复方案相矛盾
2. 新修复方案明显取代了旧的文档解决方案
3. 当前工作涉及重构、迁移、重命名或依赖项升级，可能导致旧文档中的引用失效
4. 模式文档现在显得过于宽泛、过时，或不再符合更新后的实际情况
5. 相关文档查找器在同一问题领域发现了高度可信的刷新候选项
6. 相关文档查找器报告与现有文档中度重叠——可能存在整合机会，可通过有针对性的审查加以利用

以下情况不适合调用 ce:compound-refresh：

1. 未找到相关文档
2. 相关文档看起来仍与新经验一致
3. 重叠仅停留在表面，不会改变现有指导
4. 刷新需要进行范围过广、证据薄弱的历史审查

请遵循以下规则：

• 如果有一个明显过时的候选项，请在写入新经验后，附上范围明确的提示来调用 ce:compound-refresh
• 如果同一领域有多个候选项，请询问用户是否要针对该模块、类别或模式集合执行刷新
• 如果上下文已经紧张，或处于轻量模式，请勿自动扩大范围进行刷新；而应将 ce:compound-refresh 作为下一步建议，并附上范围提示

调用或建议使用 ce:compound-refresh 时，请明确说明要传入的参数。优先选择最窄且有效的范围：

• 具体文件：当某一篇经验文档或模式文档可能已过时
• 模块或组件名称：当多篇相关文档可能需要审查
• 类别名称：当偏差集中在某个解决方案类别中
• 模式文件名或模式主题：当过时的指导位于 docs/solutions/patterns/

示例：

• /ce:compound-refresh plugin-versioning-requirements
• /ce:compound-refresh payments
• /ce:compound-refresh performance-issues
• /ce:compound-refresh critical-patterns

如果某个领域、类别或模式范围内的改动会产生跨领域影响，单个范围提示仍可能扩展到多篇相关文档。

除非用户明确要求进行广泛检查，否则不要在未提供参数的情况下调用 ce:compound-refresh。

务必先记录新经验。刷新是有针对性的维护后续工作，而不是文档编写的前提条件。

可发现性检查

写入经验并作出刷新决定后，请检查项目的指令文件是否会引导 Agent 在相关领域开始工作前，先发现并搜索 docs/solutions/。每次都要执行此检查——只有 Agent 能找到知识库，知识库才能不断累积价值。

1. 确认根目录中有哪些指令文件（AGENTS.md、CLAUDE.md 或两者都有）。读取这些文件，并判断哪一个包含实质性内容——其中一个文件可能只是通过 @ 引入另一个文件的垫片（例如，CLAUDE.md 仅包含 @AGENTS.md，反之亦然）。包含实质性内容的文件才是评估和编辑目标；忽略垫片。如果两个文件都不存在，则完全跳过此检查。

2. 评估阅读指令文件的 Agent 是否能了解以下三点：

   • 存在一个可搜索的知识库，用于存放已记录的解决方案
   • 了解其结构，足以有效搜索（类别组织方式、module、tags、problem_type 等 YAML frontmatter 字段）
   • 知道何时搜索（在实现功能、调试问题，或针对已有文档记录的领域做决策之前——其中的经验总结可能涵盖 bug、最佳实践、工作流模式或其他组织知识）

   这是语义评估，而非字符串匹配。相关信息可能是架构部分中的一行、注意事项部分中的一个项目符号、分散在多个位置，也可能完全没有使用确切路径 docs/solutions/。请自行判断——如果 Agent 阅读文件后能合理地发现并使用该知识库，则视为通过检查。

3. 如果已满足上述意图，则无需采取行动——继续下一步。

4. 如果未满足： a. 根据文件现有的结构、语气和信息密度，确定在哪里自然地加入说明。创建新部分之前，先检查是否可以在最相关的部分中添加一行——例如架构树、目录清单、文档部分或约定部分。通常，在现有部分中添加一行远胜于创建新部分。只有当文件结构明确分节，且没有任何相关部分时，才将新部分作为最后手段。 b. 起草尽可能简短的补充内容，传达上述三点。与文件现有的风格和信息密度保持一致。补充内容应介绍知识库本身，而非插件——即使没有插件的 Agent，也应能从中受益。

   语气应为说明性，而非指令性。用描述方式表达时机，而不是给出指令——例如“在实现或调试已有文档记录的领域时可能相关”，而不是“实现或调试前先检查”。“实现前务必搜索”之类的祈使指令，会导致工作流已有专门搜索步骤时重复读取。目标是让 Agent 知道该文件夹的存在及其内容，然后自行判断何时查阅。

   以下示例用于把握尺度，并非模板——请根据文件调整：

   已有目录清单或架构部分时——添加一行：

   docs/solutions/  # 已记录的过往问题解决方案（bug、最佳实践、工作流模式），按类别组织，并使用 YAML frontmatter（module、tags、problem_type）
   

   文件中没有自然适合的位置时——可以添加一个简短的带标题部分：

   ## 已记录的解决方案
   
   `docs/solutions/` — 已记录的过往问题解决方案（bug、最佳实践、工作流模式），按类别组织，并使用 YAML frontmatter（`module`、`tags`、`problem_type`）。在实现或调试已有文档记录的领域时可能相关。
   

   c. 在完整模式下，向用户解释这样做的重要性——在此代码库中工作的 Agent（包括新会话、其他工具或未安装该插件的协作者）如果看不到指令文件中的相关说明，就不会知道要查阅 docs/solutions/。展示拟议的更改及其插入位置，然后使用平台提供的阻塞式提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）征求用户同意后再进行编辑。如果没有可用的提问工具，则展示提议并等待用户回复。在轻量模式下，输出一行提示后继续。

第 3 阶段：可选增强

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

<parallel_tasks>

根据问题类型，可选择调用专门的 Agent 来审查文档：

• performance_issue → compound-engineering:review:performance-oracle
• security_issue → compound-engineering:review:security-sentinel
• database_issue → compound-engineering:review:data-integrity-guardian
• 任何代码量较大的问题 → 始终运行 compound-engineering:review:code-simplicity-reviewer，并额外运行与仓库主要技术栈匹配的 kieran 审查 Agent：
  • Ruby/Rails → 还要运行 compound-engineering:review:kieran-rails-reviewer
  • Python → 还要运行 compound-engineering:review:kieran-python-reviewer
  • TypeScript/JavaScript → 还要运行 compound-engineering:review:kieran-typescript-reviewer
  • 其他技术栈 → 无需运行 kieran 审查 Agent

</parallel_tasks>

---

轻量模式

<critical_requirement> 单次处理的替代方案——文档内容相同，消耗更少 token。

此模式会完全跳过并行子 Agent。协调者在一次处理中完成所有工作，生成相同的解决方案文档，不进行交叉引用或重复项检测。 </critical_requirement>

协调者（主对话）按顺序一次性完成以下所有工作：

1. 从对话中提取信息：根据对话历史识别问题和解决方案。如果系统提示中注入了“用户的自动记忆”区块（仅限 Claude Code），也要查看该区块——将其中的相关备注作为对话历史的补充背景。最终文档中凡是纳入了来自记忆的内容，都要标注“(auto memory [claude])”
2. 分类：阅读 references/schema.yaml 和 references/yaml-schema.md，然后确定轨道（bug 或 knowledge）、类别和文件名
3. 编写最简文档：使用 assets/resolution-template.md 中相应轨道的模板，创建 docs/solutions/[category]/[filename].md，其中包括：
   • 符合相应轨道要求的 YAML frontmatter 字段
   • Bug 轨道：问题、根本原因、解决方案（包含关键代码片段）以及一条预防建议
   • Knowledge 轨道：背景、指导（包含关键示例）以及一条适用性说明
4. 跳过专门的 Agent 审查（第 3 阶段）以节省上下文

轻量模式输出：

✓ 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 /compound in a fresh session.

不启动任何子 Agent。不执行并行任务。只写入一个文件。

在轻量模式下会跳过重叠检查（不启动 Related Docs Finder 子 Agent）。这意味着轻量模式可能会创建与现有文档重叠的文档。这是可以接受的——ce:compound-refresh 稍后会发现重叠。只有在存在明确且范围狭窄的刷新目标时，才建议使用 ce:compound-refresh。不要从轻量模式会话扩展到大范围刷新。

---

记录内容

• 问题症状：确切的错误消息、可观察到的行为
• 尝试过的调查步骤：哪些方法无效以及原因
• 根本原因分析：技术说明
• 有效解决方案：分步修复方法和代码示例
• 预防策略：如何避免问题再次发生
• 交叉引用：相关问题和文档的链接

前置条件

问题已解决（而非仍在处理中） 已验证解决方案有效 问题并非微不足道（不是简单的拼写错误或明显错误）

创建内容

结构化文档：

• 文件：docs/solutions/[category]/[filename].md

根据问题自动检测类别：

Bug 轨道：

• build-errors/
• test-failures/
• runtime-errors/
• performance-issues/
• database-issues/
• security-issues/
• ui-bugs/
• integration-issues/
• logic-errors/

Knowledge 轨道：

• best-practices/
• workflow-issues/
• developer-experience/
• documentation-gaps/

应避免的常见错误

❌ 错误	✅ 正确
子 Agent 写入 context-analysis.md、solution-draft.md 之类的文件	子 Agent 返回文本数据；由编排器写入一个最终文件
研究和汇总并行执行	先完成研究 → 再进行汇总
工作流中创建多个文件	写入或更新一份解决方案文档：docs/solutions/[category]/[filename].md（另可小幅修改一个项目说明文件，以便用户发现该文档）
已有文档涵盖同一问题，却又创建新文档	检查重叠评估；重叠度高时更新现有文档

成功输出

✓ 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):
  ✓ performance-oracle: Validated query optimization approach
  ✓ kieran-rails-reviewer: Code examples meet Rails conventions
  ✓ 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

显示成功输出后，使用平台的阻塞式提问工具提供“接下来做什么？”选项（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。如果没有可用的提问工具，请列出编号选项并等待用户回复后再继续。未获得用户选择前，不要继续工作流，也不要结束当前轮次。

替代输出（因重叠度高而更新现有文档时）：

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

知识复利理念

这会构建一个不断积累的知识系统：

1. 首次解决“简报生成中的 N+1 查询” → 研究（30 分钟）
2. 记录解决方案 → docs/solutions/performance-issues/n-plus-one-briefs.md（5 分钟）
3. 下次遇到类似问题 → 快速查找（2 分钟）
4. 知识不断积累 → 团队变得更聪明

反馈循环：

Build → Test → Find Issue → Research → Improve → Document → Validate → Deploy
    ↑                                                                      ↓
    └──────────────────────────────────────────────────────────────────────┘

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

自动调用

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

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

输出

将最终经验直接写入 docs/solutions/。

适用的专业 Agent

根据问题类型，这些 Agent 可以提升文档质量：

代码质量与评审

• compound-engineering:review:kieran-rails-reviewer：根据 Rails 最佳实践评审代码示例
• compound-engineering:review:kieran-python-reviewer：根据 Python 最佳实践评审代码示例
• compound-engineering:review:kieran-typescript-reviewer：根据 TypeScript 最佳实践评审代码示例
• compound-engineering:review:code-simplicity-reviewer：确保解决方案代码简洁清晰
• compound-engineering:review:pattern-recognition-specialist：识别反模式或重复出现的问题

特定领域专家

• compound-engineering:review:performance-oracle：分析 performance_issue 类别的解决方案
• compound-engineering:review:security-sentinel：检查 security_issue 解决方案中的漏洞
• compound-engineering:review:data-integrity-guardian：评审 database_issue 迁移和查询

改进与研究

• compound-engineering:research:best-practices-researcher：为解决方案补充行业最佳实践
• compound-engineering:research:framework-docs-researcher：添加框架／库文档参考链接

何时调用

• 自动触发（可选）：Agent 可以在文档记录后运行，以改进文档
• 手动触发：用户可以在 /ce:compound 完成后调用 Agent，进行更深入的评审

相关命令

• /research [topic] - 深入调查（搜索 docs/solutions/ 中的模式）
• /ce:plan - 规划工作流（参考已记录的解决方案）