postmortem

postmortem skill 概览

postmortem skill 能做什么

postmortem skill 是一套面向高管导师场景的工作流，用来把发布失败、目标落空、招聘失误、丢单或运营中断，转化为不归责的根因分析。它会引导 agent 精确定义事件、用严谨的 5-Whys 方法追问原因，并建立 change register，让最终产出不只是“经验教训”，而是一组可落地的系统性改进。

最适合领导者和 Quality Management 场景

这个 postmortem skill 尤其适合创始人、高管、运营负责人、产品负责人、工程经理，以及需要理解结果为何偏离计划的 Quality Management 团队。它适用于目标是预防和流程改进、而不是追责惩罚的场景。对于 Quality Management 下的 postmortem 用例，它最大的价值在于把失败转化为控制措施、责任人和可衡量的后续行动。

它与通用 prompt 的区别

通用的“分析哪里出了问题” prompt 往往会产出宽泛评论。这个 skill 更聚焦，也更偏运营落地：它会推动用户清晰界定事件，区分表象和原因，避免找替罪羊，并追问是什么条件让失败更容易发生。它的核心差异点是 change register，能帮助把洞察转化为责任归属、截止时间和系统层面的修复。

采用前需要注意的事项

该仓库路径下只有一个 SKILL.md，没有辅助脚本、参考资料或 metadata 文件。这让 postmortem install 很轻量，但也意味着 skill 的效果高度依赖你提供的上下文质量。适合在你能提供足够事实材料、支持一次严肃复盘时使用；如果事件仍处在政治上不安全、法律上敏感，或只建立在传闻之上，就不适合使用。

如何使用 postmortem skill

postmortem install 以及需要检查的文件

使用下面的命令从 GitHub skill source 安装：

npx skills add alirezarezvani/claude-skills --skill postmortem

源文件位于：

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

请先阅读 SKILL.md，因为完整的运行模型都在这个文件里。这里没有额外的 rules/、resources/、references/ 或 scripts/ 文件夹需要对齐，因此你的主要安装决策是：这个单文件工作流是否符合你的复盘方式。

实际使用时如何调用这个 skill

该 skill 围绕命令模式设计：

/em:postmortem <event>

一个较弱的调用方式是：

/em:postmortem Q3 release slipped

更好的调用方式会给 agent 足够信息，用来区分事实、假设和原因：

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

哪些输入能提升 postmortem 使用效果

为了获得更好的 postmortem 使用效果，请提供预期结果、实际结果、时间线、最早的预警信号、影响范围、关键决策、约束条件，以及当时已知的信息。同时包含量化证据和人的上下文：收入缺口、缺陷数量、招聘时间线、错过的里程碑、客户影响、决策负责人、审批瓶颈，以及相互竞争的优先级。

不要要求 skill “找出是谁造成的”。更好的做法是让它识别系统条件：责任归属不清、升级路径薄弱、规划假设不现实、质量关卡缺失、激励冲突，或风险暴露过晚。

产出有用结果的推荐工作流

先从一份基于事实的事件简报开始，然后要求生成第一版 postmortem 草稿。接着检查 5-Whys 链条是否过早停止，或是否跳到了一个方便但未必充分的解释。之后用证据继续迭代，例如：“Pressure-test the root cause against the timeline”，“Separate controllable causes from external shocks”，或 “Convert these lessons into a change register suitable for the next exec review.”

最佳的最终交付物通常包括：事件定义、影响摘要、促成因素、根因、非原因、当时看起来合理的决策、推荐的系统性改进、责任人、截止时间，以及验证指标。

postmortem skill 常见问题

postmortem 适合初学者吗？

适合，前提是用户能提供清晰的事件描述。该 skill 的结构降低了提前掌握正式复盘方法的门槛。初学者在调用前应准备一份简短时间线和结果差距说明；否则，模型可能会用看似合理但未经验证的假设来填补缺失上下文。

什么时候不应该使用这个 skill？

不要把它当作绩效评估、纪律处分工具、法律调查，或未经人工审核的公开事件声明来使用。如果领导层只想要一套好看的叙事，而不是可能令人不适的因果分析，它也不适合。若组织无法根据发现采取行动，postmortem 可能带来的不是改进，而是挫败感。

它和 incident review 有什么不同？

incident review 通常聚焦技术服务故障和运营恢复。这个 postmortem skill 范围更广：季度目标落空、发布失败、招聘失误、丢单、产品失败和领导层决策都可以纳入。它可以支持 Quality Management，但除非由合格审核人员进行适配，否则不能替代受监管的 CAPA、审计或合规文档。

这个 skill 依赖特定生态吗？

不依赖。该 skill 是纯 markdown，可以通过上面的命令安装到兼容的 skills 工作流中。由于没有脚本或外部资源，它可以在业务、产品、工程和运营场景之间迁移。代价是它不会自动摄取 dashboard、工单系统或 incident log；你需要自行总结或粘贴相关证据。

如何改进 postmortem skill

为 postmortem 提供更好的原始材料

提升 postmortem 结果最快的方法，是提供一份紧凑的证据包。包括：目标、实际结果、时间线、决策点、错过的信号、约束条件、利益相关方、影响，以及现有假设。对不确定的说法要明确标注。例如：“Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”

留意常见失败模式

最常见的失败是根因过浅，比如“沟通不畅”或“缺乏 owner”。应要求 agent 再往下追一层：是什么结构导致沟通失败？为什么责任归属不清？为什么规划流程允许这种模糊性存在？另一种失败模式是过度纠偏，列出太多 action items。应推动形成更少但有人负责、可观察、并且更可能防止复发的改进项。

把发现转化为 change register

一份高质量的 change register 应说明变更名称、它要解决的根因、owner、截止日期、成功指标和复盘节奏。用于 Quality Management 时，还应补充控制类型、验证方法和所需证据。这样，skill 的产出更容易在领导层复盘、季度规划、发布治理、招聘流程调整或持续改进项目中真正落地。

在第一版答案后继续迭代

第一版草稿出来后，继续提出有针对性的追问：“Which conclusions are evidence-backed versus inferred?”、“What would have prevented this without slowing the team unnecessarily?”、“What early warning metric should we add?” 或 “Rewrite the change register for executive accountability.” postmortem skill 最适合作为结构化调查伙伴来使用，而不是一次性报告生成器。