pm-retro
@konglong87 · 收录于 1 周前
Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘
适合你,如果团队需要系统化地总结迭代经验并跟踪改进项
/ 下载安装
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code
~/.claude/skills/(项目级 .claude/skills/)Codex CLI
~/.codex/skills/Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add konglong87/superpm/pm-retro/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- konglong87/superpm/pm-retro/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify konglong87/superpm/pm-retro安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
36GitHub stars
~2.4K上下文体积 · 单文件
镜像托管
怎么用
技能原文 SKILL.md
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 交互规则
当流程要求与用户交互时:
- 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。
- 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。
- 一次只问一个问题。
- 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。
- 不得在用户回答前生成文档、写入 docs。
- 已有 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复盘流程。
注意事项
- 安全氛围:复盘不是追责,聚焦流程改进而非个人
- 数据说话:目标达成用数据支撑,避免主观判断
- 行动驱动:每个问题必须有对应的行动项
- 跟踪闭环:下次复盘时先回顾本次行动项完成情况
输出质量对比
✅ Good 示例:
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」 - 有验证来源:「数据来源:Google Analytics, 2025-12-01」 - 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例:
- 模糊结论:「数据表明留存率有所下降」 - 无来源:「根据经验,这个功能很重要」 - 没有行动建议:「留存是个问题」
常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯:
| 误区 | 正确做法 | |------|---------| | 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 | | 未运行检查就声称已完成 | 先验证,再陈述 | | 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 | | "这次应该没问题"的想法 | 每次都要重新验证 |
产出质量检查 / Verification Checklist
- [ ] 前置依赖已满足(输入文档/数据已收集)
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到
docs/目录 - [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill
⚠️ 任何一项未通过 → 补全后再标记完成。
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →
评论
登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…