用途
Pre-Mortem 用于在计划、设计和实现真正落地之前，系统性地找出可能让项目失败的风险。它基于 Gary Klein 的“事前验尸”（Pre-Mortem）技术，并由 Shreyas Doshi（Stripe）推广。核心提问是：“设想三个月后这个项目惨败了，为什么会失败？”通过这种反向推演，把隐藏的失败模式提前暴露出来。
主要能力
该技能把风险划分为四类：
- Tiger（[TIGER]）：明确的威胁，如果不处理就会造成伤害。
- Paper Tiger（[PAPER]）：看起来有威胁，但实际大概率没问题。
- Elephant（[ELEPHANT]）：没人愿意谈的隐忧。
- False Alarm：经核实后并非风险。
它强调“先验证再标记”。不能仅凭模式匹配就标记风险，每个潜在 Tiger 都必须经过验证。常见的误报来源包括：看到硬编码路径却没检查是否有 if exists() 回退；发现缺少功能 X 却没问“X 是否在范围内”；在未阅读第 N 行上下 20 行的情况下就标记该行代码；未追踪代码就假设错误情况未被处理。
验证清单要求对每个潜在发现确认：是否读取了发现点上下 20 行上下文、是否存在 try/except 或 if exists() 或 else 分支、是否在本次代码范围内、是否位于 main、tests/ 或仅开发代码中。任何一项为“否”或“未知”，都不得标记为 Tiger。
每个 Tiger 必须附带证据，包括风险描述、位置（file.py:42）、严重程度（high/medium），以及“已检查但未找到的缓解措施”（mitigation_checked）。如果无法用具体证据填写 mitigation_checked，就不算已验证的 Tiger。
使用方式
命令形式：
- /premortem：自动检测上下文并选择深度
- /premortem quick：强制快速分析（计划、PR）
- /premortem deep：强制深度分析（实现前）
- /premortem <file>：分析特定计划或代码
工作流程：
- 检测上下文与深度。在计划创建阶段或 PR 审查时使用 quick（局部范围）；在实现前使用 deep（全局范围）；否则询问用户选择深度。
- 运行对应清单。Quick 清单关注：最可能出错的单点、可能失败的外部依赖、是否可回滚、测试未覆盖的边界情况、可能导致返工的需求不清。Deep 清单按技术风险（可扩展性、依赖、数据、延迟、安全、错误处理）、集成风险（破坏性变更、迁移路径、回滚策略、功能开关）、流程风险（需求清晰度、干系人输入、技术债、维护负担）、测试风险（覆盖缺口、集成测试、负载测试、手工测试）逐项检查。
- 通过 AskUserQuestion 呈现风险，要求用户决策。选项包括：接受风险并继续、向计划添加缓解措施（推荐）、研究缓解方案、讨论具体风险。
- 处理用户响应。若接受风险则记录并继续；若添加缓解措施则更新计划并重新运行 quick premortem 验证；若研究缓解方案则对每个 HIGH 严重度 Tiger 并行启动内部（scout）与外部（oracle）研究，综合后给出 2-4 个缓解选项；若讨论风险则就具体风险展开对话。
- 若添加了缓解措施，则把“风险缓解（Pre-Mortem）”章节追加到计划中，包含已处理的 Tiger、已接受的风险以及本次运行的时间、模式、Tiger 与 Elephant 数量。
输出采用两遍流程：第一遍收集潜在风险（potential_risks），第二遍验证后输出 tigers、elephants、paper_tigers、false_alarms，deep 模式还包含 checklist_gaps。
适用场景
- 在 create_plan / plan-agent 中，计划结构获批后、退出计划模式前运行 quick premortem；若发现 HIGH 风险则阻塞直到处理。
- 计划获批后、实现前，对完整计划运行 deep premortem；阻塞直到所有 HIGH Tiger 被处理。
- 在 PR 审查工作流中，对 diff 范围运行 quick premortem，并告知发现的风险。
严重程度阈值：HIGH 为阻塞，必须处理或明确接受；MEDIUM 不阻塞，告知用户并建议处理；LOW 不阻塞，仅记录知悉。
限制
资料未提供该技能的安装方式、依赖环境、支持的平台或收费信息。其效果取决于是否严格执行验证清单；若跳过验证，可能产生误报。