name: 事后回顾 description: 回顾已完成会话以提取可操作的改进。识别DX摩擦、文档差距、架构混乱、反模式、过程失败以及技能/配置改进。使用渐进式披露进行针对性调查类型。

事后回顾

回顾已完成会话或任务以评估其执行情况并提取改进。这包括“我们做得如何”的评估和“我们能学到什么”的调查。

何时使用

完成任何非平凡任务或会话后。目标是持续改进：

常规回顾：执行过程有多顺畅？摩擦发生在哪里？
问题会话：事情花费时间超过预期，需要多次修正
错误修复：什么导致了它，下次如何预防？
新模式：某些事情运作良好，应被编码化

调查类型

根据您调查的内容加载相关参考：

情况	加载	文件
代理在执行中遇到摩擦（错误文件、不良假设、不明确约定）	DX摩擦	`references/dx-friction.md`
文档（README、注释、API文档）错误、不完整或误导	文档差距	`references/documentation-gaps.md`
代码难以理解或内容位置意外	架构清晰度	`references/architecture-clarity.md`
错误已修复，但根本原因暗示过程差距	错误预防	`references/bug-prevention.md`
代码工作但偏离最佳实践、惯用法或已建立约定	反模式	`references/anti-patterns.md`
技能、钩子、命令、代理或`.claude/`配置需要更新	工具改进	`references/tooling-improvements.md`

当会话跨越调查类型时，加载多个参考。

核心过程

每个事后回顾都遵循四个步骤，无论调查类型如何。

1. 重建发生了什么

遍历会话时间线。对每个重要步骤，记录：

尝试了什么
实际发生了什么
哪里需要修正及原因
什么进行顺利（值得记录有效部分，不仅是问题）

暂时不要评论。仅记录序列。

2. 评估执行质量

评估会话整体情况：

效率：我们采取了直接路径还是迂回？在哪里以及为什么？
准确性：初始方法正确吗，还是需要多次修正？
工具适配：技能、命令和配置有帮助还是阻碍？
沟通：用户和代理之间的意图是否清晰？
结果：我们交付了所要求的内容吗？是牢固还是仅“暂时可用”？

标记任何感觉比应有更困难的事项，即使最终成功。

3. 识别系统性原因

对每个摩擦点，提问：“什么可以预防这种情况？”

超越第一个答案。“我应该更仔细阅读文件”是症状。“文件名称未指示其内容”或“没有文档化约定说明此类代码存放位置”是系统性原因。

良好根本原因指向可修复事项：

缺失或误导的文档片段
不一致或不可发现的架构模式
提供错误指导的技能/配置
存在但未写下的约定
允许回归的测试差距
运作良好但未编码化的工作流

不良根本原因仅是问题描述：

“我犯了个错误”
“代码复杂”
“花费时间才搞清楚”

4. 提出具体行动

每个发现应产生以下之一：

文档更新 - 修复错误文档、添加缺失文档、澄清模糊文档
技能/配置更新 - 修改现有技能或CLAUDE.md指令
新技能/钩子 - 创建新技能或钩子以编码化模式
架构改进 - 重构使系统更易发现
测试添加 - 添加测试以捕获此类问题
编码化胜利 - 运作良好的事项应使其可重复

每个行动应有具体文件路径和变更描述。模糊行动如“改进文档”不实用。

输出格式

## 会话事后回顾

### 发生了什么
[带关键决策点的会话时间线]

### 执行评估
- **结果：** [交付内容与要求内容对比]
- **效率：** [直接路径还是迂回？在哪里以及为什么？]
- **什么运作良好：** [值得重复的模式、技能或方法]

### 发现

#### 发现 1: [标题]
**发生了什么：** [摩擦或问题，事实陈述]
**根本原因：** [底层系统性问题]
**行动：** [带文件路径的具体变更]
**优先级：** [高/中/低，基于此情况复发的频率]

#### 发现 2: [标题]
...

### 总结
[1-2句话：最大收获和应首先改变的事项]