在非平凡决策落地前用全新上下文的对抗性审查来证伪…

当你要提交非平凡代码、做架构决策、断言非显而易见的事实，或在陌生代码中工作时，用独立上下文的审查者对抗性地找出问题，而不是自我验证。

适用场景

解决思路

1. 判断决策是否非平凡：满足以下任一即算——引入或修改分支逻辑、跨越模块或服务边界、断言类型系统或编译器无法验证的属性（线程安全、幂等性、顺序、不变量）、正确性依赖未来读者看不到的上下文、影响范围不可逆（生产部署、数据迁移、公共 API 变更）。
2. 按检查清单执行怀疑循环：Step 1 CLAIM（写下主张与重要性）→ Step 2 EXTRACT（隔离工件与契约）→ Step 3 DOUBT（调用全新上下文审查者并给出对抗性提示）→ Step 4 RECONCILE（逐条对照工件文本分类）→ Step 5 STOP（满足停止条件）。
3. Step 1 CLAIM：用两三行写下决策，格式为 CLAIM: "<主张>" 和 WHY THIS MATTERS: "<为何重要>"；若无法写得如此紧凑，说明你只有感觉而非决策，先把它显式化。
4. Step 2 EXTRACT：只提取最小可审查单元——代码取 diff 或函数而非整个文件；决策取 3–5 句提案加约束；断言取主张加支撑证据（与 Step 1 的 CLAIM 块分开）。剥离你的推理过程，不要交出结论，否则只会得到对结论的确认；单元要小到审查者一次阅读即可把握，500 行的 PR 先分解。
5. Step 3 DOUBT：使用对抗性提示词，明确要求「找出工件的问题，假设作者过度自信」，检查未言明的假设、未处理的边界情况、隐藏耦合或共享状态、契约可能被违反的方式、可能破坏的既有约定、意外输入下的失败模式；要求不要验证、不要总结，找不到问题就明确说明。
6. Step 3 只传 ARTIFACT + CONTRACT，绝不传 CLAIM，让审查者独立判断工件是否满足契约。
7. Step 3 在 Claude Code 中可使用 agents/ 下基于角色的审查者（默认隔离上下文）；但对抗性提示词优先于该 persona 的默认输出形态，需将提示词原样粘贴以覆盖默认；若无法干净覆盖，退回使用带对抗性提示词的通用 subagent。
8. Step 3 跨模型升级（交互式会话）：单模型审查完成后、RECONCILE 之前，必须询问用户是否要跨模型第二意见，选项为 Gemini CLI、Codex CLI、手动外部审查或跳过；无论工件风险高低，每个交互式怀疑循环都必须提出这个问题，由用户决定成本是否值得。
9. Step 3 若用户选择 CLI：先用 which 检查工具在 PATH 中，再运行 --version 等测试二进制可用，然后与用户确认确切调用方式（含必需 flags、认证、环境变量如 API key），只传 ARTIFACT + CONTRACT + 对抗性提示词，注意 shell 转义，优先用 stdin 或 heredoc 而非内联 -p "…"，输出进入 Step 4。
10. Step 3 绝不把工件插值进 shell 引号参数：代码、markdown 和审查提示常含反引号、$(...) 和引号字符，会截断提示或执行内嵌 shell；应把完整提示写入文件再通过 stdin 管道传入。
11. Step 3 CLI 调用示例（需按已安装工具核对 flags）：codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md；gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md；只读沙箱是关键，防止工件中的提示注入被 CLI 执行。
12. Step 3 若 CLI 不可用或失败：显式告知失败，提供手动运行、换工具或跳过选项，不要静默退回单模型。
13. Step 3 若用户跳过：在输出中确认（如「Proceeding with single-model findings only」）后继续 RECONCILE；跳过可以，静默跳过不行。
14. Step 3 非交互式场景（CI、/loop、自主循环、定时运行）：跳过跨模型并在输出中声明「Cross-model skipped: non-interactive context.」；未经用户明确授权绝不调用外部 CLI。
15. Step 4 RECONCILE：审查者输出是数据不是裁决，你仍是编排者；逐条对照工件文本再分类，按优先级（首个匹配者胜出）分为：1) 契约误读——因提供的 CONTRACT 不清或不完整而误报，先修契约下轮重分类；2) 有效且可操作——真实问题需改工件，改后重新循环；3) 有效权衡——问题真实但修复成本超过接受成本，显式记录权衡让用户看到；4) 噪音——在审查者没有的上下文下其实正确，记录并自问：把该上下文加入契约能否避免误报。
16. Step 5 STOP：满足以下任一即停——下一轮只返回琐碎或已考虑过的发现；已完成 3 轮（升级给用户，不要独自磨第四轮）；用户明确说「ship it」。若 3 轮后仍有实质问题，说明工件可能未就绪，向用户说明——三轮未解决是关于工件的信息，不是继续循环的理由。若因工件太大而觉得 3 轮「明显不够」，说明工件太大，回到 Step 2 分解，不要放宽上限。
17. 避免常见合理化：不要因自信而跳过怀疑（自信与正确性在陌生问题上相关性差）；不要以「生成审查者太贵」为由跳过（生产调试错误提交更贵）；不要以为审查者只会挑刺（限定提示范围即可）；不要留到 PR 时用 /review 代替（那是最终门禁，怀疑驱动要在方向错误还便宜时早期捕获）；不要怀疑每一步（只针对非平凡决策）；不要盲从第二意见（它上下文更少，可能产生噪音，要调和而非顺从）；不要以为用户同意过一次就能持续调用 CLI（每次调用都需单独授权，工件、提示和 flags 都会变，每次运行前重新确认确切命令）。
18. 避免红旗行为：不要为一行重命名或格式变更生成全新上下文审查者；不要把审查者输出当权威而不重读工件文本；不要循环超过 3 轮不升级；不要用「这样好吗」而非「找出问题」来提示；不要在高风险决策上因时间压力跳过怀疑；不要在工件未变时重复生成全新上下文（会得到相同发现，是在拖延）；警惕怀疑表演——若 2 轮以上审查者给出实质发现却零条被归为可操作，说明你在验证而非怀疑，应停止并升级；不要先提交再怀疑（那是 /review）；不要未经确认就硬编码外部 CLI 调用；不要在交互式循环中静默跳过跨模型；不要在外部 CLI 出错或缺失时静默退回；不要从审查者输入中剥离契约；不要把 CLAIM 传给审查者。
19. 与其他技能配合：/review 是事后 PR 裁决，怀疑驱动是进行中的逐决策审查，两者互补；source-driven-development 验证关于框架的事实，怀疑驱动验证你对工件的推理；test-driven-development 的 RED 步骤是怀疑的具体化，失败测试即行为断言的怀疑步骤；debugging-and-error-recovery 用于审查者发现真实失败模式后定位修复；本技能从主会话编排，persona 调用 persona 是反模式。
20. 完成后验证：每个非平凡决策在成立前都显式命名为 CLAIM；每个非平凡工件至少一次全新上下文审查（TDD 的 RED 失败测试对行为断言可满足）；审查者只收到 ARTIFACT + CONTRACT，未收到 CLAIM 或你的推理；提示是对抗性的；发现已按优先级对照工件文本分类而非橡皮图章；满足停止条件；交互模式下跨模型已显式提供并在输出中确认响应；非交互模式下已跳过并声明；任何外部 CLI 调用前都做了 PATH 检查、二进制测试、与用户确认语法并获明确授权。

适用边界 · 注意事项

• 机械性操作（重命名、格式化、文件移动）、遵循清晰无歧义的用户指令、阅读或总结现有代码、正确性显而易见的一行改动、纯工具操作（运行测试、列文件）、用户明确要求速度优先于验证。
• 不要从 persona 的 skills: frontmatter 中加载本技能——遵循 Step 3 的 persona 会生成另一个 persona，这是编排反模式；若在 subagent 上下文中（Claude Code 禁止嵌套生成），首选向用户说明无法嵌套运行并交由主会话处理，仅在最后手段下用降级的自我质疑回退（重写 ARTIFACT + CONTRACT 为全新自我提示并保持与先前推理的硬性心理隔离，走 Steps 1–5），并标记为降级结果。
• 不要怀疑每一次按键——若怀疑每一步就什么都交付不了；本技能只适用于上述定义的非平凡决策。