用途：pre-mortem 用于在计划获批后、首次提交前，对一项具体变更做失败预演。它假设变更已经上线并出了事故，要求像读事后复盘一样回答“为什么会失败”，从而在成本最低的阶段发现可预见的缺陷。资料指出，最昂贵的 bug 往往来自自信但不完整的实现，例如单位换算假设（分钟与秒）、同时到达的 webhook 竞态、迁移中途打断运行中的任务、范围蔓延移除他人依赖的 DialogTitle。
主要能力：输出固定三部分。第一，用一句话说明要发布什么；若无法一句话概括，说明变更过大，建议拆分。第二，列出 3 至 5 个失败模式，每个包含：场景（具体到参与者、时序、数据行，而非“负载下可能出问题”）、可能性（高/中/低，并基于本代码库或这些用户给出一行理由）、影响范围（谁和什么会坏，尽量量化行数、用户、金额、请求）、缓解措施（最小且具体的改动，如唯一索引、功能开关、dry-run、幂等键、回滚步骤、能捕获它的测试；若写成“小心点”则不算）。失败模式按可能性乘影响范围排序。第三，给出唯一建议，不模棱两可：按原样发布、先加固（列出要并入的缓解措施编号）、或拆分变更（提出更小、影响面更小的首片并说明延后内容）。
使用方式：在计划已明确、有具体 diff 或变更可反应时使用；若问题仍模糊，应先诊断，否则会为错误问题推理失败模式。触发词包括 pre-mortem、premortem 等。
适用场景：变更触及共享状态、涉及支付或 webhook、迁移、并发写入等。
限制：不适用于一行编辑、文案修改、导入调整、类型修复；不适用于行为可证明未变且有完整测试覆盖的纯重构；也不适用于以学习为目标的绿地原型。若不确定是否值得，可自问“我愿意为它凌晨三点被叫醒吗”。