Skip to content
Productivity
Skill

/pm-retro

Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘

From plugin
super-pm
6648 skills1 hook
Install
$ npx -y skills add konglong87/superPM --skill pm-retro --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/pm-retro

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘

SKILL.md

pm-retro.SKILL.md
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
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

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

---

Read more
Ships withsuper-pm

让每个产品经理都能轻轻松松的高效工作 ☕️ 📺 🚀

Get the whole plugin
Stats
65
Stars
8
Forks
Active
Maintenance
JavaScript
Language
MIT
License
11d ago
Last commit
5mo ago
Created

Repo: konglong87/superPM

Other skills on super-pm.

pm-brainstorm
Skill

pm-brainstorm

Use when: 需要创意方案、探索产品方向、发散思维、本质问题分析 用户说"我想做一个XX""帮我规划XX产品""帮我设计一下需求" 用户给出新产品方向,但尚未完成本轮 brainstorm 交互确认 新产品从0到1的第一步 Do NOT use when: 用户明确说"跳过 brainstorm /…

pm-clarify
Skill

pm-clarify

Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入

pm-competitor
Skill

pm-competitor

Use when: 需要持续监控竞品动态、建立竞品情报预警、定期输出竞品监控月报、追踪竞品版本/定价/功能/舆情/融资异动 Do NOT use when: 仅需一次性竞品调研(用 pm-market / pm-search --type=competitor);产品尚无明确竞品

pm-demand
Skill

pm-demand

Use when: 已完成 /pm-brainstorm 后,需要系统化收集需求、验证产品想法真伪、分析用户痛点 用户明确要求"需求调研""需求验证""验证痛点""分析用户痛点" 用户明确选择跳过 brainstorm,直接进入需求调研 Do NOT auto-select when:…

pm-interview
Skill

pm-interview

Use when: 需要设计用户访谈/用户调研方案、编写访谈提纲、规划样本与招募、制定访谈执行与分析方法 Do NOT use when: 仅做案头需求调研(用 pm-demand);已有明确结论只需验证单一假设且无需访谈