premortem

事前检视

想象计划已经失败，然后解释原因。这种“前瞻性回溯”（Klein，《HBR》，2007 年）通过切换时态，比询问“可能会出什么问题？”多找出约 30% 的失败原因，而且原因也更具体。这项技能将这一机制转化为可重复执行的流程，最终产出修订后的计划，而不只是列出担忧。

工作流路由

触发条件	工作流
“做一次事前检视”、“运行事前检视”、“什么会让这件事失败”、高风险计划	Workflows/RunPremortem.md（完整流程：并行深度分析 Agent）
“快速事前检视”、小型／个人决策、快速直觉检查、背景信息不足	Workflows/QuickPremortem.md（单人单轮，不分派任务）
“更新事前检视技能”、添加／修复工作流	Workflows/Update.md

对于任何有实际风险的事项，默认使用 RunPremortem。只有在决策很小，或用户明确要求快速完成时，才改用 QuickPremortem。

核心机制（不要跳过这一设定）

整个技巧只有一个关键动作：**明确指出失败已经发生，并且已经确定，然后询问失败的原因。**其余一切都只是执行方式。如果某个步骤无法帮助用户进入“事情已经失败”的情境，就删掉它。完整的证据和引用见：References/Methodology.md。

快速参考

• 使用过去时设定情境。“现在是[时间范围]。[计划]已经失败。原因如下。”不要说“可能会失败”。
• **先独立生成原因。**在 RunPremortem 中，并行 Agent 不得查看彼此的输出——这是防止锚定的保障，也是不可或缺的一环。
• **要求原因与具体计划相关。**拒绝泛泛的风险（“时间表延误”）。每个原因都必须以实际计划细节为依据。
• **务必落实行动。**每项保留的风险都要对应一项缓解措施和一个早期预警信号。最后给出修订后的计划和启动前检查清单。没有后续行动的事前检视只是作秀。
• **Markdown 是权威记录。**对话记录（.md）是正式记录。HTML 只是通过 Tools/GenerateReport.ts --html 生成的可选可视化产物，绝不能作为主要输出。

不应运行事前检视的情况

• 没有具体计划的模糊构想——先收集计划，否则只会产生泛泛的风险。
• 已经不可逆地做出的决策——没有东西可修订，价值很低。
• 事实性问题或创意反馈——用错了工具。
• 抽象地批判某个想法／论点 → RedTeam。对当前议题进行多视角辩论 → Council。

工具

• Tools/GenerateReport.ts——将调查结果 JSON（架构见 References/Templates.md）转换为 Markdown 报告（默认）或独立 HTML 报告（--html）。使用 bun 运行。参见 Tools/GenerateReport.help.md。

注意事项

这是本技能信息密度最高的部分。每次运行后，如果遇到意外情况，就把它补充进来。

• “30%”这个统计数据说的是数量，而不是正确性。 1989 年 Mitchell/Russo/Pennington 的研究发现，前瞻性回顾能多生成约 30% 条理由——并非让识别_正确_理由的能力提升 30%。Klein 在 HBR 的转述（“正确识别”）夸大了这一结果。绝不要告诉用户，事前验尸能让他们“准确率提高 30%”。它让人生成的理由更_丰富_、更_具体_。错误引用这项研究会让整个分析显得草率。
• 锚定效应会毁掉整个流程。 如果按顺序生成原因（或让一个 Agent 看到另一个 Agent 的输出），第一个提到的失败就会框定之后的所有内容。应独立生成，再进行合并。这就是 RunPremortem 会并行分派 Agent，并明确禁止相互交流的原因。
• 泛泛的风险是最常见的质量问题。 “预算超支”“团队分心”“市场变化”适用于所有计划，对任何人都没有帮助。如果替换主题后某个原因仍然成立，那它就过于笼统——必须要求它引用计划中的实际细节。
• 在做出承诺之前运行。 钱已经花出去、团队也在情感上投入之后再做事前验尸，就变成了一种形式。它的价值在于_改变_计划，因此计划必须还有调整空间。
• 不要将它与 RedTeam 或 Council 混淆。 事前验尸 = 想象_具体计划_在未来如何失败，并以修订后的计划收尾。RedTeam = 对任意想法发起对抗性攻击。Council = 多个_当前_视角展开辩论。用词有重叠，机制却不同。
• 上下文不足 → 输出泛泛。 如果你无法用一句话说明（1）要对什么做事前验尸，（2）会影响谁，（3）成功意味着什么，就停下来，一次只问一个问题。不要凭空生成失败情形——那恰恰会产生这种方法旨在避免的泛泛风险。
• 失败 ≠ 悲观。 输出应是具体的因果故事和缓解措施，而不是一味渲染厄运。如果结果读起来像是“所有事情都有风险”，那这次运行就失败了。
• 可能性和严重程度是不同的维度。 _最可能_发生的失败和_最危险_的失败通常不是同一个。两者都要指出——这种区分往往就是关键洞见。

自定义

执行前，检查用户是否在 ~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/ 中设置了自定义项。如果存在 PREFERENCES.md，请加载并应用其中的设置 （例如偏好的默认时间范围、报告主题、失败分析 Agent 数量）。这些设置优先于默认值。 如果该目录不存在，则使用技能默认设置。不要将私人或身份相关内容放入技能正文——这些内容应放在 SKILLCUSTOMIZATIONS 中。

🚨 语音通知（调用时运行）

curl -s -X POST http://localhost:31337/notify \
  -H "Content-Type: application/json" \
  -d '{"message": "Running the WORKFLOWNAME workflow in the Premortem skill to ACTION"}' \
  > /dev/null 2>&1 &

然后输出：Running the **WorkflowName** workflow in the **Premortem** skill to ACTION...

示例

示例 1：对发布进行完整的事前验尸

User: "Premortem our paid-newsletter launch next month"
→ RunPremortem: gather context (what/who/success) → frame "it's 6 months out, the launch failed"
→ generate plan-specific causes → fan out 1 agent per cause (independent) → synthesize
   most-likely + most-dangerous + hidden assumption + revised plan + checklist
→ write transcript .md, optionally GenerateReport.ts --html → 3-sentence chat summary

示例 2：快速进行个人直觉检查

User: "quick premortem on accepting this contractor role"
→ QuickPremortem: single-pass, no agents → past-tense framing → 5-8 specific causes with
   likelihood/severity, hidden assumption, top mitigations → short markdown, no HTML

示例 3：与 RedTeam 区分

User: "poke holes in my argument that we should go remote-first"
→ This is attacking an ARGUMENT, not a plan-with-stakes → suggest RedTeam instead, or
   reframe: "if you want to premortem the remote-first *rollout plan*, I can do that."

执行日志

完成任何工作流后，追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Premortem","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl