retro-meeting
Skill2 starsChanged 5 months agoMITView on GitHub
复盘会议模板——目标回顾、结果评估、原因分析、经验沉淀。专项技能SKILL,可独立使用。
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-reviewSkill
- design-reviewSkill
- main-workflowSkill
- okrSkill
- pr-faqSkill
- release-checklistSkill
- release-reviewSkill
- requirement-clarificationSkill
- requirement-reviewSkill
- retro-reviewSkill
- six-pagerSkill
- software-project-governanceSkill
- stage-architectureSkill
- stage-cicdSkill
- stage-developmentSkill
- stage-infraSkill
- stage-initiationSkill
- stage-maintenanceSkill
- stage-operationsSkill
- stage-releaseSkill
- stage-researchSkill
- stage-selectionSkill
- stage-testingSkill
- tech-reviewSkill
- test-reviewSkill
The file
Files
回顾会议模板
本 skill 提供回顾会议的标准模板和执行流程,用于维护阶段的复盘和经验回灌。可独立使用。
触发条件
- 一个迭代/里程碑/阶段完成,需要复盘
- 发生了事故或重大偏差,需要总结经验
- 维护阶段定期复盘(建议每个迭代结束时)
输入
| 输入项 | 说明 | 是否必须 |
| 回顾周期 | 本轮复盘覆盖的时间范围 | 必须 |
| 目标回顾 | 本周期开始时设定的目标和计划 | 必须 |
| 过程记录 | 证据、决策、风险、问题等过程数据 | 推荐 |
| 运营数据(如有) | 上线后的运行指标和反馈 | 推荐 |
执行步骤
第一步:目标回顾
| # | 活动 | 说明 |
| 1 | 列出本周期开始时的目标 | 从计划跟踪表中提取 |
| 2 | 逐项评估完成度 | 每个目标:已达成 / 部分达成 / 未达成 |
| 3 | 量化差距 | 部分达成和未达成的目标,用数据说明差距 |
第二步:结果评估
| # | 问题 | 记录要求 |
| 1 | 做得好的是什么? | 至少列出 3 条,每条说明为什么好 |
| 2 | 做得不好的是什么? | 至少列出 3 条,每条说明原因 |
| 3 | 有什么意外发现? | 计划外但有价值的发现或教训 |
参考华为自我批判:复盘必须包含"自己做得不好的 3 件事"和对应的改进计划——不批判自己意味着没有真正复盘。
参考 Google Blameless Postmortem:问题分析聚焦流程和系统,不追责个人。每次复盘产出可执行的改进项。
第三步:根因分析
对每个"做得不好"的事项,用 5-Why 分析法追溯根因:
| 层级 | 问题 | 示例 |
| 表象 | 发生了什么? | "功能延迟 3 天交付" |
| Why-1 | 为什么延迟? | "开发时发现设计文档不够详细" |
| Why-2 | 为什么不够详细? | "设计阶段时间紧张,跳过了核心模块的详细设计" |
| Why-3 | 为什么时间紧张? | "立项时低估了架构复杂度" |
| Why-4 | 为什么低估? | "调研阶段没有评估技术复杂度" |
| Why-5 | 为什么没评估? | "调研 checklist 没有技术复杂度评估维度" |
输出:每个"做得不好"的事项有至少 3 层 Why 追溯,最深层的根因作为改进项的输入。
第四步:经验沉淀
| # | 活动 | 说明 |
| 1 | 提炼可复用经验 | 从"做得好"和"做得不好"中提炼规律 |
| 2 | 分类经验 | 按维度分类:流程类 / 技术类 / 协作类 / 管理类 |
| 3 | 映射到规则/模板 | 经验能否回灌到工作流的规则或模板中 |
回灌规则:
- 经验能转化为规则检查项的 → 更新对应子工作流或 Gate 检查
- 经验能转化为模板字段的 → 更新对应模板
- 经验是项目特有的 → 记录到决策日志,不修改通用规则
第五步:改进计划
| # | 改进项 | 格式要求 |
| 1 | 列出改进项 | 每条有明确描述、不模糊 |
| 2 | 指定责任人 | 每条有且仅有 1 个责任人 |
| 3 | 设定截止日期 | 有明确的完成日期 |
| 4 | 纳入跟踪 | 改进项进入下一轮计划跟踪表 |
改进项数量控制:每轮复盘不超过 5 条改进项。超过 5 条说明颗粒度不够或期望过高——执行不来的改进计划比没有还糟。
参考字节 A/B 验证:改进项在下轮复盘中必须有执行结果验证,不能只列不做。
输出
| 产出物 | 格式 |
| 目标完成度评估 | 每个目标:已达成 / 部分达成 / 未达成 + 量化差距 |
| 做得好/做得不好列表 | 各至少 3 条,有原因分析 |
| 根因分析 | 每个问题至少 3 层 Why 追溯 |
| 可复用经验 | 按维度分类,标注是否可回灌到规则/模板 |
| 改进计划 | 不超过 5 条,每条有责任人和截止日期 |
质量标准
- 目标完成度逐项评估(不是笼统的"差不多")
- "做得不好"至少 3 条,且不回避真实问题
- 至少 1 个"做得不好"事项有根因分析(≥3 层 Why)
- 改进计划有责任人和截止日期
- 改进项已纳入跟踪表
独立使用说明
本 skill 可脱离完整生命周期独立使用。
如果项目已初始化 governance(.governance/ 存在)
- 先执行目标锚定检查(读 plan-tracker → 确认成功标准 → 偏离检查)
- 不需要先通过任何 Gate
- 可用于任何迭代的回顾(不限于正式维护阶段)
- 简单迭代可简化为"3 好 3 差 + 改进计划"的轻量模式
- 如果后续接入完整工作流,本 skill 的产出自动成为 G11(维护闭环)中"复盘结论"和"经验回灌"的证据
如果项目未初始化 governance(.governance/ 不存在)
- 跳过所有治理前置检查
- 直接执行本 skill 的核心流程(目标回顾 + 结果评估 + 根因分析 + 经验沉淀)
- 执行完毕后提醒用户:"当前项目未初始化 governance。如需自动证据记录、Gate 检查、风险跟踪,运行
/governance-init。"
子工作流映射
| 本 skill 步骤 | 对应 lifecycle 阶段 | 映射说明 |
| 目标回顾 | 维护与演进 | Gate G11 检查项"是否完成复盘"中的目标回顾部分 |
| 结果评估 | 维护与演进 | 复盘文档中"做得好/做得不好"记录 |
| 根因分析 | 维护与演进 | 复盘文档中的原因分析部分 |
| 经验沉淀 | 维护与演进 | Gate G11 检查项"经验是否回灌到规则和模板" |
| 改进计划 | 维护与演进 | Gate G11 检查项"下轮方向是否已明确",改进项进入下一轮跟踪表 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

