premortem

Premortem

Premortem 是一种可选的计划挑战策略。它会要求一个全新的上下文，在实现前找出已明确的 bead 或调用方意图可能失败的具体方式。 它不是必需 RPI 流程的一部分，也不代表已获准就绪。 计划的通用挑战方法负责可选的 交流、独立性和停止规则；Premortem 负责以下三项检查。相邻技能：Review提供通用建议，Validate负责验收已完成的变更，而多个 独立视角由 Council提供。

按以下顺序运行检查，并按相同顺序报告发现：第一项或第二项检查中的发现，优先级高于第三项检查提出的任何单一技术风险。

第一项检查：谁来验证，验证者是否独立？

先检查计划的证据形式，再考虑任何技术风险：对于每个工作单元，谁来验证它？验证上下文是否不同于编写它的上下文？作者没有编写的 CI 和现有确定性检查，算作独立验证者；对于普通工作单元，这些就足够了 （Validate）。有两种情况属于发现：一个工作单元只由其作者编写的检查来评估，例如某个收尾步骤写着“实现者运行自己的测试并关闭”；以及 Validate 将某个工作单元列为成本高昂，却没有安排独立于作者的新鲜审查。每种情况报告一次，并列出涉及的工作单元。自我评定为通过是典型的虚假完成，因此优先级最高，因为它会悄无声息地把其他所有失败变成已交付的失败。

第二项检查：哪些步骤是单向门？

逐一审视各步骤，并标记为双向（计划可以撤回）或单向（无法撤回）。对于每个单向步骤，明确说明确切的撤销成本、不可逆点，以及越过该点时由谁掌握操作权：调用方，还是在批处理中做决定的 Agent。双向失败的代价是重试；单向失败的代价是事物本身。留意前十九个步骤都可逆，接着却有一个不可逆步骤的情况：前十九步养成的条件反射会决定人们如何处理第二十步。

这种失败模式称为声称可逆，却未追踪验证：回滚部分写着“完全可逆”，但其中某一步却会撤销凭据、强制推送或发布。超出调用方现有授权范围的重大不可逆操作属于一项发现；Plan 的决策者负责撤销成本和授权，先前的授权仍然有效，因此不要在越过不可逆点时要求重复批准，也不要把每个不确定的细节都视为不可逆。停止条件：每个步骤都有标记，且每个单向标记都注明了撤销成本。

第三项检查：构造失败情形

从计划默认成立的前提出发，找出候选失败情形，而不是罗列通用风险。常见前提包括：工具或服务按计划所述运行；在工作量相关的情况下，工作量远高于或低于预期时仍能正常进行；各步骤按规定的顺序和时间完成；验收标准、边界行为、范围和依赖项均已完备。首先关注其他步骤所依赖的决策，以及任何决定性前提是推断而非引用依据的单向步骤。指出能够证明每项前提不成立的事实；如果现在就能查证，就直接查证，不要把该前提作为风险报告。

对每个候选失败情形，都要尝试具体地推翻计划：写出会导致计划失败的输入、命令序列或仓库状态，并运行或引用检查，以说明计划能否经受该考验。如果无法执行，构造的输入或序列加上引用事实（文件和行号、文档所述行为、观察到的输出）即算作尝试。无法构造的失败情形应报告为“已尝试但受阻”，并说明障碍；这本身就是支持计划的证据。要指出的失败模式是纸上谈兵式的悲观：没有构造依据的臆想风险，看似尽职，却什么也没检验。既没有构造依据、也没有阻碍事实的发现应直接删除，而不是弱化表述。

工作流

1. 找到现有的意图来源，并检查其中的验收标准、非目标、证据要求和声明的写入范围。
2. 由未编写计划的上下文进行判断，并遵循适用于身份、模型选择、授权和边界的共享挑战方法。调用方编写的计划可在此处接受判断，并将调用方视为作者。如果当前上下文编写了计划，且无法启动新的上下文，仍须运行检查，说明独立性环节缺失，并以内联方式返回发现；绝不可称其为独立判断。
3. 根据引用的仓库事实运行三项检查。对于容易锚定于现有设计的集成或扩展计划，请加入 推导差异挑战。
4. 返回一组完整、范围明确的具体发现，注明已检查和未检查的范围，然后停止：由调用方决定是修改计划还是调用 RPI。

判断是否有效

输出中应能观察到：

• 每个单元都注明验证者；每种自验证形式各作为一项发现，并列出其单元；
• 每个步骤都已标记；每个单向标记都注明撤销成本和不可逆点；
• 每项发现都引用了推翻尝试或导致受阻的事实；
• 发现集合有明确边界：如果评审指出了每个步骤，就等于什么也没报告。

边界

只提出建议性发现，不对任何版本、就绪状态、准入或权限作出裁决。不要实施、验证候选方案、重试、修复、排期、认领、修改验收标准、操作 Git、结束工作、发布或交付。Council 或 Dueling Idea Genies 可由调用方提供作为证据，但 Premortem 不需要它们，也不能将共识转化为批准。任何计划编辑都会产生一个新对象，供调用方之后发起的 Premortem 评审。

输出

默认以内联方式返回发现：

Findings (in check order, then most consequential first within each check)
1. <step> - <how it fails> - <construction, or the fact that blocked it> - <consequence>
Verifiers: <unit>: <who verifies>
Steps: <step>: two-way | one-way - <undo cost> - <point of no return> - <who holds the handle>
Checked: <what was examined>. Not checked: <what was not>.
Independence: <judge context, distinct from author> or "missing: <reason>"

<skill-dir> 是包含此 SKILL.md 的目录。Claude Code 将其显示为“此技能的基础目录”；Codex 会列出此技能的 SKILL.md 路径；在 AgentOps 源代码检出中，该目录为 skills/premortem。运行命令前，请将 <skill-dir> 替换为该目录的绝对路径。工作目录保持为用户的仓库。如果宿主未显示此技能的安装位置，请使用你读取的 SKILL.md 所在目录。如果无法确定，请勿猜测路径，也不要运行当前仓库中同名的脚本；请说明随附脚本不可用，并根据其 架构 手动检查评审字段。

当调用方要求提供可留存的评审时，请返回 premortem-plan-review.v1，并使用 bash "<skill-dir>/scripts/validate-output.sh" <review.json> 对其进行检查。其 intent_digest 是所提供的确切意图文本的 SHA-256（例如 shasum -a 256 plan.md）；author_context_id 用于标明计划的撰写者（调用方或该会话的 ID），judge_context_id 用于标明当前上下文。该格式没有用于验证者或步骤标记的字段：请将它们记录在 checked 中，并将每条发现的构造事实或阻塞事实写入其 evidence。验证器会拒绝相同的作者和评审者 ID，但只检查字符串是否不同，不会检查是否有独立评审者参与，因此没有独立评审者的评审应以内联方式提供。发现集为空仅表示此可选挑战未发现具体缺陷；它绝不是生命周期门槛。