用途：pre-mortem 是面向尚未开工项目的“事后复盘”，通过想象项目已上线并公开惨败，逆向找出最可能的失败原因，用于在构建前识别真实风险。
五步流程：第一步，设想 6 个月后项目已发布且明显失败；第二步，写一句具体、可感的失败新闻标题（如某日因按原始请求体哈希去重导致重试时 3 万客户被重复扣款）；第三步，列出 10 至 15 条这一定失败发生的具体原因，需引用真实组件/文件、真实失败模式（竞态、schema 不匹配、凭证过期）和真实人为因素，拒绝“测试不足”式空话；第四步，按可能性 1-5 与严重度 1-5 评分，以两者乘积排序，取前三为最高优先缓解项；第四步补充，将风险分为 Tigers（你认为可能拖垮项目的真实问题，按 Launch-Blocking、Fast-Follow、Track 分紧急度）、Paper Tigers（他人提出但你不认为真实、只需记录以对齐干系人）和 Elephants（团队知道却不公开讨论的不适问题）；第五步，为前三成因各写一条具体护栏（能捕获该问题的测试、熔断/功能开关、runbook 条目、带特定 SLO 的监控告警）；若无法在时间/预算内缓解，则向用户升级说明“该计划接受 X 风险且无缓解”。
使用方式：可把模板加入 PLAN-*.md，模板含失败标题、成因评分表、Tigers 表（含分类、缓解、负责人、截止）、Paper Tigers、Elephants 与已接受风险。资料还给出按项目类型的常见失败参照（如 fintech 的幂等键碰撞重复扣款、healthcare 的 PHI 日志泄露、web3 的预言机过期与闪电贷、mlops 的训练/服务偏移、ai-system 的提示注入外泄数据等）。
限制与注意：避免模糊风险、宇宙级风险（如“AWS 会挂”）、为显周全而列已缓解项、跳过失败标题等反模式。项目极小、已有完整测试覆盖的纯重构、或一行复现的 bug 修复，可跳过 pre-mortem。本技能未提供具体安装命令或收费信息。