retrospective

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,qa.level

回顾

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终询问 · 引导模式仅询问重大事项 · 自主模式记录并继续； automation_always_ask 类别始终提示）。

输入不足 — 生成任何报告前先检查

如果此技能所需的输入不存在，答案就是“无法运行”—— 而不是一份填好的报告。 先检查，检查失败就停止。

1. 列出此技能读取的输入（数据文件、先前的报告、分析器输出、 测试结果、注册表、源代码）。
2. 对每项记录 FOUND 或 ABSENT——不要“假设存在”。
3. 如果某个部分所需的任何输入为 ABSENT，该部分应标记为 NOT ASSESSED — NO DATA。不要估算，不要根据相邻产物推断，也不要把必须填写的单元格留给 下一个阅读模板的人来填写。
4. 如果所有必需输入均为 ABSENT，请停止，并将 NOT ASSESSED — NO DATA 作为整体结论，说明缺失了什么，以及由哪个技能生成这些内容。

结论为 NOT ASSESSED 是成功的。 当没有数据时，这是对“数据说明了什么？”的正确且有用的回答。此处要防止的具体失败模式是： 结论枚举中没有“无法运行”状态的报告会产生虚假的无问题通过——例如，在没有资产、也没有标准的项目上，资产审计却返回 COMPLIANT；或在没有任何分析器数据且从未设定预算的情况下，性能分析却报告“相对于 16.67ms 预算有 >99% 的余量”。

没有证据不等于证据表明不存在。 如果没有可扫描的文件，扫描未找到匹配项并不能证明任何事情。请说明实际发生的是哪一种情况——读者无法从绿色结果中判断。

---

阶段 1：解析参数

确定这是冲刺回顾（sprint-N）还是里程碑回顾（milestone-name）。

---

阶段 1b：检查是否已有回顾

加载任何数据前，先用 glob 查找现有回顾文件：

• 冲刺回顾：production/retrospectives/retro-[sprint-slug]-*.md （也检查备用位置 production/sprints/sprint-[N]-retrospective.md）
• 里程碑回顾：production/retrospectives/retro-[milestone-name]-*.md

如果找到匹配的文件，请使用 AskUserQuestion：

• 提示：“已找到现有回顾：[filename]。你想如何继续？”
• 选项：
  • [A] 更新现有回顾 — 加载它，并根据新数据添加／修订章节
  • [B] 重新开始 — 生成新的回顾（归档旧回顾）

如果选择 [A]：读取现有文件并沿用其内容，根据新数据修订相关章节。 如果选择 [B]：以空白状态继续阶段 2。写入新文件前，将现有文件重命名，并添加 -archived-[date] 后缀。重命名也是写入操作：仅在阶段 5 中、且该阶段的询问（会说明重命名事项）获批后执行。

---

阶段 2：加载冲刺或里程碑数据

从相应位置读取冲刺或里程碑计划：

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

还要检查 production/sprint-status.yaml：如果文件存在，请与冲刺计划一并读取。它是实际故事完成状态（状态：done、完成日期、阻塞项）的权威来源。将其作为阶段 3 完成指标的主要来源。只有在 yaml 不存在时，才通过扫描 Markdown 文件进行补充。请注明 yaml 与冲刺计划之间的差异（例如，yaml 中有计划里没有的故事，反之亦然）。

如果文件不存在或为空，请输出：

“未找到 [冲刺/里程碑] 的冲刺数据。运行 /sprint-plan new 创建冲刺 （/sprint-status 只能读取冲刺），或手动提供冲刺详情。”

