用途：怀疑驱动开发（Doubt-Driven Development）是一套在飞行中执行的纪律，用于在非平凡决策定案前引入一个“全新上下文”的审查者，其偏向是证伪而非批准。它不是代码审查或评审——后者针对已完成产物给出裁决，而它是在纠错成本还低时对决策进行交叉盘问。
何时算“非平凡”：满足以下任一条件——引入或修改分支逻辑；跨模块或服务边界；断言类型系统或编译器无法验证的性质（线程安全、幂等、顺序、不变量）；正确性依赖未来读者看不到的上下文；影响面不可逆（生产部署、数据迁移、公开 API 变更）。适用场景包括：在不确定下做架构决策、提交非平凡代码、声称不明显的结论（“这是安全的”“这能扩展”“符合规格”）、在不完全理解的代码中工作。
五步流程：1）ARTIFACT——用一段话精确写下决定了什么/将要做什么，具体到陌生人可据此实现；2）CONTRACT——陈述该产物必须满足的性质、不变量、边界情况与错误模式；3）DOUBT——启动一个全新上下文的审查者，它没见过本会话任何先前推理，只收到 ARTIFACT 与 CONTRACT，任务是找出反例、边界情况、隐藏耦合、错误假设，输出 HOLDS 或 BREAKS（附具体失败）；在 Claude Code 中即用自包含提示启动一个子代理（如 general-purpose 或 junior-engineer），审查者不得继承编排者的自信；4）RECONCILE——HOLDS 则继续，BREAKS 则修复产物后回到第 3 步，或书面论证该缺陷不适用，或在暴露真实歧义时上报人类；5）STAND——只有在 RECONCILE 得到干净的 HOLDS 后决策才成立，当性质不明显时把 HOLDS 记录到代码注释、ADR 或提交信息中。
不要使用的情况（避免分析瘫痪）：机械操作（重命名、格式化、移动文件）；清晰无歧义的用户指令；阅读或总结既有代码；正确性显然的一行改动；纯工具操作（跑测试、列文件）；用户明确要求速度优先于验证。若对每次敲键都怀疑，就什么都交付不了。
加载约束：不要把该技能加到子代理人格的 frontmatter 中——遵循第 3 步的人格会再生成一个人格，属反模式；它应在拥有派发权限的主会话中运行。若从子代理内部应用（嵌套派发被禁止），应向用户说明该技能需要主会话权限并交由用户处理；仅作为降级回退，可把 ARTIFACT + CONTRACT 改写为与先前推理有硬性心理隔离的全新自提示，并将结果标记为降级——那并非全新上下文审查。
规则：只应用于非平凡决策；审查者必须有全新上下文、不继承推理；审查者偏向证伪；BREAKS 发现要么修复产物，要么以记录在案的理由明确驳回；把不明显的 HOLDS 记录为注释/ADR/提交信息；审查者未真正运行时绝不静默批准。危险信号：以“大概没问题”为由跳过审查者；审查者过于轻易同意（提示可能泄露了自信）；换提示重跑直到出现 HOLDS（挑选结果）；把流程用于琐碎工作（只有仪式，没有安全）。
验证清单：ARTIFACT 已明确写出；CONTRACT 枚举了不变量与边界情况；全新上下文审查者已运行并返回 HOLDS；若 HOLDS 不明显，已记录在未来读者能找到的地方。资料未提供工具形态、安装方式、平台支持或收费信息。