pm-retro

name	pm-retro
description	Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘
allowed-tools	["Agent","Read","Write","AskUserQuestion","Bash"]

Preamble

bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
mkdir -p docs/03-增长迭代/迭代复盘

echo "📝 迭代复盘工具已启动"

# 检查迭代计划
if [ -f "docs/03-增长迭代/迭代计划.md" ]; then
  echo "✅ 迭代计划 - 已找到"
else
  echo "⏳ 迭代计划 - 未找到"
fi

# 检查迭代完成情况
if [ -f "docs/03-增长迭代/数据报告与用户反馈.md" ]; then
  echo "✅ 数据报告 - 已找到"
else
  echo "⏳ 数据报告 - 未找到"
fi

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 复盘准备

使用 AskUserQuestion 询问：

🎯 迭代复盘准备

迭代信息：

• 迭代编号：第X次迭代
• 迭代周期：YYYY-MM-DD 至 YYYY-MM-DD
• 参与角色：产品、开发、设计、QA、运营（可多选）

迭代目标回顾：

本次迭代原定的核心目标是什么？

A) 目标1：{描述} B) 目标2：{描述} C) 目标3：{描述} D) 没有明确目标

记录到变量 ITERATION_INFO

---

步骤 2: 目标达成评估

📊 目标达成评估

目标1：{目标描述}

• 完成情况：{X}%
• 是否达成：✅/🟡/❌
• 说明：{完成/未完成的原因}

目标2：{目标描述}

• 完成情况：{X}%
• 是否达成：✅/🟡/❌
• 说明：{完成/未完成的原因}

整体完成率：{X}%

需求完成统计：

优先级	计划	完成	未完成	完成率
P0	X	X	X	X%
P1	X	X	X	X%
P2	X	X	X	X%

上述数据是否准确？

---

步骤 3: 收集团队反馈（KPT）

使用 AskUserQuestion 收集 KPT（Keep-Problem-Try）：

📝 团队反馈收集（KPT模型）

Keep - 做得好的地方（值得继续保持）

示例：

• 代码审查流程规范，Bug率降低
• 每日站会效率高
• 设计评审及时

请列举做得好的地方（每行一个，输入"完成"结束）：

收集到列表 KEEP_ITEMS

Problem - 需要改进的问题

示例：

• 需求变更频繁，影响开发节奏
• 测试时间不足，线上Bug较多
• 跨部门沟通不及时

请列举需要改进的问题（每行一个，输入"完成"结束）：

收集到列表 PROBLEM_ITEMS

Try - 尝试的行动方案

针对上述问题，尝试以下行动：

示例：

• 建立需求变更审批机制
• 预留20%测试缓冲时间
• 建立跨部门沟通群，每天同步进展

请列举尝试的行动（每行一个，输入"完成"结束）：

收集到列表 TRY_ITEMS

---

步骤 4: 根因分析

对 TOP 问题（团队反馈最多的）进行根因分析：

🔍 根因分析

TOP问题：{问题描述}

5 Whys 分析：

问题：{问题}
Why 1：{直接原因}
Why 2：{深层原因}
Why 3：{根本原因}
Why 4：{系统性原因}
Why 5：{根因结论}

根因：{根因结论}

解决方案：

1. {短期措施} - 立即执行
2. {长期措施} - 持续改进
3. {预防措施} - 防止复发

---

步骤 5: 制定改进措施

🎯 改进措施与行动项

行动项	负责人	截止时间	优先级
{行动项1}	{负责人}	{日期}	P0
{行动项2}	{负责人}	{日期}	P1
{行动项3}	{负责人}	{日期}	P1

下个迭代的改进目标：

• 将P0完成率从{X}%提升至{Y}%
• 解决TOP问题：{问题} 到 {标准}

---

步骤 6: 输出迭代复盘报告

使用 Write 工具创建 docs/03-增长迭代/迭代复盘/复盘-v{版本号}.md：

# 迭代复盘报告 v{版本号}

## 一、迭代概览

- **迭代编号**：第X次迭代
- **周期**：YYYY-MM-DD 至 YYYY-MM-DD
- **参与角色**：{角色列表}

## 二、目标达成

| 目标 | 完成率 | 状态 | 说明 |
|------|--------|------|------|
| {目标1} | X% | ✅/🟡/❌ | {说明} |
| {目标2} | X% | ✅/🟡/❌ | {说明} |
| **整体** | **X%** | | |

## 三、Keep - 做得好的

1. {内容}
2. {内容}
3. {内容}

## 四、Problem - 需要改进的

1. {内容}（根因：{根因}）
2. {内容}
3. {内容}

## 五、Try - 尝试的行动

| 行动项 | 负责人 | 截止时间 | 优先级 |
|--------|--------|---------|--------|
| {行动} | {负责人} | {日期} | P0 |
| {行动} | {负责人} | {日期} | P1 |

## 六、数据指标

| 指标 | 迭代前 | 迭代后 | 变化 |
|------|--------|--------|------|
| {指标} | X | Y | ±Z% |

## 七、下个迭代改进目标

1. {目标1}
2. {目标2}

---

**文档状态**: 迭代复盘完成
**生成时间**: {时间戳}
**生成工具**: super-pm

---

步骤 7: 完成提示

✅ 迭代复盘完成！

📄 已生成：docs/03-增长迭代/迭代复盘/复盘-v{版本号}.md

🎯 建议下一步：

A) 执行 /pm-iteration - 制定下个迭代计划 B) 执行 /pm-roadmap - 更新产品路线图 C) 如果改进措施涉及风险，执行 /pm-risk

---

兜底机制

场景: 无前置迭代计划

如果没有迭代计划文档，直接进入KPT复盘流程。

---

注意事项

1. 安全氛围：复盘不是追责，聚焦流程改进而非个人
2. 数据说话：目标达成用数据支撑，避免主观判断
3. 行动驱动：每个问题必须有对应的行动项
4. 跟踪闭环：下次复盘时先回顾本次行动项完成情况

---

输出质量对比

✅ Good 示例：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad 示例：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

---

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

误区	正确做法
使用"应该"、"大概"、"看起来"做结论	必须基于实际数据和验证
未运行检查就声称已完成	先验证，再陈述
因时间紧迫跳过关键步骤	没有例外，时间紧更要严格
"这次应该没问题"的想法	每次都要重新验证

---

产出质量检查 / Verification Checklist

• 前置依赖已满足（输入文档/数据已收集）
• 核心步骤已全部执行
• 输出文档已生成到 docs/ 目录
• 每个判断都有数据/证据支撑
• 已推荐 2-3 个后续 skill

⚠️ 任何一项未通过 → 补全后再标记完成。

---