如果 workflow: minimal（上文已解析），则没有冲刺：改为询问用户是否要回顾迄今已关闭的故事（production/epics/*/story-*.md 中 Status: Complete 的故事）。 如果 qa.level: minimal（上文已解析），则免除测试，因此，关闭时没有测试的故事不算问题；但关闭时没有保留截图的 Visual/Feel 或 UI 故事仍算问题。

然后使用 AskUserQuestion 提供以下选项（仅在 workflow: minimal 时提供 [C]）：

• [A] 手动提供数据 — 请用户粘贴或描述冲刺任务、日期和结果；将其作为回顾的事实依据。
• [B] 停止 — 中止该技能。判定：BLOCKED — 没有可用的冲刺数据。
• [C] 回顾已关闭的故事 — 将 Status: Complete 的故事作为已完成工作的记录。

如果用户选择 [A]，收集数据并使用用户提供的内容继续阶段 3。 如果用户选择 [B]，立即停止。 如果用户选择 [C]，读取这些故事并继续阶段 3。需要冲刺数据的部分（计划与实际、速度、延期、估算准确度）标记为 NOT ASSESSED — NO DATA。

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

运行 git log，了解冲刺期间实际提交的内容及提交时间。使用 Bash 工具（在 Windows 上使用 Git Bash — 2>/dev/null 是 bash 语法，不是 PowerShell 语法）：

Bash: git log --oneline --since="4 weeks ago" 2>/dev/null || git log --oneline -20

如果冲刺计划中提供了冲刺时长，请相应调整 --since 日期。

---

阶段 3：分析完成情况和趋势

通过对比计划和实际交付成果，检查已完成和未完成的任务。检查以下内容：

• 按计划完成的任务
• 已完成但与计划有所不同的任务
• 延期任务（未完成）
• 冲刺中途新增的任务（计划外工作）
• 已移除或缩减范围的任务

production/sprint-status.yaml 中每个 status: blocked 的故事都应列入遇到的阻塞项，其 blocker 字段作为阻塞原因，并在下一迭代的行动项中为其添加行动项。

扫描代码库，了解 TODO/FIXME 趋势：

• 统计当前 TODO/FIXME/HACK 注释数量
• 如果有往期冲刺统计（检查之前的回顾），与之对比
• 指出技术债是在增加还是减少

读取之前的回顾（如有），路径为 production/retrospectives/，并检查：

• 之前的行动项是否已落实？
• 是否有相同问题反复出现？
• 速度趋势如何？

如果没有更早的冲刺或回顾，速度趋势只保留当前冲刺的行，并标注为 NOT ASSESSED — NO DATA；之前行动项跟进部分只写这一行，不要编造更早的行，也不要创建空表格。

---

阶段 4：生成回顾

## Retrospective: [Sprint N / Milestone Name]
Period: [Start Date] -- [End Date]
Generated: [Date]

### Metrics

| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Tasks | [X] | [Y] | [+/- Z] |
| Completion Rate | -- | [Z%] | -- |
| Story Points / Effort Days | [X] | [Y] | [+/- Z] |
| Bugs Found | -- | [N] | -- |
| Bugs Fixed | -- | [N] | -- |
| Unplanned Tasks Added | -- | [N] | -- |
| Commits | -- | [N] | -- |

### Velocity Trend

| Sprint | Planned | Completed | Rate |
|--------|---------|-----------|------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N] (current) | [X] | [Y] | [Z%] |

**Trend**: [Increasing / Stable / Decreasing — or `NOT ASSESSED — NO DATA` with no earlier sprint to compare]
[One sentence explaining the trend]

### What Went Well
- [Observation backed by specific data or examples]
- [Another positive observation]
- [Recognize specific contributions or decisions that paid off]

### What Went Poorly
- [Specific issue with measurable impact -- e.g., "Feature X took 5 days
  instead of estimated 2, blocking tasks Y and Z"]
- [Another issue with impact]
- [Do not assign blame -- focus on systemic causes]

### Blockers Encountered

| Blocker | Duration | Resolution | Prevention |
|---------|----------|------------|------------|
| [What blocked progress] | [How long] | [How it was resolved] | [How to prevent recurrence] |

### Estimation Accuracy

| Task | Estimated | Actual | Variance | Likely Cause |
|------|-----------|--------|----------|--------------|
| [Most overestimated task] | [X] | [Y] | [+Z] | [Why] |
| [Most underestimated task] | [X] | [Y] | [-Z] | [Why] |

**Overall estimation accuracy**: [X%] of tasks within +/- 20% of estimate

[Analysis: Are we consistently over- or under-estimating? For which types of
tasks? What adjustment should we apply?]

### Carryover Analysis

| Task | Original Sprint | Times Carried | Reason | Action |
|------|----------------|---------------|--------|--------|
| [Task that was not completed] | [Sprint N-X] | [N] | [Why] | [Complete / Descope / Redesign] |

### Technical Debt Status
- Current TODO count: [N] (previous: [N])
- Current FIXME count: [N] (previous: [N])
- Current HACK count: [N] (previous: [N])
- Trend: [Growing / Stable / Shrinking]
- [Note any areas of concern]

### Previous Action Items Follow-Up

| Action Item (from Sprint N-1) | Status | Notes |
|-------------------------------|--------|-------|
| [Previous action] | [Done / In Progress / Not Started] | [Context] |

### Action Items for Next Iteration

| # | Action | Owner | Priority | Deadline |
|---|--------|-------|----------|----------|
| 1 | [Specific, measurable action] | [Who] | [High/Med/Low] | [When] |
| 2 | [Another action] | [Who] | [Priority] | [When] |

### Process Improvements
- [Specific change to how we work, with expected benefit]
- [Another improvement -- keep it to 2-3 actionable items, not a wish list]

### Summary
[2-3 sentence overall assessment: Was this a good sprint/milestone? What is
the single most important thing to change going forward?]

---

阶段 5：保存回顾

向用户展示回顾和主要发现（完成率、速度趋势、最主要的阻碍、最重要的行动项）。

询问：“我可以将其写入 production/retrospectives/retro-sprint-[N]-[date].md 吗？”（里程碑回顾则使用 production/retrospectives/retro-[milestone-name]-[date].md）

在阶段 1b 中选择重新开始后，同一个询问还要提及重命名：“……并将 [old file] 重命名为 [old file name]-archived-[date].md 吗？”若用户同意，先重命名，再写入；若用户不同意，两项操作都不执行。

若用户同意，则写入文件；如有需要，创建 production/retrospectives/ 目录。结论：已完成 — 回顾已保存。

若用户不同意，则到此为止。结论：已阻止 — 用户拒绝写入。

---

阶段 6：后续步骤

如果 workflow: minimal（上文已确定），由于没有冲刺，请跳过此问题：指出回顾文件，并说明其中的行动项会纳入简报的构建顺序。

否则，使用 AskUserQuestion：

• 提示词：“回顾已完成。行动项和速度数据已就绪。您想现在开始冲刺规划，并预先载入这些数据吗？”
• 选项：
  • [A] 是 — 开始冲刺规划，并预先填入回顾行动项和速度变化
  • [B] 否 — 准备好时，我会手动参考回顾文件

如果用户选择 [A]：调用 /sprint-plan new，并传入回顾文件路径以及行动项和速度变化的摘要，供冲刺规划器参考。

• 如果这是一次里程碑回顾，则运行 /gate-check，正式评估是否已准备好进入下一阶段。

指南

• 诚实且具体。含糊的回顾（“沟通可以更好”）只会带来含糊的改进。请使用数据和示例。
• 关注系统性问题，而非归咎于个人。
• 将行动项限制在 3-5 项。过多会分散重点。
• 每项行动都必须有负责人和截止日期。
• 检查之前的行动项是否已完成。反复出现却未解决的事项是流程问题的征兆。
• 如果这是一次里程碑回顾，还要评估是否实现了里程碑目标，以及这对整体项目进度意味着什么。