当已解决且验证的问题包含无法从最终代码/测试/文档恢复的项目…

适用于把已解决且验证、但最终产物无法解释的非显而易见项目推理，沉淀为 `<root>/solutions/` 下的单条持久学习文档。

适用场景

解决思路

1. 每次运行只写一个 learning；如果一次 session 产生多个，顺序多次运行，绝不把它们批处理；先读 `references/research.md`，它解释批处理会破坏什么。
2. 只记录已解决且验证的问题；在写入前确认问题已解决并验证。
3. 应用 durable bar 反问：如果该 learning 文档消失，未来工程师读最终实现是否仍可能重复错误或重做大量调查；只有文档持有无法从最终代码、测试、类型、注释或现有文档轻易恢复的持久项目推理，且丢失会导致复发、重大风险或大量重新发现时，才写该 learning；完成、努力、diff 大小不确立资格。
4. 如果上述反问失败，不写任何内容，并报告为什么。
5. 从 session 本身判断 eligibility，而不是询问用户；显式调用只表示现在要判断，不降低 bar。
6. 如果现有 learning 变得实质不准确或不完整，更新该 learning 而不是创建重复，因为留下它会误导。
7. 不要用 `ce-compound` 引导 `CONCEPTS.md`；它只作为副作用播种 learning 自己的区域，绝不整个 repo；要创建或引导 `CONCEPTS.md`，向 `ce-compound-refresh` 发送独立请求，然后退出。
8. 识别调用形式：`/ce-compound [brief context]`、`/ce-compound mode:non-interactive depth:lightweight [context]`、`/ce-compound mode:non-interactive depth:full [context]`。
9. 当参数包含 `mode:non-interactive` 或废弃别名 `mode:headless`，或调用明确表达非交互意图（如 caller/standing instruction 要求 “headless”、“non-interactively”、“unattended”、“without prompts/questions”）时，进入 non-interactive 模式；两个 token 同时出现不冲突。
10. 不要把单独的 “automatically” 或 “auto-run” 当作 non-interactive 信号，因为它只表示调用技能，不表示抑制提示。
11. 模糊或缺省信号默认 interactive 模式。
12. 把以 `mode:` 或 `depth:` 开头的 token 当作 flags，而不是 context；在把剩余部分作为 brief context hint 前剥离它们。
13. 一旦检测到 non-interactive 模式，就让它适用于整个运行。
14. 只在 non-interactive 模式下通过显式 token 选择 depth，且最多接受一个 depth token。
15. 遇到 `depth:lightweight` 时直接路由到 Lightweight Mode。
16. 遇到 `depth:full` 或没有 depth token 时进入 Full Mode，包括其自动 session-history 探测；非交互调用没有 depth token 时按既有行为处理。
17. 在 non-interactive lightweight 中不要问阻塞问题，也不要启动 subagents。
18. 如果调用带未知 `depth:` token、多个 `depth:` token，或带 `depth:` token 但没有 non-interactive 意图，不要猜测；发出带原因的 non-interactive failure report，并以 `Documentation skipped` 结束。
19. Non-interactive 模式在任何阶段都不问任何阻塞问题，因为 caller 无人可答。
20. 每个 non-interactive 退出（包括任何 phase 之前退出）都以 caller 可解析的终端信号结束：`Documentation complete`，或未写文档时 `Documentation skipped` 并带原因。
21. Interactive 模式只在步骤自己的 reference 指示的地方提问：Discoverability Check consent；当多个 stale docs 在起作用时问运行哪个 refresh。
22. 首次组合 `<root>/solutions/` 路径时解析 `<root>`，并把解析后的路径传给 subagent，而不是传配置。
23. 在组合任何 artifact 路径前解析 CE artifact root `<root>`。
24. 只从 `<repo-root>/.compound-engineering/config.yaml` 读取 `docs_root`（`<repo-root>` = `git rev-parse --show-toplevel`），不要从 `config.local.yaml` 读取；未设置时 `<root>` 为 `docs`，与之前相同。
25. 验证设置的值：它必须是 repo-relative 目录，其真实、符号链接解析后的路径仍在 repo 内，且既不是 repo root 也不在 `.git/` 下。
26. 如果验证失败，停止并报错，指名 `docs_root` 和值；绝不回退到 `docs`。
27. 把 `<root>` 作为唯一 artifact 位置：不存在则创建；每个路径按 `<root>/<subdir>` 组合，带此技能自己的子目录；绝不同时读 `docs`。
28. 只有 orchestrator 写 product files；Phase 1 subagents 只写 per-run scratch，绝不触碰 `<root>/`、项目 instruction 文件或任何其他 tracked path。
29. Orchestrator 在 `<root>/solutions/` 下写一个 learning，并执行两个维护副作用：在 vocabulary capture 期间写 `CONCEPTS.md`；仅在 interactive Full mode 经 consent 后，在项目 instruction 文件中写一条小 discoverability line。
30. 另外两个写入仅存在于 interactive Full mode，且用户在 assembly destination step 选择它们时：在可写声明的 Compound Pack 内写 rule file，以及把 `packs:` entry 追加到 `.compound-engineering/config.yaml`。
31. 当 `CONCEPTS.md` 不存在时创建它是预期行为，不是违规；instruction file 只编辑，绝不创建；树中其他内容不写。
32. 编辑 *其他* docs 属于 `ce-compound-refresh`；此技能可以推荐或用窄范围调用它，但绝不代替它。
33. 在 step 1 前读 `references/modes.md`；interactive run 自己选 depth 而不是问用户，且 depth choice 与 session history 都不是问题；默认 Full；仅当 session 接近 context limit 时选 Lightweight。
34. Lightweight mode 完全跳过 session history；non-interactive Full 运行同样自动探测，且不提问，因此保持非交互契约。
35. Full Mode 按顺序运行以下步骤，且每个步骤命名时的 reference 是必需读取：1) Research：读 `references/research.md`。
36. 2) Session history：读 `references/session-history.md`，并在启动 parallel block 后启动它，使两者重叠而不是串行；Session history 是最终 Phase 1 输入，不是 workflow stop；当它返回（包括 `no relevant prior sessions`）时，直接进入 assembly，不暂停或总结。
37. 3) Assembly and write：等待每个 Phase 1 输入，然后读 `references/assembly.md`。
38. 4) Refresh check and discoverability：读 `references/refresh-and-discoverability.md`。
39. 5) Optional enhancement：读 `references/enhancement.md`；仅交互。
40. 6) Report：读 `references/report.md`，了解你的模式必须发出的报告形状以及技能如何结束。
41. Lightweight Mode 用单次 pass 替换 steps 1-6；读 `references/lightweight.md`，它定义两种模式的完成输出。
42. 完成标准：写入或更新符合条件 doc，验证其 frontmatter 和 claims，记录 vocabulary capture，并发出该 mode 的完成报告；当没有 learning 符合时，什么都不写，并报告原因。
43. 最终产出：将符合条件的一个已解决问题写成 `<root>/solutions/` 下的 durable learning，基于当前 tree，并使下一个 agent 可发现。

适用边界 · 注意事项

• 常规修复，其代码、测试、类型、注释或现有文档已经清楚解释了教训时，不要写。
• 问题尚未解决或未验证时，不要写。
• 如果丢失该学习文档后，未来工程师读最终实现仍不太可能重复错误或重做大量调查，则不要写；完成度、努力、diff 大小不构成资格。