ce-compound

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/ce-compound

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

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

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 frontmatter的结构化文档，以便于搜索和未来参考。使用并行子Agent以实现最高效率。

**为什么叫"compound"？**每一份记录的解决方案都会积累团队的知识。第一次解决问题需要调研。记录下来后，下次遇到同类问题只需几分钟就能解决。知识就是这样积累起来的。

Usage

使用方法

bash

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

bash

/ce-compound                    # 记录最近的修复方案
/ce-compound [brief context]    # 提供额外的上下文提示

Support Files

支持文件

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.

这些文件是工作流的持久约定。在需要的步骤按需读取——不要在技能启动时批量加载。

```
references/schema.yaml
```
— 规范的frontmatter字段和枚举值（验证YAML时读取）
```
references/yaml-schema.md
```
— 从problem_type到目录的类别映射（分类时读取）
```
assets/resolution-template.md
```
— 新文档的章节结构（组装时读取）

生成子Agent时，将相关文件内容传入任务提示，这样它们无需跨技能路径即可获取约定信息。

Execution Strategy

执行策略

Present the user with two options before proceeding, using the platform's blocking question tool (

AskUserQuestion

in Claude Code,

request_user_input

in Codex,

ask_user

in Gemini). If no question tool is available, present the options and wait for the user's reply.

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.

Do NOT pre-select a mode. Do NOT skip this prompt. Wait for the user's choice before proceeding.

If the user chooses Full, 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, dispatch the Session Historian in Phase 1. If no, skip it. Do not ask this in lightweight mode.

在继续之前，使用平台的阻塞式提问工具（Claude Code中的

AskUserQuestion

、Codex中的

request_user_input

、Gemini中的

ask_user

）向用户提供两个选项。如果没有提问工具，则展示选项并等待用户回复。

1. 完整模式（推荐）——完整的compound工作流。调研、交叉引用并审核你的解决方案，生成能积累团队知识的文档。

2. 轻量模式——生成相同的文档，但仅单次处理。速度更快，消耗的token更少，但不会检测重复内容或交叉引用现有文档。适用于简单修复或接近上下文限制的长会话。

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

如果用户选择完整模式，在继续前询问一个后续问题。检测当前运行的工具（Claude Code、Codex或Cursor）并询问：

你是否还希望搜索你的[工具名称]会话历史，
以获取有助于Compound流程的相关知识？这会增加时间和token消耗。

如果用户同意，在阶段1调用Session Historian；如果不同意，则跳过。轻量模式下不询问此问题。

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

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

阶段1的子Agent向编排器返回文本数据。它们不得使用写入、编辑或创建任何文件的操作。只有编排器可以写入文件：阶段2中的解决方案文档，以及——如果可发现性检查发现缺口——对项目说明文件（AGENTS.md或CLAUDE.md）的小幅编辑。对说明文件的编辑属于维护操作，并非第二个交付成果；它确保未来的Agent可以发现知识存储库。 </critical_requirement>

Phase 0.5: Auto Memory Scan

阶段0.5：自动内存扫描

Before launching Phase 1 subagents, check the auto-memory block injected into your system prompt for notes relevant to the problem being documented.

Look for a block labeled "user's auto-memory" (Claude Code only) already present in your system prompt context — MEMORY.md's entries are inlined there
If the block is absent, empty, or this is a non-Claude-Code platform, 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:

undefined

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

查找系统提示上下文中已有的标记为"user's auto-memory"的块（仅Claude Code）——MEMORY.md的条目已内联在此处
如果该块不存在、为空，或者当前平台不是Claude Code，则跳过此步骤，直接进入阶段1
扫描条目，查找与要记录的问题相关的内容——使用语义判断，而非关键词匹配
如果找到相关条目，准备一个标记的摘录块：

undefined

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

将其视为额外上下文，而非主要证据。对话历史和代码库发现优先于这些笔记。

[相关条目内容]


5. 将此块作为额外上下文传递给阶段1中的Context Analyzer和Solution Extractor任务提示。如果任何内存笔记最终出现在最终文档中（例如，作为调查步骤或根本原因分析的一部分），请标记为"(auto memory [claude])"，以便未来读者清楚其来源。

