retrospective

name	retrospective
description	通过分析已完成的工作、速率、阻碍因素和模式来生成 Sprint 或里程碑回顾。产出可执行的洞见以指导下一次迭代。
argument-hint	[sprint-N|里程碑名称]
user-invocable	true
allowed-tools	Read, Glob, Grep, Write
context	!git log --oneline --since="2 weeks ago" 2>/dev/null

当此技能被调用时：

1. 读取参数确定这是 Sprint 回顾 （sprint-N）还是里程碑回顾（里程碑名称）。

2. 读取 Sprint 或里程碑计划从相应位置：

   • Sprint 计划：production/sprints/
   • 里程碑定义：production/milestones/

   提取：计划任务、预估工作量、负责人和目标。

3. 读取 git log 以了解该 Sprint 或里程碑覆盖的时间段内 实际提交了什么以及何时提交。

4. 扫描已完成和未完成的任务，通过对比计划与实际交付物。检查：

   • 按计划完成的任务
   • 已完成但与计划有修改的任务
   • 延期任务（未完成）
   • Sprint 中途添加的任务（计划外工作）
   • 被移除或缩减范围的任务

5. 扫描代码库中的 TODO/FIXME 趋势：

   • 统计当前的 TODO/FIXME/HACK 注释数
   • 与上一 Sprint 的计数对比（如可用，检查之前的回顾）
   • 注意技术债务是在增长还是减少

6. 读取之前的回顾（如有），来自 production/sprints/ 或 production/milestones/，以检查：

   • 之前的行动项是否已处理？
   • 相同的问题是否在重复出现？
   • 速率趋势如何？

7. 生成回顾：

## 回顾：[Sprint N / 里程碑名称]
周期：[开始日期] -- [结束日期]
生成日期：[日期]

### 指标

| 指标 | 计划 | 实际 | 差异 |
|------|------|------|------|
| 任务数 | [X] | [Y] | [+/- Z] |
| 完成率 | -- | [Z%] | -- |
| 故事点 / 工作量天数 | [X] | [Y] | [+/- Z] |
| 发现的 Bug | -- | [N] | -- |
| 修复的 Bug | -- | [N] | -- |
| 新增的计划外任务 | -- | [N] | -- |
| 提交数 | -- | [N] | -- |

### 速率趋势

| Sprint | 计划 | 完成 | 完成率 |
|--------|------|------|--------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N]（当前） | [X] | [Y] | [Z%] |

**趋势**：[上升 / 稳定 / 下降]
[一句话解释趋势]

### 做得好的方面
- [由具体数据或示例支持的观察]
- [另一个正面观察]
- [认可特定贡献或取得了回报的决策]

### 做得不好的方面
- [具有可衡量影响的具体问题 — 例如 "功能 X 花了 5 天而非预估的 2 天，阻塞了任务 Y 和 Z"]
- [另一个有影响的问题]
- [不要归咎个人 — 关注系统性原因]

### 遇到的阻碍

| 阻碍项 | 持续时间 | 解决方式 | 预防措施 |
|--------|---------|---------|---------|
| [什么阻碍了进展] | [持续多久] | [如何解决] | [如何预防再次发生] |

### 估算准确性

| 任务 | 预估 | 实际 | 偏差 | 可能原因 |
|------|------|------|------|---------|
| [最严重高估的任务] | [X] | [Y] | [+Z] | [为什么] |
| [最严重低估的任务] | [X] | [Y] | [-Z] | [为什么] |

**整体估算准确性**：[X%] 的任务在预估的 +/- 20% 以内

[分析：我们是否持续高估或低估？对于哪些类型的任务？应该做何调整？]

### 延期分析

| 任务 | 原始 Sprint | 延期次数 | 原因 | 处理方式 |
|------|-----------|---------|------|---------|
| [未完成的任务] | [Sprint N-X] | [N] | [为什么] | [完成 / 缩减范围 / 重新设计] |

### 技术债务状态
- 当前 TODO 数量：[N]（上次：[N]）
- 当前 FIXME 数量：[N]（上次：[N]）
- 当前 HACK 数量：[N]（上次：[N]）
- 趋势：[增长 / 稳定 / 减少]
- [注意任何令人关注的领域]

### 上次行动项跟进

| 行动项（来自 Sprint N-1） | 状态 | 备注 |
|--------------------------|------|------|
| [上次的行动] | [已完成 / 进行中 / 未开始] | [上下文] |

### 下次迭代的行动项

| # | 行动 | 负责人 | 优先级 | 截止日期 |
|---|------|--------|--------|---------|
| 1 | [具体、可衡量的行动] | [谁] | [高/中/低] | [何时] |
| 2 | [另一个行动] | [谁] | [优先级] | [何时] |

### 流程改进
- [工作方式的具体改变，附预期收益]
- [另一项改进 — 保持在 2-3 个可执行的改进项，而非愿望清单]

### 总结
[2-3 句话整体评估：这是一个好的 Sprint/里程碑吗？下一步最重要的改变是什么？]

8. 保存回顾到相应位置：

   • Sprint：production/sprints/sprint-[N]-retrospective.md
   • 里程碑：production/milestones/[里程碑名称]-retrospective.md

   如目录不存在则创建。

9. 向用户输出摘要：完成率、速率趋势方向、首要阻碍项，以及最重要的行动项。

指南

• 要诚实和具体。模糊的回顾（"沟通可以更好"）只能产生模糊的改进。使用数据和示例。
• 关注系统性问题，而非个人责任。
• 行动项限制在 3-5 个。更多会分散注意力。
• 每个行动项必须有负责人和截止日期。
• 检查之前的行动项是否已完成。反复出现的未处理项是流程问题的信号。
• 如果这是里程碑回顾，还需评估里程碑目标是否达成，以及这对整体项目时间线意味着什么。