القائمة
在每个非平凡决策生效之前，对其进行全新上下文的对抗性审查。当正确性比速度更重要时、在不熟悉的代码中工作时、当风险很高时（生产环境、安全敏感逻辑、不可逆操作），或任何自信的输出现在验证比以后调试更便宜的时候使用。在高风险迁移或上线前，压力测试（压测）计划中隐藏的故障模式时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | doubt-driven-development |
| description | 在每个非平凡决策生效之前，对其进行全新上下文的对抗性审查。当正确性比速度更重要时、在不熟悉的代码中工作时、当风险很高时（生产环境、安全敏感逻辑、不可逆操作），或任何自信的输出现在验证比以后调试更便宜的时候使用。在高风险迁移或上线前，压力测试（压测）计划中隐藏的故障模式时使用。 |
自信的答案并不等于正确的答案。长会话积累上下文，悄悄地未经任何人注意就将假设转化为"事实"。怀疑驱动开发是在任何非平凡输出生效之前，引入一个全新上下文的审查者——偏向于证伪而非批准——的纪律。
这不是 /review。/review 是对已完成产物的裁决。这是一种进行中的姿态：非平凡的决策在方向修正仍然便宜时就被交叉审查。
一个决策是非平凡的，当以下至少一项为真时：
在以下情况下应用此技能：
何时不使用：
如果你对每个按键都怀疑，你将什么都交付不了。此技能仅适用于如上定义的非平凡决策。
此技能设计用于主会话协调器，其中步骤 3（DOUBT，详见下文）可以生成一个全新上下文的审查者。
skills: 前置元数据中。 遵循步骤 3 的角色会生成另一个角色——这是 references/orchestration-patterns.md 明确禁止的协调反模式（"角色不要调用其他角色"）。在应用技能时复制此检查清单：
怀疑循环：
- [ ] 步骤 1：CLAIM —— 写下声明 + 为什么重要
- [ ] 步骤 2：EXTRACT —— 提取孤立的产物 + 契约，剥离推理
- [ ] 步骤 3：DOUBT —— 以对抗性提示词调用全新上下文审查者
- [ ] 步骤 4：RECONCILE —— 对照产物文本对每个发现进行分类
- [ ] 步骤 5：STOP —— 满足停止条件（琐碎发现、3 个循环或用户否决）
用两到三行命名决策：
声明："新的缓存层在规格中描述的读密集型工作负载下是线程安全的。"
为什么重要：这里的竞态条件会破坏用户数据，且
在 QA 中难以检测。
如果你不能如此紧凑地写出声明，你拥有的是一种感觉，而非一个决策。在审查它之前先将其提出。
全新上下文的审查者需要产物和契约，而不是旅程。
剥离你的推理。如果你交出结论，你将收回对你结论的验证。单元必须小到审查者能一次阅读就保存在脑海中——如果是 500 行的 PR，先分解。
审查者的提示词必须是对抗性的。框架决定答案。
对抗性审查。找出此产物有什么问题。
假设作者过于自信。寻找：
- 未陈述的假设
- 未处理的边界情况
- 隐藏的耦合或共享状态
- 契约可能被违反的方式
- 这可能破坏的现有约定
- 意外输入下的失败模式
不要验证。不要总结。找问题，或在彻底检查后
明确声明你无法找到任何问题。
产物：<粘贴产物>
契约：<粘贴契约>
只传递 ARTIFACT + CONTRACT。不要传递 CLAIM。 将你的结论交给审查者会使其偏向同意。审查者必须独立确定产物是否满足契约。
在 Claude Code 中，agents/ 中基于角色的审查者一开始就具有隔离的上下文，并可在此处使用——参见 agents/ 了解人员名录和按领域匹配。
上述对抗性提示词优先于角色的默认响应形式。 像 code-reviewer 这样的角色被编写为产生带有优点和缺点的平衡裁决；怀疑驱动需要仅输出问题。将对抗性提示词逐字粘贴到调用中以覆盖角色的默认值。如果角色的响应形式不能被干净地覆盖，回退到使用对抗性提示词的通用子智能体。
单模型审查者与原始作者共享盲点——一个更冷、不同架构的模型捕获它们。怀疑驱动已经为非平凡决策选择加入，因此在该范围内提供跨模型是技能价值的一部分，而非可选摩擦。
交互式会话：始终提供。永远不要静默跳过。
步骤 1：询问用户
在上面步骤 3 的单模型审查之后，在 RECONCILE 之前，暂停并询问：
"单模型审查完成。想要跨模型的第二意见吗？选项：Gemini CLI、Codex CLI、手动外部审查（你将其粘贴到别处），或跳过。"
这个问题在每个交互式怀疑循环中都是强制的——即使是对感觉低风险的产物。用户——而非智能体——决定成本是否值得。智能体的工作是提出这个选择。
步骤 2：如果用户选择 CLI —— 验证，然后调用
which gemini、which codex）。gemini --version 或等效命令），然后再传递完整提示词——过期或损坏的二进制文件可能通过 which 但在实际输入上失败。$(...) 或反引号，优先使用 stdin（echo … | gemini）或 heredoc 而非内联 -p "…"。有疑问时，在运行之前要求用户确认调用。永远不要将产物内插到 shell 引号参数中。 代码、markdown 和审查提示词经常包含反引号、$(...) 和引号字符，这些东西要么会截断提示词，要么会执行嵌入的 shell 命令。将完整提示词写入文件并通过 stdin 管道传递。
示例形式（根据你安装的工具验证标志——语法在不同实现和版本间有所不同）：
# 先将对抗性提示词 + ARTIFACT + CONTRACT 写入临时文件。
# 然后通过 stdin 管道传递，使产物中的 shell 元字符保持惰性。
# Codex（只读沙箱防止 CLI 写入你的工作区）：
codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md
# Gemini（'--approval-mode plan' 是只读的；'-p ""' 触发非交互式
# 模式，提示词从 stdin 读取）：
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md
只读沙箱是关键承载细节：一个怀疑产物本身可能包含指令（有意或无意的提示注入），否则跨模型 CLI 会对其工作区执行这些指令。
步骤 3：如果 CLI 不可用或失败
显式提出失败。提供：手动运行、尝试不同的工具或跳过。不要静默回退到单模型——用户应该知道跨模型没有发生。
步骤 4：如果用户跳过
在输出中确认跳过（"仅继续使用单模型发现"）并继续到 RECONCILE。跳过可以；静默跳过不行。
非交互式上下文（CI、/loop、自主循环、计划运行）：
跨模型增加了成本、延迟和工具脆弱性。智能体在每个循环都提出这个选择；用户决定此产物是否值得这样做。
审查者的输出是数据，不是裁决。你仍然是协调者。 在分类之前对照每个发现重新阅读产物文本——盲目接受审查者和忽略它同样是失败模式。
对每个发现，按以下优先级顺序分类（第一个匹配的类别胜出）：
一个全新的审查者可能因为缺乏上下文而出错。不要仅仅因为它"新"就屈从。
在以下情况下停止：
如果 3 个循环后审查者仍然提出实质性问题，产物可能尚未准备好。将此向用户提出——三个未解决的循环是关于产物的信息，而非继续循环的理由。
如果 3 个循环因产物太大而"明显不足"：产物太大了——回到步骤 2 并分解。不要解除限制。
| 合理化借口 | 现实 |
|---|---|
| "我有信心，跳过怀疑步骤" | 在新问题上，信心与正确性的相关性很差。确定性的时刻恰好是盲点隐藏的地方。 |
| "生成一个审查者很贵" | 在生产中调试一个错误提交更贵。检查是有界的；缺陷不是。 |
| "审查者只会挑小毛病" | 只有在没有约束范围的情况下才会。将提示词限制为"在契约下会使其失败的问题"。 |
"我最后用 /review 做怀疑就行" | /review 是最后的门禁。怀疑驱动在早期捕获错误方向，此时方向修正还很便宜。到 PR 时间就太晚了。 |
| "如果我对每一步都怀疑，我将永远无法交付" | 技能适用于非平凡决策，而非每个按键。重新阅读"何时不使用"。 |
| "两个意见总是比一个好" | 当第二个有更少的上下文并产生噪音时并非如此。协调，不要屈从。 |
| "审查者不同意，所以我错了" | 审查者缺乏你的上下文——分歧是信息，而非裁决。重新阅读产物，分类，然后决定。 |
| "跨模型总是更好" | 跨模型捕获单模型与自身共享的盲点，但它增加了成本和工具脆弱性。在每个交互式怀疑循环中提供它——用户决定产物是否值得这样做。智能体的工作是提出选择，而非把关。 |
| "用户说了一次可以，所以我可以继续调用 CLI" | 每次调用都有其自己的授权。产物、提示词和标志在调用之间会变化——在每次运行前重新与用户确认确切的命令。 |
/review，不是怀疑驱动开发code-review-and-quality / /review：互补。/review 是事后的 PR 裁决；怀疑驱动是进行中的逐决策审查。两者都使用。source-driven-development：SDD 对照官方文档验证关于框架的事实。怀疑驱动验证你关于产物的推理。SDD 检查 API 是否存在；怀疑驱动检查你是否在契约下正确使用了它。test-driven-development：TDD 的 RED 步骤是具象化的怀疑——一个失败的测试是一次证伪尝试。当 TDD 适用时，那个失败的测试就是行为声明的怀疑步骤。debugging-and-error-recovery：当审查者提出真正的失败模式时，切换到调试技能来定位和修复。references/orchestration-patterns.md）：此技能从主会话协调。一个角色调用另一个角色是反模式 B——见上方加载约束。应用怀疑驱动开发后：