在评审后需要沉淀经验时使用：记录教训、根因与修复…

在一次完整聊天线程中完成工作或评审后，用于把经验教训沉淀到项目文件并列出后续 compound 动作。

适用场景

解决思路

1. 将 “this conversation” 理解为完整聊天线程，即用户调用 compound 的同一 chat 中所有消息；教训和 compound 动作来自该线程中任何位置已完成或决定的工作。
2. 在范围内纳入：同一 chat 中先前完成的工作、其他 skill 运行（例如 `/ppp-weekly-report`、`/groove-work-plan`）、文件或 bean 编辑、决策、评审或规划讨论。
3. 纳入用户或线程作为工作流一部分提到的任何 bean 或 work item（例如本次 compound 阶段所属的 epic 或 task），用它们支撑教训和动作。
4. 除非用户要求，不纳入 daily memory、weekly summaries 或其他文档（例如 “compound on the whole day”）。
5. 如果运行 compound 时上下文中看不到其他工作（例如该回合只显示 compound 请求），询问要沉淀哪个 session 或工作（例如“我只看到 compound 请求。应 compound 哪个 session——例如上面的 PPP 运行，还是其他？”），不要得出“未讨论工作”的结论。
6. 记录 lessons、root causes 和 fixes，并以根因分析记录教训：不仅失败是什么，还要为什么。
7. 更新相关项目文件：rules files、templates、docs、task bodies。
8. 生成 compound actions checklist，并将每个动作标记为 done 或 pending。
9. 如果检测到用户挫败（frustration）模式，专门捕获它们。
10. 将 “No new lessons” 作为明确可接受的结果——捕获它，而不是跳过。
11. 从 `.groove/index.md` 读取 `tasks.backend`；memory 路径始终为 `.groove/memory/`。
12. 如果 `.groove/.cache/pending-capture.md` 存在（由 `session-capture` Stop hook 暂存），先读取它，并用其中的 commits/working-changes 作为 lessons 和 git context 的真值来源，以免遗忘或被压缩的 session 丢失。
13. 在记录 compound 阶段后，删除 `.groove/.cache/pending-capture.md`。
14. 在生成 compound actions checklist 前，通过 `/groove-utilities-memory-mistakes --list` 检查 open mistake incidents。
15. 如果存在 open incidents：使用 `/groove-utilities-memory-mistakes` 的 log → fix → audit → resolve 循环处理每个 incident，然后再继续。
16. 将 “mistakes: N incident(s) resolved → learned/<topic>” (done/pending) 加入 compound checklist。
17. 如果没有 open incidents：静默跳过。
18. 将输出写入已有项目文件；除非必要，不创建新文件。
19. 即使看起来 “nothing to capture” 也始终运行，并明确捕获这一点。
20. compound actions checklist 必须包含每个动作为什么重要，而不只是动作是什么。
21. 如果用户表现出重复修复、困惑或返工，捕获该模式及其 trigger。
22. 如果 `tasks.backend != none`，通过 `/groove-utilities-task-create` 在 backend 创建 stage task，并给描述性标题，使一天内多次 compound 可区分：`YYYY-MM-DD, Compound — <brief topic>`（topic 来自刚关闭的工作，例如 release、feature 或 session summary）。
23. 不要在 task 标题中给 stage 编号。
24. 在生成 compound actions checklist 后，识别任何关于 AI workflow、agent behaviour、tool usage 或 engineering process 的 lesson，而不是特定于 codebase 或 product 的 lesson。
25. 如果发现任何此类 lesson，提议：“Workflow learning detected — add to .groove/memory/learned/<suggested-topic>.md?”
26. 根据内容建议 topic 名称（例如 `patterns`、`tools`、`anti-patterns`、`hooks`）。
27. 等待用户确认、选择不同 topic 或跳过。
28. 如果确认：将 lesson 作为 bullet 追加到文件中 `## <YYYY-MM-DD>` 标题下；如果文件不存在，用 `# <Topic>` 标题创建；如果日期标题不存在则创建。
29. 将 “workflow learning → .groove/memory/learned/<topic>.md” (done/pending) 加入 compound checklist。
30. 如果没有 workflow lessons，完全跳过此步骤——不提示、不打扰。
31. 如果 workflow learning 已在本地捕获且 `.groove/index.md` 中设置了 `groovebook:`，在 checklist 后添加一行建议：“Learning captured → `.groove/memory/learned/<topic>.md`. Publish to groovebook? Run `/groove-groovebook-publish`。”
32. 如果 `groovebook:` 不存在：静默跳过。
33. 在 workflow learning 捕获后，提供 graduation 建议：“Is this lesson stable enough to apply to every future session? Run `/groove-utilities-memory-graduate <topic>` to promote it to AGENTS.md permanently.”；仅在 lesson 刚被确认时建议，不是每次 compound 运行都建议。
34. 在 workflow learning 步骤后，扫描对话中的 deferred items——短语如 “we'll come back to”、“do this later”、“next time”、“TODO”、“skip for now”、“won't fix today”。
35. 如果发现任何 deferred items：列出它们并问：“Capture any of these as promises? (numbers, or enter to skip)”；对每个确认项运行 `/groove-utilities-memory-promises <text>`。
36. 如果没有发现：静默跳过。
37. 在 workflow learning 步骤后，提示可选 session rating：“Rate this session (1–5): how well did the compound loop serve you? (enter to skip)”。
38. 如果用户提供 rating：追加到 `.groove/memory/learned/signals.md` 的 table 下；如果文件不存在，用 header 和 table header row 创建文件。
39. 使用格式：`| YYYY-MM-DD | <rating>/5 | <one-line context from the session topic> |`。
40. 如果用户跳过：不要再提。

适用边界 · 注意事项

• 不用于 daily memory、weekly summaries 或其他文档，除非用户明确要求。
• 当上下文中看不到除 compound 请求外的其他工作时，不要直接判定“未讨论工作”并跳过；应先询问要沉淀哪个 session 或工作。
• 没有 `.groove` 项目结构及 `/groove-utilities-*` 等 groove 工具链时，不应使用（依赖 `tasks.backend`、`.groove/memory/`、`groovebook:` 等）。