retro

retro skill 概览

retro 是用来做什么的

retro 是面向工程团队的项目复盘 skill。它会把提交历史、最近的时间线数据和过往经验整理成每周复盘，回答“我们交付了什么？”以及“上个 sprint 发生了什么变化？”。如果你需要的是一个能产出结构化团队回顾、而不是泛泛状态总结的 retro skill，它很适合。

适合谁安装

如果你想要一个可重复使用的 retro guide，用于每周工程回顾、sprint 结束复盘或 manager check-in，就应该安装 retro。它尤其适合 Project Management 工作流：你需要简洁的进展框架、按个人贡献的信号，以及跨周的趋势感知时，它会很有用。

它的不同之处

这个 skill 的核心是持久记忆，而不是一次性的 prompt。它会读取之前的复盘、最近的时间线事件和最近的 learnings，让每次运行都有连续性。这样一来，当你在意推进节奏、遗留问题，以及团队是否真的在持续改进时，它会更有价值。

如何使用 retro skill

安装并触发它

使用以下命令安装：
npx skills add garrytan/gstack --skill retro

然后在你需要每周复盘、交付总结或 sprint review 时调用它。这个 skill 里最自然的触发短语包括 “weekly retro”、“what did we ship” 和 “engineering retrospective”。

提供正确的输入

当你的 workspace 已经有提交活动，并且项目目录相对稳定时，retro install 的决策最容易做出。为了获得最佳效果，最好一开始就告诉 agent 时间窗口、团队，以及任何关注重点。例如：“为最近 7 天运行 retro，重点看 release blocker，并指出 ownership 的变化。”这比“总结一下项目”更好，因为前者明确告诉 skill 该如何组织输出。

先看这些文件

先阅读 SKILL.md，了解工作流和约束；如果你想看生成文档是怎么拼出来的，再查看 SKILL.md.tmpl。由于这个 repo 不包含支持性的 rules/、resources/ 或 scripts，这两个 skill 文件就是主要事实来源。

实用工作流建议

retro 最适合在一个有意义的工作周期结束后使用，而不是进行到一半时就用。如果你的 repo 提交很少，输出会比较薄，所以最好补充更明确的日期范围，或者要求和之前的复盘做对比。用于 Project Management 时，最好让它输出结果、风险和下一步动作，而不是写成一段叙述式回顾。

retro skill 常见问题

retro 只适合工程团队吗？

大体上是的。retro 是围绕代码变更、工作模式和交付信号设计的，所以它更适合工程场景，而不是通用的业务报表。如果你的项目几乎没有可用的 commit 轨迹，这个 skill 能依赖的信息就会少很多。

它比普通 prompt 好在哪里？

普通 prompt 可以一次性总结一周；retro 是一个可复用的 skill，内置了对历史复盘、时间线事件和 learnings 的上下文查询，因此它能产出更稳定的周度结果，并跟踪长期连续性。

retro 适合新手吗？

适合，只要你能说明复盘周期，以及你希望重点看什么。使用这个 skill 不需要了解内部实现，但输入越清晰，产出的 retro 往往越好。新手通常只要明确日期范围、团队和一到两个重点，就能得到更好的结果。

什么时候不该用 retro？

如果你想要的是深入的架构评审、bug 分诊报告，或者产品战略备忘录，就不要用 retro。它更适合团队进展回顾和带趋势感知的复盘，而不是围绕彼此无关目标的广泛分析。

如何改进 retro skill

聚焦复盘问题

最好的 retro usage，从一个清晰的问题开始：交付速度、ownership、质量，还是团队健康度。如果你一次把所有问题都抛进去，复盘就会变得很泛。先选出读完之后真正需要做决定的那个点。

提供更可靠的事实基础

给 skill 提供日期范围、repo 名称、发布里程碑，以及已知事件。比如：“上周的主要目标是 release readiness；重点突出 regression、handoff 和未完成工作。”这样可以帮助 skill 区分真实进展和只是看起来很忙的活动。

注意常见失败模式

最常见的失败模式，是过度优化 commit 数量，而不是关注有意义的进展。另一种是空泛的表扬，把风险盖住了。如果第一次输出太宽泛，就要求它拆得更细：已交付项、受阻项、团队贡献，以及下周风险。

用追问继续迭代

拿到第一版 retro 之后，用一个 follow-up prompt 继续细化：“重新运行 retro，更强调代码质量和未解决的 follow-up”，或者“把这份内容总结成面向 PM 受众的 5 个要点。”这通常比从头重来更有效，也能让 retro skill 更贴近你的真实工作流。