retro

retro 概览

retro 的作用

retro skill 可以帮你组织一场结构化的 sprint retrospective，把团队反馈转化为清晰的行动项。它适合那些不满足于普通 prompt 的场景：retro skill 会引导讨论的展开方式，把零散评论归纳成主题，并推动结果落到负责人和截止日期上。

适合谁用

如果你是 Project Management、Agile 团队负责人、Scrum Master、产品团队成员，或者任何需要主持 sprint 回顾、梳理哪些做得好、哪些出了问题、下一步要改什么的人，都可以使用 retro。当你的目标是产出一个真正可执行的 retro 结果，而不只是保留一份讨论记录时，它尤其合适。

为什么它不一样

这个 retro skill 最核心的价值是“结构化”。它支持多种 retrospective 形式，必要时还能读取用户提供的团队数据，并且强调的是归纳和提炼，而不是聊天式展开。这让它比一次性的“帮我写个 retro” prompt 更适合反复使用的团队仪式。

如何使用 retro skill

安装 retro

先把 retro skill 按 repo 路径安装到你的 skills 目录里，然后在发起 retrospective 之前，让你的 agent 指向这段 skill 内容。一个典型的 retro 安装方式，是添加 phuryn/pm-skills，再选择 pm-execution/skills/retro。当你的任务是主持一次会议、总结反馈，或者把 sprint 笔记转成后续行动时，就用这个 skill。

准备更好的输入

retro 最擅长处理具体上下文，而不是模糊请求。高质量输入通常会包含：

• sprint 日期或 iteration 名称
• 团队名称和项目背景
• 原始反馈、会议记录或调查文本
• velocity、事故、carryover、阻塞项等指标
• 你希望采用的决策风格：Start/Stop/Continue、4Ls 或 Sailboat

一个弱 prompt 会写：“做个 retro。”
更强的 prompt 会写：“用 Start/Stop/Continue 为 Sprint 42 主持一次 retro。这里有 18 张 sticky notes、3 起事故和 2 个反复出现的阻塞项。请归纳主题，并在结尾给出 5 条优先级最高的行动项，每条都要有负责人和截止日期。”

先读这些文件

先看 SKILL.md，因为这里包含了主持规则和主流程。如果这个 skill 以后有扩展，再顺带检查 README.md、AGENTS.md 或目录级引用；但这个 repo 目前主要还是围绕主 skill 文件展开。也就是说，最快上手 retro 的方式不是跳着用，而是先读说明，再按你团队的格式和约束去调整。

放进实际工作流里使用

一个好的 retro 工作流通常是：

1. 收集团队原始输入
2. 选择一个和团队成熟度匹配的格式
3. 让 skill 聚类主题并提炼模式
4. 把主题转成有明确负责人的行动项
5. 在分享前先检查结果是否现实可执行

如果团队很忙，就让 skill 优先保证简洁和决策质量。如果这次 retro 比较敏感，就要求它避免指责性语言，尽量保持中性表述。

retro skill 常见问题

retro 只适用于 sprint retrospective 吗？

不是。retro skill 最适合 sprint retros，但也同样适用于发布后复盘、项目例会、事故反思，以及任何需要“结构化学习 + 后续行动”的团队复盘场景。

使用 retro 一定要有原始笔记吗？

不一定，但如果你提供团队笔记、调查评论或指标，结果会明显更好。没有输入时，retro 仍然可以生成一个主持大纲，但它能综合的证据更少，内容也更容易流于泛泛而谈。

retro 比普通 prompt 更好吗？

通常是的，尤其当你想要一致性时。普通 prompt 也能要求写 retrospective，但 retro skill 给你的是可复用的结构，以及从反馈到行动的更清晰路径。对于 Project Management 工作流来说，这一点最重要，因为这类工作尤其看重复性和责任落实。

什么时候不该用 retro？

如果你需要深入的根因分析、正式的事故报告，或者冲突调解脚本，就不要用 retro。它是为 retrospective 主持设计的，不适合用于法律、HR 或技术事故文档。

如何改进 retro skill

提供更锋利的原始材料

输入越好，retro 输出通常也越好。尽量提供具体例子，而不是印象式描述：

• “因为缺少 QA 权限，部署两次被延误”
• “有三个人提到验收标准不清楚”
• “在 sprint 中途改需求后，velocity 从 42 降到 31”

这种细节能帮助 skill 识别主题，而不是自己凭空猜。

明确你想要的输出形式

直接告诉 retro 什么叫成功。比如，你可以要求：

• 只要 3–5 个主题，不要完整逐字稿
• 适合 30 分钟 retro 的简短主持议程
• 带负责人、截止日期和预期影响的行动项
• 避免指责的中性语言

这样 retro 对 Project Management 会更有用，因为输出会更容易在真实会议里直接执行。

注意常见失败模式

最常见的问题，是输入太宽泛，最后只得到泛泛的建议。另一个问题是要求太多行动项，反而削弱后续落实。如果第一版结果感觉太虚，就在 prompt 里补上 sprint 背景、证据，以及你希望的行动项数量，再重新运行 retro，这样下一版就更容易落地。