如果未找到相关条目，则无需传递内存上下文，直接进入阶段1。

Phase 1: Research

阶段1：调研

Launch research subagents. Each returns text data to the orchestrator.

Dispatch order:

Launch

Context Analyzer

Solution Extractor

, and

Related Docs Finder

in parallel (background)

Then dispatch
```
ce-session-historian
```
in foreground — it reads session files outside the working directory that background agents may not have access to
The foreground dispatch runs while the background agents work, adding no wall-clock time

<parallel_tasks>

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

调度顺序：

并行启动

Context Analyzer

、

Solution Extractor

和

Related Docs Finder

（后台运行）

然后在前台调度
```
ce-session-historian
```
——它读取工作目录之外的会话文件，这些文件后台Agent可能无法访问
前台调度在后台Agent工作时运行，不会增加实际耗时

<parallel_tasks>

1. Context Analyzer

Extracts conversation history
- Reads
```
references/schema.yaml
```
  for enum validation and track classification
- Determines the track (bug or knowledge) from the problem_type
- Identifies problem type, component, and track-appropriate fields:
  - Bug track: symptoms, root_cause, resolution_type
  - Knowledge track: applies_when (symptoms/root_cause/resolution_type optional)
- Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence
- Reads
```
references/yaml-schema.md
```
  for category mapping into
```
docs/solutions/
```
- 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, suggested filename, and which track applies
- Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above
- Does not force bug-track fields onto knowledge-track learnings or vice versa

提取对话历史
- 读取
```
references/schema.yaml
```
  进行枚举验证和跟踪分类
- 根据problem_type确定跟踪类型（bug或knowledge）
- 识别问题类型、组件和适合跟踪类型的字段：
  - Bug跟踪：症状、根本原因、解决方案类型
  - Knowledge跟踪：适用场景（症状/根本原因/解决方案类型可选）
- 纳入自动内存摘录（如果编排器提供）作为补充证据
- 读取
```
references/yaml-schema.md
```
  获取
```
docs/solutions/
```
  目录的类别映射
- 使用
```
[sanitized-problem-slug]-[date].md
```
  格式建议文件名
- 返回：YAML frontmatter框架（必须包含从problem_type映射而来的
```
category:
```
  字段）、类别目录路径、建议文件名以及适用的跟踪类型
- 不得凭记忆生成枚举值、类别或frontmatter字段；必须读取上述模式文件和映射文件
- 不得将Bug跟踪字段强行应用于Knowledge跟踪的成果，反之亦然

2. Solution Extractor

Reads
```
references/schema.yaml
```
for track classification (bug vs knowledge)
- Adapts output structure based on the problem_type track
- 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
Bug track output sections:
- 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)
Knowledge track output sections:
- Context: What situation, gap, or friction prompted this guidance
- Guidance: The practice, pattern, or recommendation with code examples when useful
- Why This Matters: Rationale and impact of following or not following this guidance
- When to Apply: Conditions or situations where this applies
- Examples: Concrete before/after or usage examples showing the practice in action

读取
```
references/schema.yaml
```
进行跟踪分类（bug vs knowledge）
- 根据problem_type跟踪类型调整输出结构
- 纳入自动内存摘录（如果编排器提供）作为补充证据——对话历史和已验证的修复方案优先；如果内存笔记与对话矛盾，需将矛盾作为警示上下文记录
Bug跟踪输出章节：
- 问题：1-2句话描述问题
- 症状：可观察到的症状（错误信息、行为表现）
- 无效尝试：失败的调查尝试及其原因
- 解决方案：实际修复方案，附带代码示例（适用时提供修复前后对比）
- 原理说明：根本原因解释以及解决方案为何能解决问题
- 预防策略：避免问题复发的策略、最佳实践和测试用例。适用时提供具体代码示例（如gem配置、测试断言、 linting规则）
Knowledge跟踪输出章节：
- 背景：促使该指南产生的场景、缺口或痛点
- 指南内容：实践方法、模式或建议，适用时附带代码示例
- 重要性：遵循或不遵循该指南的理由和影响
- 适用场景：适用该指南的条件或情况
- 示例：展示实践方法的具体前后对比或使用示例

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
- Assesses overlap with the new doc being created across five dimensions: problem statement, root cause, solution approach, referenced files, and prevention rules. Score as:
  - High: 4-5 dimensions match — essentially the same problem solved again
  - Moderate: 2-3 dimensions match — same area but different angle or solution
  - Low: 0-1 dimensions match — related but distinct
