Postmortem writer
Skill findscripter/everything-skills/02-engineering/postmortem-writer
类书式 AI Agent 技能大典 · 精选/中文化/互见成网的 500+ 开源技能,可作为 Claude Code 插件市场一键安装。A curated, cross-referenced encyclopedia of 500+ open-source agent skills.
npx -y skills add findscripter/everything-skills --skill postmortem-writerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
当事故(SEV1/SEV2、客户面中断>15min、数据丢失/安全、险些酿祸的 near-miss)结束后需要做事后复盘时使用;做产出无指责复盘文档(执行摘要、UTC 时间线、根因分析、行动项),用 5 Whys 把责任从"谁"导向"系统条件",并落成带 owner/截止日的可追踪工单;不适用于事故进行中的实时应急处置、纯监控告警配置或代码改动审查;触发词:复盘、事后复盘、postmortem、blameless、无指责、根因分析、RCA、5 Whys、事故时间线、incident review、action items。
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.0 KB, as published. Nobody here has run it
何时使用
事故结束后需要把"发生了什么、为什么、如何防止再发"沉淀成组织可学习的文档时使用。
触发条件(满足其一即应写复盘):
- SEV1 / SEV2 级事故;
- 客户面中断 > 15 分钟;
- 数据丢失或安全事件;
- 险些酿成严重后果的 near-miss、新出现的故障模式、需要非常规人工干预的事故。
不该用的边界:
- 事故进行中的实时止血/应急指挥 —— 本技能只做事后复盘,不做在线处置。
- 纯监控告警阈值/看板配置 —— 那是可观测性建设,不是复盘。
- 审查具体代码改动找 bug —— 那是代码审查,不在本技能范围(复盘只把"评审漏看"作为贡献因素记录,不逐行审代码)。
- 只想给个人定责追责 —— 与无指责原则冲突,直接拒绝。
步骤 / 指令
Day 0 事故发生
Day 1-2 趁记忆新鲜起草复盘文档(草稿)
Day 3-5 召开无指责复盘会
Day 5-7 定稿,逐条行动项建工单
Week 2+ 跟踪行动项关闭
季度 横向回看多起事故的模式
撰写流程:
-
立无指责基调。把每个问题从"谁造成的"改写成"是什么系统条件允许了它":
- "谁犯了错" → "系统为何允许这个错误发生"
- 目标是改进系统、共享教训、建立心理安全,而非惩罚个人。
-
填执行摘要:一段话讲清 何时 + 影响范围(受影响客户数、收入损失、工单数、是否有数据/安全影响)+ 根因一句话 + 如何恢复。
-
写时间线(统一用 UTC,表格化):部署完成、首次告警、ack、宣告级别、定位根因、决定回滚、回滚完成、完全恢复 —— 每行
时间 | 事件,精确到分钟。 -
根因分析,用 5 Whys 逐层下钻,每层都要给证据(指标截图、代码 diff、PR 号、评审记录、缺失的测试/文档):
- 服务为何失败 → 连接耗尽 → 为何耗尽 → 每请求新建连接 → 为何绕过连接池 → 开发者不熟代码约定 → 为何不熟 → 缺连接管理模式文档。
- 区分直接原因 / 贡献因素 / 系统性根因(通常根因是测试缺失、文档缺失、评审清单缺项这类系统问题,而非某个人)。
-
复盘三视角各写"做对了 / 没做好":
- 检测(Detection):告警是否及时、阈值是否合理、有无部署关联告警;
- 响应(Response):定位/决策/沟通;
- 影响(Impact):客户、业务、技术三层量化。
-
行动项必须可执行、有主、有期、入工单,并按"预防/检测/缓解"归类、按影响×成本排优先级(P0/P1/P2):
优先级 | 行动 | Owner | 截止日 | 工单号。无孤儿行动项。 -
开复盘会(60 分钟):开场重申无指责(5) → 走时间线(15) → 分析讨论(20) → 行动项(15) → 收尾确认 owner(5)。把指责一律导回系统层面,记录异议,给沉默者发言机会,控时打断跑题。
示例
5 Whys 片段(每问必带证据):
### Why #2: 为什么数据库连接被耗尽?
答:每个请求都新建连接,而非复用连接池。
证据:代码 diff 显示用了 DriverManager.getConnection(),而非池化 DataSource。
根因→改进映射表:
| 根因 | 改进 | 类型 |
| ----------- | ------------------ | ------ |
| 缺测试 | 补连接池行为集成测试 | 预防 |
| 缺文档 | 文档化连接管理模式 | 预防 |
| 评审有缺口 | 更新评审清单 | 检测 |
| 无金丝雀 | 实施金丝雀发布 | 缓解 |
行动项表:
| 优先级 | 行动 | Owner | 截止日 | 工单 |
| ----- | ------------------------- | ------ | --------- | ------- |
| P0 | 补连接池行为集成测试 | @alice | 2024-01-22 | ENG-1234 |
| P0 | 数据库连接告警阈值降到 70% | @bob | 2024-01-17 | OPS-567 |
| P1 | 文档化连接管理模式 | @alice | 2024-01-29 | DOC-89 |
轻量复盘(小事故,SEV3)模板:标题/日期/时长/级别 → 发生了什么 → 时间线 → 根因 → 修复(即时+长期带工单号)→ 教训一句话。
注意事项
- 永远不点名羞辱(name and shame);写成定责文档会直接扼杀学习。
- 立即开写,记忆衰减极快;要具体:精确时间、精确报错、附图作视觉证据。
- 不要做浅层分析(连追 5 个"为什么");不要零行动项(浪费会议);行动项要现实可达,否则永不关闭。
- 小事故别跳过——它们揭示模式;行动项必须有 owner,否则成孤儿;务必跟踪到关闭,事后核验完成。
- 别造无意义的忙活(busywork),行动项要真正有价值。
互见
- requires:无。
- related:无。
- combines_with:无。
本条采编自 wshobson/agents(MIT)。