pm-selfcheck
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘
$ npx -y skills add konglong87/superPM --skill pm-retro --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/pm-retroContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘
name: pm-retro description: | Use when: 迭代结束后需要复盘总结经验教训、改进团队流程、记录改进行动项 Do NOT use when: 迭代尚未结束、团队不需要正式复盘 allowed-tools: - Agent - Read - Write - AskUserQuestion - Bash
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---
当流程要求与用户交互时:
1. 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。 2. 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。 3. 一次只问一个问题。 4. 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。 5. 不得在用户回答前生成文档、写入 docs。 6. 已有 docs 文件不能替代本轮用户回答。
---
使用 AskUserQuestion 询问:
> 🎯 迭代复盘准备 > > **迭代信息**: > > - **迭代编号**:第X次迭代 > - **迭代周期**:YYYY-MM-DD 至 YYYY-MM-DD > - **参与角色**:产品、开发、设计、QA、运营(可多选) > > **迭代目标回顾**: > > 本次迭代原定的核心目标是什么? > > A) 目标1:{描述} > B) 目标2:{描述} > C) 目标3:{描述} > D) 没有明确目标
记录到变量 `ITERATION_INFO`
---
> 📊 目标达成评估 > > **目标1:{目标描述}** > - 完成情况:{X}% > - 是否达成:✅/🟡/❌ > - 说明:{完成/未完成的原因} > > **目标2:{目标描述}** > - 完成情况:{X}% > - 是否达成:✅/🟡/❌ > - 说明:{完成/未完成的原因} > > **整体完成率**:{X}% > > **需求完成统计**: > | 优先级 | 计划 | 完成 | 未完成 | 完成率 | > |--------|------|------|--------|--------| > | P0 | X | X | X | X% | > | P1 | X | X | X | X% | > | P2 | X | X | X | X% | > > 上述数据是否准确?
---
使用 AskUserQuestion 收集 KPT(Keep-Problem-Try):
> 📝 团队反馈收集(KPT模型) > > **Keep - 做得好的地方(值得继续保持)** > > 示例: > - 代码审查流程规范,Bug率降低 > - 每日站会效率高 > - 设计评审及时 > > 请列举做得好的地方(每行一个,输入"完成"结束):
收集到列表 `KEEP_ITEMS`
> **Problem - 需要改进的问题** > > 示例: > - 需求变更频繁,影响开发节奏 > - 测试时间不足,线上Bug较多 > - 跨部门沟通不及时 > > 请列举需要改进的问题(每行一个,输入"完成"结束):
收集到列表 `PROBLEM_ITEMS`
> **Try - 尝试的行动方案** > > 针对上述问题,尝试以下行动: > > 示例: > - 建立需求变更审批机制 > - 预留20%测试缓冲时间 > - 建立跨部门沟通群,每天同步进展 > > 请列举尝试的行动(每行一个,输入"完成"结束):
收集到列表 `TRY_ITEMS`
---
对 TOP 问题(团队反馈最多的)进行根因分析:
> 🔍 根因分析 > > **TOP问题**:{问题描述} > > **5 Whys 分析**: > ``` > 问题:{问题} > Why 1:{直接原因} > Why 2:{深层原因} > Why 3:{根本原因} > Why 4:{系统性原因} > Why 5:{根因结论} > ``` > > **根因**:{根因结论} > > **解决方案**: > 1. {短期措施} - 立即执行 > 2. {长期措施} - 持续改进 > 3. {预防措施} - 防止复发
---
> 🎯 改进措施与行动项 > > | 行动项 | 负责人 | 截止时间 | 优先级 | > |--------|--------|---------|--------| > | {行动项1} | {负责人} | {日期} | P0 | > | {行动项2} | {负责人} | {日期} | P1 | > | {行动项3} | {负责人} | {日期} | P1 | > > **下个迭代的改进目标**: > - 将P0完成率从{X}%提升至{Y}% > - 解决TOP问题:{问题} 到 {标准}
---
使用 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---
> ✅ 迭代复盘完成! > > 📄 已生成:`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 示例**:
- 模糊结论:「数据表明留存率有所下降」 - 无来源:「根据经验,这个功能很重要」 - 没有行动建议:「留存是个问题」
---
出现以下情况立即停止并回溯:
| 误区 | 正确做法 | |------|---------| | 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 | | 未运行检查就声称已完成 | 先验证,再陈述 | | 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 | | "这次应该没问题"的想法 | 每次都要重新验证 |
---
> ⚠️ 任何一项未通过 → 补全后再标记完成。
---
Repo: konglong87/superPM
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 需要创意方案、探索产品方向、发散思维、本质问题分析 用户说"我想做一个XX""帮我规划XX产品""帮我设计一下需求" 用户给出新产品方向,但尚未完成本轮 brainstorm 交互确认 新产品从0到1的第一步 Do NOT use when: 用户明确说"跳过 brainstorm /…
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要持续监控竞品动态、建立竞品情报预警、定期输出竞品监控月报、追踪竞品版本/定价/功能/舆情/融资异动 Do NOT use when: 仅需一次性竞品调研(用 pm-market / pm-search --type=competitor);产品尚无明确竞品
Use when: 已完成 /pm-brainstorm 后,需要系统化收集需求、验证产品想法真伪、分析用户痛点 用户明确要求"需求调研""需求验证""验证痛点""分析用户痛点" 用户明确选择跳过 brainstorm,直接进入需求调研 Do NOT auto-select when:…
Use when: 需要设计用户访谈/用户调研方案、编写访谈提纲、规划样本与招募、制定访谈执行与分析方法 Do NOT use when: 仅做案头需求调研(用 pm-demand);已有明确结论只需验证单一假设且无需访谈