- Returns: Links, relationships, refresh candidates, and overlap assessment (score + which dimensions matched)
Search strategy (grep-first filtering for efficiency):
1. Extract keywords from the problem context: module names, technical terms, error messages, component types
2. If the problem category is clear, narrow search to the matching
```
docs/solutions/<category>/
```
  directory
3. 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>
```
4. If search returns >25 candidates, re-run with more specific patterns. If <3, broaden to full content search
5. Read only frontmatter (first 30 lines) of candidate files to score relevance
6. Fully read only strong/moderate matches
7. 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>

搜索
```
docs/solutions/
```
目录中的相关文档
- 识别交叉引用和链接
- 查找相关GitHub问题
- 标记可能已过时、矛盾或过于宽泛的相关学习文档或模式文档
- 评估与新文档的重叠度，从五个维度进行：问题陈述、根本原因、解决方案方法、引用文件、预防规则。评分标准：
  - 高：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问题搜索：
优先使用
```
gh
```
CLI搜索相关问题：
```
gh issue list --search "<keywords>" --state all --limit 5
```
。如果未安装
```
gh
```
，则在可用情况下回退到GitHub MCP工具（如
```
unblocked
```
data_retrieval）。如果两者都不可用，则跳过GitHub问题搜索并在输出中注明。

</parallel_tasks>

4. Session Historian (foreground, after launching the above — only if the user opted in)

4. Session Historian（前台调度，在启动上述Agent之后——仅当用户选择启用时）

Skip entirely if the user declined session history in the follow-up question
- Dispatched as
```
research:ce-session-historian
```
- Dispatch in foreground — this agent reads session files outside the working directory (
```
~/.claude/projects/
```
  ,
```
~/.codex/sessions/
```
  ,
```
~/.cursor/projects/
```
  ) which background agents may not have access to
- Searches prior Claude Code, Codex, and Cursor sessions for the same project to find related investigation context
- Correlates sessions by repo name across all platforms (matches sessions from main checkouts, worktrees, and Conductor workspaces)
- In the dispatch prompt, pass:
  - A specific description of the problem being documented — not a generic topic, but the concrete issue (error messages, module names, what broke and how it was fixed). This is what the agent filters its findings against.
  - The current git branch and working directory
  - The instruction: "Only surface findings from prior sessions that are directly relevant to this specific problem. Ignore unrelated work from the same sessions or branches."
  - The output format:
```
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
```
- Omit the
```
mode
```
  parameter so the user's configured permission settings apply
- Dispatch on the mid-tier model (e.g.,
```
model: "sonnet"
```
  in Claude Code) — the synthesis feeds into compound assembly and doesn't need frontier reasoning
- Returns: structured digest of findings from prior sessions, or "no relevant prior sessions" if none found

如果用户在后续问题中拒绝使用会话历史，则完全跳过
- 以
```
research:ce-session-historian
```
  身份调度
- 前台调度——该Agent读取工作目录之外的会话文件（
```
~/.claude/projects/
```
  、
```
~/.codex/sessions/
```
  、
```
~/.cursor/projects/
```
  ），这些文件后台Agent可能无法访问
- 搜索同一项目的过往Claude Code、Codex和Cursor会话，查找相关调查上下文
- 通过仓库名称关联所有平台的会话（匹配主 checkout、工作树和Conductor工作区的会话）
- 在调度提示中传递：
  - 要记录的问题的具体描述——不是通用主题，而是具体问题（错误信息、模块名称、故障点及修复方式）。这是Agent过滤结果的依据。
  - 当前git分支和工作目录
  - 指令："仅展示与该具体问题直接相关的过往会话结果。忽略同一会话或分支中的无关工作内容。"
  - 输出格式：
```
按以下章节结构组织你的回复（无结果的章节可省略）：
- 过往尝试：针对该具体问题的先前解决方法
- 无效尝试：过往会话中针对该问题的失败尝试
- 关键决策：针对该问题做出的选择及其理由
- 相关上下文：过往会话中直接有助于该问题文档化的其他内容
```
- 省略
```
mode
```
  参数，以便应用用户配置的权限设置
- 使用中端模型调度（如Claude Code中的
```
model: "sonnet"
```
  ）——综合结果将用于compound组装，无需前沿推理能力
- 返回：过往会话结果的结构化摘要；如果未找到相关会话，则返回"no relevant prior sessions"

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

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 the Session History Researcher returned relevant prior-session context:
- Fold investigation dead ends and failed approaches into the What Didn't Work section (bug track) or Context section (knowledge track)
- Use cross-session patterns to enrich the Prevention or Why This Matters sections
- Tag session-sourced content with "(session history)" so its origin is clear to future readers
- If findings are thin or "no relevant prior sessions," proceed without 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
```
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
```

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>

<sequential_tasks>

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

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

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

检查Related Docs Finder的重叠度评估，再决定要写入的内容：

重叠度	操作
高 — 现有文档涵盖同一问题、根本原因和解决方案	更新现有文档，添加更新的上下文（新代码示例、更新的引用、额外的预防建议），而非创建重复文档。保留现有文档的路径和结构。
中 — 同一问题领域但角度、根本原因或解决方案不同	正常创建新文档。标记重叠情况，以便在阶段2.5建议进行合并审核。
低或无	正常创建新文档。

更新而非创建的原因：两份描述同一问题和解决方案的文档不可避免会产生差异。更新的上下文更新鲜、更可信，因此应将其整合到现有文档中，而非创建一个立即需要合并的新文档。

更新现有文档时，保留其文件路径和frontmatter结构。更新解决方案、代码示例、预防建议和任何过时的引用。在frontmatter中添加

last_updated: YYYY-MM-DD

字段。除非问题框架发生实质性变化，否则不要修改标题。

纳入会话历史结果（如果可用）。当Session History Researcher返回相关的过往会话上下文时：
- 将调查的死胡同和失败尝试整合到无效尝试章节（Bug跟踪）或背景章节（Knowledge跟踪）
- 使用跨会话模式丰富预防策略或重要性章节
- 将会话来源的内容标记为"(session history)"，以便未来读者清楚其来源
- 如果结果单薄或为"no relevant prior sessions"，则无需会话上下文直接继续
从收集的内容中组装完整的markdown文件，读取
```
assets/resolution-template.md
```
获取新文档的章节结构
根据
```
references/schema.yaml
```
验证YAML frontmatter
按需创建目录：
```
mkdir -p docs/solutions/[category]/
```
写入文件：要么是更新后的现有文档，要么是新的
```
docs/solutions/[category]/[filename].md
```

创建新文档时，保留

assets/resolution-template.md

中的章节顺序，除非用户明确要求不同的结构。

</sequential_tasks>

Phase 2.5: Selective Refresh Check

阶段2.5：选择性更新检查

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
The Related Docs Finder reported moderate overlap with an existing doc — there may be consolidation opportunities that benefit from a focused review

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

写入新的学习内容后，判断该新解决方案是否表明旧文档需要更新。

ce-compound-refresh

并非默认后续步骤。仅当新学习内容表明旧的学习文档或模式文档可能不准确时，才选择性使用。

当以下任一情况成立时，调用

ce-compound-refresh

是合理的：

相关的学习文档或模式文档推荐的方法与新修复方案相矛盾
新修复方案明显取代了旧的已记录解决方案
当前工作涉及重构、迁移、重命名或依赖项升级，可能使旧文档中的引用失效
模式文档看起来过于宽泛、过时或不再符合当前实际情况
Related Docs Finder在同一问题领域中发现高可信度的需更新候选文档
Related Docs Finder报告与现有文档中度重叠——可能存在合并机会，需集中审核

当以下情况成立时，不适合调用

ce-compound-refresh

：

未找到相关文档
相关文档仍与新学习内容一致
重叠度表面化，不改变先前的指导内容
更新需要广泛的历史回顾，但证据不足

遵循以下规则：

如果有一个明显过时的候选文档，在写入新学习内容后，调用
```
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

