将最近解决的问题记录为项目中可长期复用的经验沉淀，或在 CONCEPTS.md 中记录项目专属词汇。适用于完成某项工作后沉淀经验的场景。
/ce-compound
协调多个并行工作的分支 Agent（subagent），共同将最近解决的问题记录下来。
Setup
在此次调用的开头、派发任何 subagent 之前运行一次该脚本，并遵循其输出的指令——除非某条指令与本 Skill 自身关于向用户提问的规则存在冲突。无论这些规则是仅在非交互模式下生效还是在所有模式下均生效，均以本 Skill 的规则为准，不发起任何阻塞式提问。请勿在同一次调用中重复运行；后续调用本 Skill 或其他 Skill 时会运行各自的脚本。如果没有可用的 Node 运行时，本 Skill 将按正常流程继续运行。
SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi
Purpose
在上下文记忆犹新时捕获问题解决方案，在 <root>/solutions/ 中生成带有 YAML frontmatter 的结构化文档，以便于检索和日后参考。该过程采用并行 subagent 协助完成。
为什么要复利（"compound"）？ 每份记录下来的解决方案都在为团队知识库产生复利。第一次解决某个难题需要费时调研；将其整理成文档后，下一次遇到只需几分钟即可搞定。知识就是这样不断复利的。
Usage
/ce-compound # 记录最近一次问题修复
/ce-compound [简要上下文] # 提供额外的上下文提示
/ce-compound mode:headless # 用于自动化流程的非交互模式运行
/ce-compound mode:headless [上下文] # 带有上下文提示的非交互模式运行
/ce-compound mode:headless depth:lightweight [上下文] # 低开销的非交互模式运行
/ce-compound mode:headless depth:full [上下文] # 完整的非交互模式运行
单次运行仅处理一项经验沉淀。 本工作流的凭据校验（grounding）、重叠检测和交叉引用均基于“单个已解决问题”这一前提。如果一个会话中产生了多项独立的经验沉淀，请按顺序为每项经验分别运行一次本 Skill——每次运行都会基于最新的文件树重新校验凭据。切勿在单次运行中批量处理多项经验沉淀，然后再在草稿之间缝合交叉引用；草稿撰写上下文中的临时编号（如“经验 3”）泄露到正式文档中，正是本规则要防止的失效场景。
CONCEPTS.md bootstrap requests
如果是为了从零创建或初始化（bootstrap）CONCEPTS.md 而专门调用本 Skill，而不是为了记录一个已解决的问题，请不要运行正常阶段——ce-compound 仅作为记录真实经验沉淀的副作用来填充 CONCEPTS.md（它只给该经验沉淀所属的领域补充概念，而非整个仓库；参见阶段 2.4）。全仓库范围的概念地图创建是 ce-compound-refresh 的职责。如果收到独立的初始化请求，请将其重定向至 ce-compound-refresh（它会询问是构建概念地图还是运行刷新周期），然后退出。
Mode Detection
当满足以下任一条件时进入无头（headless）模式：传入的调用参数包含 mode:headless 标识，或者调用的意图极其明确地表达了非交互需求——例如调用方或常驻指令要求“无头”、“非交互”、“无人值守”或“无需提示/提问”地运行 ce-compound。参数标识是显式形式；自然语言中清晰的非交互运行请求效果完全相同。仅凭“自动”或“自动运行”字眼并不算作无头模式的信号——它表达的是如何触发该 Skill，而不是抑制其交互提示——因此对于模糊或缺失的信号，默认按交互模式处理。以 mode: 或 depth: 开头的参数标识为 Flag 开关，而非上下文参数——在将其余部分作为简要上下文提示处理之前，应先剔除这些 Flag。
depth 是仅在无头模式下生效的显式深度选择器。在无头模式下，最多接受一个 depth 标识：depth:lightweight 直接路由至轻量模式（Lightweight Mode）；而 depth:full 路由至完整模式（Full Mode）并自动触发历史会话探测。含有 mode:headless 但未带 depth: 标识的情况保持向下兼容，默认运行完整模式。无头轻量模式不会提出任何阻塞式问题，也不会启动任何 subagent。如果调用中包含未知的 depth: 标识、多个 depth: 标识，或者在没有无头意图的情况下使用了 depth: 标识，不要擅自猜测；输出带具体原因的无头模式失败报告，并以 Documentation skipped 结束。
| 模式 | 触发条件 | 行为说明 |
|---|---|---|
| 交互模式（默认） | 无 headless 标识且无明确的非交互意图 | 自动评估并选择完整模式或轻量模式，并报告选择结果；自动触发历史会话探测（仅限完整模式）；提示用户授权可发现性检查（Discoverability Check）；以简要总结结尾（不提供“后续步骤”菜单） |
| 无头模式 | 存在 mode:headless 标识，或调用意图极其明确地表达了非交互需求 |
无阻塞式提问。按显式请求的深度运行，默认使用完整模式（包含自动历史会话探测）。若可发现性检查发现遗漏，仅作报告而不修改指令文件。跳过阶段 3 的专项评审。以结构化的终端报告结尾——不提供“后续步骤”菜单。 |
无头模式专为没有人类在场回答问题的自动化流程和 Skill 间调用而设计。一旦识别出该模式，将贯穿整个运行过程。
Session context
在阶段 1 过滤历史会话之前，通过 shell 工具在运行时解析两个值。分别作为独立命令运行并读取其退出状态——在这里，非零退出状态属于正常状态，并非需要妥协绕过的错误：
- Git 分支 — 运行
git rev-parse --abbrev-ref HEAD。在阶段 1 中使用该分支名称过滤历史会话。如果返回HEAD（处于分离头指针状态）或退出码非零（非 git 仓库），则跳过分支过滤。 - 仓库根目录 — 运行
git rev-parse --show-toplevel。在阶段 1 中将其作为历史会话的仓库过滤器。如果退出码非零（非 git 仓库），则回退使用当前工作目录。
Support Files
这些文件构成了工作流的持久化契约。请在需要它们的具体步骤中按需读取，切勿在 Skill 启动时批量加载。
references/schema.yaml— 规范的 frontmatter 字段和枚举值（在校验 YAML 时读取）references/yaml-schema.md— 从 problem_type 到目录的分类映射表（在分类时读取）references/concepts-vocabulary.md— CONCEPTS.md 的格式与写入规则（在阶段 2.4 浮现领域术语时读取）references/agents/session-historian.md— Skill 本地的合成提示词，用于可选的历史会话复利上下文（仅在用户选择启用历史会话时读取）references/grounding-validation.md— 凭据校验协议：标记裁决规则与语义校验器提示词（在阶段 2.45 中读取）assets/resolution-template.md— 新文档的章节结构模板（在组装文档时读取）scripts/session-history/— 打包进本 Skill 的会话发现与提取脚本，确保历史会话支持完全自包含scripts/validate-frontmatter.py— frontmatter 解析安全校验器（在阶段 2 步骤 8 中通过记载的存在性防线运行；将SKILL_DIR设置为本 Skill 目录，若脚本缺失则回退至人工检查清单）scripts/validate-doc-claims.py— 机械式声明校验器：引用的路径、commit SHA、相对链接、残留的草稿脚手架（在阶段 2.45 中通过SKILL_DIR锚点运行）
派发 subagent 时，将相关文件内容传入任务提示词中，使其直接获得契约内容，无需跨 Skill 路径读取。
Artifact Root
本 Skill 在 <root>/solutions/ 目录下写入和读取经验沉淀。当首次组装 <root>/solutions/ 路径时（按下方配置块）解析 <root>；向 subagent 传递搜索或写入范围时，请传递解析后的 <root>/solutions/ 绝对/相对路径，而不是原始配置。
<!-- ce-docs-root:start -->
在组装任何产物路径之前，必须先解析 CE 产物根目录 <root>。
- 读取
<repo-root>/.compound-engineering/config.local.yaml中的docs_root，若为空则读取config.yaml；以第一个非空值为准（<repo-root>=git rev-parse --show-toplevel）。若均未设置 -><root>保持为docs，与之前完全一致。 - 校验 已设置的值：必须是相对于仓库的目录路径，且其通过符号链接解析后的真实路径必须保留在仓库内部，既不能是仓库根目录，也不能在
.git/之下。否则终止运行并报错指出docs_root及该非法值——切勿直接回退至docs。 - 使用
<root>作为唯一的产物存放位置：若不存在则创建，按<root>/<subdir>格式拼接包含本 Skill 子目录的完整路径，绝不再同时读取docs。
<!-- ce-docs-root:end -->
Execution Strategy
ce-compound 不会向用户询问运行哪种模式或是否搜索历史会话。这两者都是 Agent 能够做出更好决策的事项：模式取决于 Agent 能观察到的上下文预算，而历史会话的价值在事前对双方都是未知的（收益在于当前 Agent 未曾参与的无关联历史会话），因此通过一次低成本的探测即可决定，无需发问。整个工作流中唯一的交互式提示是可发现性检查的授权提示，因为该操作会修改被版本控制跟踪的指令文件。
模式选择（完整模式 vs 轻量模式）——由 Agent 直接决定，切勿询问用户。
- 默认选择完整模式（Full Mode）：完整的工作流（调研、交叉引用、重叠检测、凭据校验）。对于绝大多数记录下来的经验沉淀而言，这都是正确的选择——相较于产生该经验的工程投入以及文档沉淀带来的复利价值，其消耗的 Token 成本微乎其微。
- 仅在遇到真实的上下文压力时才选择轻量模式（Lightweight Mode，单次处理、不启动 subagent——详见轻量模式）：如会话接近上下文上限，或修复极其简单以至于交叉引用毫无价值。这些都是 Agent 可以观察而用户无法察觉的条件，这也正是为何不将其作为问题询问用户的原因。
- 在完成输出的第一行明确声明所选模式及一行简要原因（例如：“已运行完整模式。” / “已运行轻量模式——由于会话上下文偏紧。”）。如果轻量模式不符合用户的喜好，重新运行是一项罕见且低成本的修正——比每次运行都用提示词打扰用户成本低得多。
在无头模式下，跳过自动模式选择。运行模式检测期间选定的深度：depth:lightweight 进入轻量模式；depth:full 或未指定 depth 标识则进入完整模式，包括自动历史会话探测（阶段 1 步骤 4）。
历史会话——完整模式下的自动探测，绝不发问。 检索先前会话的意义在于，某个毫无关联的早期会话中可能包含相关问题的解决方案；无论是 Agent 还是用户都无法在事前预知这一点，因此发问毫无意义。相反，完整模式始终会运行低成本的“发现+元数据”探测（阶段 1 步骤 4）——它与调研 subagent 并行运行，在实际耗时上几乎零开销——只有当探测表面确实存在高度相关的候选会话时，才会升级到高成本的提取与合成阶段。轻量模式完全跳过历史会话；无头完整模式运行相同的自动探测，因其不弹出任何提示，故保持了无头模式的非交互特性。此支持仅存在于复利工作流内部；不存在独立的历史会话产品入口。
Full Mode
<critical_requirement>
核心交付物为单个文件——最终的文档。
阶段 1 的 subagent 将其完整的结构化输出写入 <run-dir>/ 下的单次运行临时产物中，仅返回包含该产物路径的简要确认信息。协调器（orchestrator）在阶段 2 组装时再读回这些产物。T
<!-- truncated for translation batch; full body continues in source -->
