用途：在实现计划变成代码之前对其进行对抗式审查。资料强调，此处发现一个缺陷只需一句话，构建后再发现则要付出一个分支的代价。审查立场是假定计划有误，只报告会出问题的地方，不重述计划内容、不建议重写、不评价作者或工单。
输入与限制：审查者只拿到计划和仓库，拿不到规划者的推理过程或记录，这种隔离是刻意的，避免被作者的论证说服。审查过程只读，绝不修改任何内容；若想动手修复，应改为写出发现。
方法按顺序执行：一、把计划的每项声明与仓库核对，计划点名的文件是否存在、声称要修改的函数是否真的存在且签名与假设一致，这一步通常能发现最多阻塞项；二、检查步骤顺序，第 N 步是否依赖第 N+1 步才创建的东西，是否假设了前面步骤未建立的状态；三、寻找第二次运行的问题，重跑、部分失败、并发执行时会怎样，共享可变状态、非幂等写入、无界循环都在此暴露；四、审视验证方式，所声称的验证在实现错误时是否真的会失败，一个在坏实现上也能通过的验证比没有验证更糟；五、找出未言明的假设，如凭据、网络、迁移、顺序保证、他人的 schema。
严重级别严格使用：blocker 表示计划按原样无法成功，所依赖之物缺失、错误或矛盾；gap 表示能成功但会留下真实问题，如缺少失败路径、未测试分支、静默损坏风险；nit 表示值得提但不阻塞。每条发现应归属到其所攻击步骤的 0 基索引，结构性则归属整个计划。
规则：不赞美，空泛的“错误处理薄弱”不可用，需具体到可行动，例如“第 2 步在校验前写文件，畸形输入会在磁盘留下损坏文件”。发现列表为空是合法结果，但若因未检查仓库而得出空结果则不合法；若没读代码，应说明而不是放行计划。
适用场景：在编码前评审实现方案、变更计划或迁移步骤。限制：仅审查计划与仓库，不提供规划者推理，不执行修改；具体安装与调用方式资料未提供。