。

始终先捕获新的学习内容。更新是定向的维护后续步骤，而非文档化的先决条件。

Discoverability Check

可发现性检查

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:
- That a searchable knowledge store of documented solutions exists
- Enough about its structure to search effectively (category organization, YAML frontmatter fields like
```
module
```
  ,
```
tags
```
  ,
```
problem_type
```
  )
- When to search it (before implementing features, debugging issues, or making decisions in documented areas — learnings may cover bugs, best practices, workflow patterns, or other institutional knowledge)
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 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 (
```
AskUserQuestion
```
in Claude Code,
```
request_user_input
```
in Codex,
```
ask_user
```
in Gemini) to get consent before making the edit. If no question tool is available, present the proposal and wait for the user's reply. In lightweight mode, output a one-liner note and move on

写入学习内容并做出更新决策后，检查项目的说明文件是否会引导Agent在开始记录领域的工作前发现并搜索

docs/solutions/

。每次都要执行此检查——只有当Agent能找到知识存储库时，它才能积累价值。

确定存在哪些根级说明文件（AGENTS.md、CLAUDE.md或两者都有）。读取文件并确定哪个包含实质性内容——一个文件可能只是包含
```
@
```
-include另一个文件的垫片（例如，
```
CLAUDE.md
```
仅包含
```
@AGENTS.md
```
，反之亦然）。实质性文件是评估和编辑的目标；忽略垫片。如果两个文件都不存在，则完全跳过此检查。
评估读取说明文件的Agent是否能了解三件事：
- 存在可搜索的已记录解决方案知识存储库
- 足够了解其结构以有效搜索（类别组织、YAML frontmatter字段如
```
module
```
  、
