mcpField
A
agile-retro

agile-retro

github.com/djalmajr生产力4126 次安装5 周前更新
代码仓库

关于 agile-retro

面向团队的复盘技能，将迭代或交付回顾转化为少量有负责人、可验证的改进措施。它区分事实与感受，并将结论衔接到下一周期。

主要功能

  1. 01区分事实与感受
  2. 02分析成效及问题根因
  3. 03制定 2–3 项责任明确的行动
  4. 04设定期限与验证方式
  5. 05将行动衔接到下一周期

适用场景

  1. 01回顾已完成的迭代
  2. 02重大交付后进行反思
  3. 03为迭代规划准备改进措施

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/djalmajr/skills --skill agile-retro

安装后在 Claude Code 中输入/agile-retro确认已加载。

附带文件templates/retro.md

详细介绍

复盘

使用此技能进行复盘，将反思转化为具体的改进措施。

通过斜杠命令收到的初始上下文：$ARGUMENTS

如果 $ARGUMENTS 已填写，请将其用作参考（例如，周期、冲刺、计划、交付）。 如果为空，请询问要分析哪个周期或交付。

语言

使用用户的语言撰写文档。使用正确的语法以及所需的变音符号或特定文字。如果无法确定用户使用的语言，请先询问。模板为英文——请翻译标题和内容，使其符合目标语言。

项目根目录

此技能会将文档写入相对于项目根目录（即工作所在的仓库）的路径，而不是 Agent 当前的工作目录。

  • 如果在项目内调用，请使用此技能中显示的相对路径。
  • 如果从其他目录调用（例如，兄弟仓库，或项目位于其他位置），请在每个文档路径前加上 <project-root>/。
  • 如果项目根目录不明确，请使用 harness 的提问工具向用户确认后再写入。

提问

遵循项目范围内 CLAUDE.md / AGENTS.md 中的约定（“Skill Prompting Conventions”）。对于以下决策点，请使用 harness 的结构化提问工具——AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。仅当路径／名称／值无法枚举时，才使用自由文本提问。

决策点结构化提问的原因建议选项
复盘范围影响分析深度和模板单个故事 · 单个冲刺 · 单个史诗
引导方式决定提问内容开始－停止－继续 · 悲伤－愤怒－高兴 · 4Ls · 自由形式

自由文本提问（不使用结构化工具）：

  • 参与者笔记
  • 改进措施

无暂停模式：如果用户明确禁用了技能执行期间的澄清，请将每个结构化提问转换为“开放问题”（或同类章节）中的条目，并继续执行，不要中断。

目标

  • 区分事实与观点
  • 找出哪些做得好、哪些不理想，以及原因
  • 生成少量清晰的措施，并注明负责人和截止日期
  • 推动流程改进，而不只是留存历史记录
  • 反思交付结果（计划内容与实际情况的对比）

适用场景

  • 冲刺或交付周期已结束
  • 团队需要反思哪些方面做得好、哪些方面需要改变
  • 开始下一次冲刺之前——复盘结果应为冲刺规划提供依据
  • 重要交付完成后（通过 /agile-status 的闭环模式）
  • 单次交付复盘（涵盖旧版 /post-impl 反思的内容）
  • 单次冲刺复盘（标准复盘）

不适用场景

  • 冲刺期间的状态跟踪——改用 /agile-status（检查点模式）
  • 规划下一次冲刺——改用 /agile-sprint（但复盘结果应为其提供依据）
  • 通过验证来关闭交付——先使用 /agile-status（闭环模式），然后再复盘
  • 需要指标／数据——先运行 /agile-review（其指标章节），然后再复盘

流程

1. 收集输入

查阅：

  • 该周期的状态关闭报告
  • 状态检查点和汇总报告
  • 冲刺评审（如有）
  • 冲刺指标（如有）
  • 用户或利益相关者的反馈
2. 区分事实与观点
  • **事实：**实际发生的情况（交付、阻塞、偏差、指标）
  • **感受：**团队／个人对流程的感受
3. 分析
  • **哪些方面做得好：**带来成效的实践、工具、决策
  • **哪些方面不理想：**导致摩擦、延迟或返工的问题
  • **原因：**找到根本原因，而不只是表面症状
4. 反思交付结果

在交付关闭后进行复盘时：

  • 计划交付的内容与实际交付的内容
  • 哪些决策是正确的，哪些应该调整
  • 下次会如何改进
  • 引入的技术债务或风险
5. 定义行动
  • 每次回顾限定 2-3 项行动（重质不重量）
  • 每项行动必须包含：
    • 具体描述
    • 负责人
    • 截止日期
    • 验证改进是否落实的方法
6. 与下一周期衔接
  • 在下一个冲刺/交付中，如何观察这些行动的效果？
  • 是否有行动需要成为待办事项？

保存位置

  • 如果是针对某项计划的回顾，保存到 planning/<initiative>/retro.md
  • 如果是针对冲刺/周期的回顾，保存到 planning/retros/retro-YYYY-MM-DD.md

链接后续流程

  • 如果行动产生了新任务：建议使用 /agile-story 或 /agile-epic
  • 如果行动改变了流程，或暴露出技能/模板的缺失：记录在回顾中，供人工审查
  • 如果周期重新开始：建议使用 /agile-sprint

参考模板

使用此技能中的 templates/retro.md 作为基础。

规则

  • 回顾不是发泄情绪，也不是会议纪要，而是改进工具。
  • 行动必须具体且可执行，不能含糊其辞（“改善沟通”不是行动）。
  • 每项行动都必须有负责人。没有负责人的行动不会落实。
  • 每次回顾限定 2-3 项行动。行动太多 = 一项也无法落实。
  • 如果同一项行动连续出现在多次回顾中，说明问题更深层——应讨论根本原因。

与工作流程的关系

flowchart LR
    A["/agile-status<br>(closure)"] --> B["/agile-retro"]
    B --> C[improvement actions]
    C --> D["/agile-sprint"]

此技能用于闭合反馈循环。要完成交付，请先使用 /agile-status（关闭模式）。要查看演示和冲刺数据，请先使用 /agile-review。下一个周期从 /agile-sprint 开始。

评论

支持 Markdown