```
tags
```
  、
```
problem_type
```
  ）
- 何时搜索（在实现功能、调试问题或在记录领域做出决策之前——学习内容可能涵盖bug、最佳实践、工作流模式或其他机构知识）
这是语义评估，而非字符串匹配。信息可能出现在架构章节的一行、注意事项部分的一个项目符号、多个位置，或者从未使用确切路径
```
docs/solutions/
```
来表达。运用判断——如果Agent读取文件后能合理发现并使用知识存储库，则检查通过。
如果核心要求已满足，则无需操作——继续下一步。
如果未满足： 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
```
）获取同意后再进行编辑。如果没有提问工具，则展示提案并等待用户回复。在轻量模式下，输出一行说明后继续

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 →
```
review:ce-performance-oracle
```
security_issue →
```
review:ce-security-sentinel
```
database_issue →
```
review:ce-data-integrity-guardian
```
Any code-heavy issue → always run
```
review:ce-code-simplicity-reviewer
```
, and additionally run the kieran reviewer that matches the repo's primary stack:
- Ruby/Rails → also run
```
review:ce-kieran-rails-reviewer
```
- Python → also run
```
review:ce-kieran-python-reviewer
```
- TypeScript/JavaScript → also run
```
review:ce-kieran-typescript-reviewer
```
- Other stacks → no kieran reviewer needed

</parallel_tasks>

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

<parallel_tasks>

根据问题类型，可选调用专业Agent审核文档：

performance_issue →
```
review:ce-performance-oracle
```
security_issue →
```
review:ce-security-sentinel
```
database_issue →
```
review:ce-data-integrity-guardian
```
任何代码密集型问题 → 始终运行
```
review:ce-code-simplicity-reviewer
```
，并额外运行与仓库主技术栈匹配的kieran审核Agent：
- Ruby/Rails → 同时运行
```
review:ce-kieran-rails-reviewer
```
- Python → 同时运行
```
review:ce-kieran-python-reviewer
```
- TypeScript/JavaScript → 同时运行
```
review:ce-kieran-typescript-reviewer
```
- 其他技术栈 → 无需kieran审核Agent

</parallel_tasks>

Lightweight Mode

轻量模式

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

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

Extract from conversation: Identify the problem and solution from conversation history. Also scan the "user's auto-memory" block injected into your system prompt, if present (Claude Code only) -- 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: Read
```
references/schema.yaml
```
and
```
references/yaml-schema.md
```
, then determine track (bug vs knowledge), category, and filename
Write minimal doc: Create
```
docs/solutions/[category]/[filename].md
```
using the appropriate track template from
```
assets/resolution-template.md
```
, with:
- YAML frontmatter with track-appropriate fields
- Bug track: Problem, root cause, solution with key code snippets, one prevention tip
- Knowledge track: Context, guidance with key examples, one applicability note
Skip specialized agent reviews (Phase 3) to conserve context

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.

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

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

编排器（主对话）在单次顺序处理中执行以下所有操作：

从对话中提取信息：从对话历史中识别问题和解决方案。同时扫描注入到系统提示中的"user's auto-memory"块（如果存在，仅Claude Code）——将任何相关笔记作为对话历史的补充上下文使用。将最终文档中纳入的任何内存来源内容标记为"(auto memory [claude])"
分类：读取
```
references/schema.yaml
```
和
```
references/yaml-schema.md
```
，然后确定跟踪类型（bug vs knowledge）、类别和文件名
写入极简文档：使用
```
assets/resolution-template.md
```
中相应的跟踪模板创建
```
docs/solutions/[category]/[filename].md
```
，包含：
- 适合跟踪类型的YAML frontmatter字段
- Bug跟踪：问题、根本原因、带有关键代码片段的解决方案、一条预防建议
- Knowledge跟踪：背景、带有关键示例的指南、一条适用性说明
跳过专业Agent审核（阶段3）以节省上下文

轻量模式输出：

✓ 文档已完成（轻量模式）

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

[如果可发现性检查发现说明文件未提及知识存储库：]
提示：你的AGENTS.md/CLAUDE.md未向Agent展示docs/solutions/目录——
简短提及有助于所有Agent发现这些学习内容。

注意：此文档是在轻量模式下创建的。如需更丰富的文档
（交叉引用、详细的预防策略、专业审核），
请在新会话中重新运行/ce-compound。

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

在轻量模式下，跳过重叠检查（无Related Docs Finder子Agent）。这意味着轻量模式可能创建与现有文档重叠的文档。这是可接受的——

ce-compound-refresh

会在后续检测到这种情况。仅当存在明显的窄范围更新目标时，才建议使用

ce-compound-refresh

。不要从轻量会话扩展到大规模更新扫描。

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"> 非 trivial 问题（不是简单的拼写错误或明显错误） </check> </preconditions>

What It Creates

创建内容

Organized documentation:

File:
```
docs/solutions/[category]/[filename].md
```

Categories auto-detected from problem:

Bug track:

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

Knowledge track:

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

结构化文档：

文件：
```
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/

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

❌ 错误做法	✅ 正确做法
子Agent写入 `context-analysis.md` 、 `solution-draft.md` 等文件	子Agent返回文本数据；编排器写入一个最终文件
调研和组装并行运行	调研完成 → 再执行组装
工作流中创建多个文件	仅写入或更新一个解决方案文档： `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
  ✓ 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 success output, present the "What's next?" options using the platform's blocking question tool (

AskUserQuestion

in Claude Code,

request_user_input

in Codex,

ask_user

in Gemini). If no question tool is available, present the numbered options and wait for the user's reply before proceeding. Do not continue the workflow or end the turn without the user's selection.

Alternate output (when updating an existing doc due to high overlap):

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

✓ 文档已完成

自动内存：2条相关条目用作补充证据

子Agent结果：
  ✓ Context Analyzer：识别到brief_system中的performance_issue，类别：performance-issues/
  ✓ Solution Extractor：3个代码修复方案、预防策略
  ✓ Related Docs Finder：2个相关问题
  ✓ Session History：同一分支的3个过往会话，发现2个失败的解决方法

专业Agent审核（自动触发）：
  ✓ ce-performance-oracle：验证了查询优化方法
  ✓ ce-kieran-rails-reviewer：代码示例符合Rails规范
  ✓ ce-code-simplicity-reviewer：解决方案足够简洁

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

当Email Processing或Brief System模块出现类似问题时，此文档可用于未来参考搜索。

下一步操作？
1. 继续工作流（推荐）
2. 链接相关文档
3. 更新其他引用
4. 查看文档
5. 其他

显示成功输出后，使用平台的阻塞式提问工具展示"下一步操作？"选项（Claude Code中的

AskUserQuestion

、Codex中的

request_user_input

、Gemini中的

ask_user

）。如果没有提问工具，则展示编号选项并等待用户回复后再继续。在用户做出选择前，不要继续工作流或结束对话。

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

✓ 文档已更新（现有文档已使用当前上下文刷新）

检测到重叠：docs/solutions/performance-issues/n-plus-one-queries.md
  匹配维度：问题陈述、根本原因、解决方案、引用文件
  操作：使用更新的代码示例和预防建议更新了现有文档

已更新文件：
- docs/solutions/performance-issues/n-plus-one-queries.md（添加了last_updated: 2026-03-24）

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 [context]立即记录，无需等待自动检测。 </manual_override> </auto_invoke>

Output

输出

Writes the final learning directly into

docs/solutions/

将最终学习内容直接写入

docs/solutions/

目录。

Applicable Specialized Agents

适用的专业Agent

Based on problem type, these agents can enhance documentation:

根据问题类型，这些Agent可增强文档质量：

Code Quality & Review

代码质量与审核

review:ce-kieran-rails-reviewer: Reviews code examples for Rails best practices
review:ce-kieran-python-reviewer: Reviews code examples for Python best practices
review:ce-kieran-typescript-reviewer: Reviews code examples for TypeScript best practices
review:ce-code-simplicity-reviewer: Ensures solution code is minimal and clear
review:ce-pattern-recognition-specialist: Identifies anti-patterns or repeating issues

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

Specific Domain Experts

特定领域专家

review:ce-performance-oracle: Analyzes performance_issue category solutions
review:ce-security-sentinel: Reviews security_issue solutions for vulnerabilities
review:ce-data-integrity-guardian: Reviews database_issue migrations and queries

review:ce-performance-oracle：分析performance_issue类别的解决方案
review:ce-security-sentinel：审核security_issue解决方案的漏洞
review:ce-data-integrity-guardian：审核database_issue的迁移和查询

Enhancement & Research

增强与调研

research:ce-best-practices-researcher: Enriches solution with industry best practices
research:ce-framework-docs-researcher: Links to framework/library documentation references

research:ce-best-practices-researcher：用行业最佳实践丰富解决方案
research:ce-framework-docs-researcher：链接到框架/库文档引用

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

自动触发（可选）：Agent可在文档化后运行以增强文档
手动触发：用户可在/ce-compound完成后调用Agent进行深度审核

ce-compound

Original

Translation

/ce-compound

/ce-compound

Purpose

目的

Usage

使用方法

Support Files

支持文件

Execution Strategy

执行策略

Full Mode

完整模式

Phase 0.5: Auto Memory Scan

阶段0.5：自动内存扫描

Supplementary notes from auto memory

自动内存补充笔记

Phase 1: Research

阶段1：调研

1. Context Analyzer

1. Context Analyzer

2. Solution Extractor

2. Solution Extractor

3. Related Docs Finder

3. Related Docs Finder

4. Session Historian (foreground, after launching the above — only if the user opted in)

4. Session Historian（前台调度，在启动上述Agent之后——仅当用户选择启用时）

Phase 2: Assembly & Write

阶段2：组装与写入

Phase 2.5: Selective Refresh Check

阶段2.5：选择性更新检查

Discoverability Check

可发现性检查

Phase 3: Optional Enhancement

阶段3：可选增强

Lightweight Mode

轻量模式

What It Captures

捕获内容

Preconditions

前提条件

What It Creates

创建内容

Common Mistakes to Avoid

需避免的常见错误

Success Output

成功输出

The Compounding Philosophy

积累理念

Auto-Invoke

自动调用

Output

输出

Applicable Specialized Agents

适用的专业Agent

Code Quality & Review

代码质量与审核

Specific Domain Experts

特定领域专家

Enhancement & Research

增强与调研

When to Invoke

调用时机

Related Commands

相关命令