doubt-driven-development

用途

Doubt-Driven Development（怀疑驱动开发）解决的是这样一个问题：一个自信的回答并不等于一个正确的回答。在长时间的会话中，上下文会不断累积，假设会在无人察觉的情况下被悄悄当成「事实」。该技能的作用是在任何非平凡产出正式成立之前，先物化一个「新鲜上下文」的审查者，并且这个审查者被设定为倾向于证伪而非认可。

它明确不是 /review。/review 是对已完成产物给出的裁决；而本技能是一种「进行中」的姿态——非平凡决策在纠错成本还很低的时候就被交叉盘问。

主要能力

非平凡决策的判定：满足以下任一条件即视为非平凡——引入或修改分支逻辑；跨越模块或服务边界；断言类型系统或编译器无法验证的性质（线程安全、幂等性、顺序性、不变式）；正确性依赖未来读者看不到的上下文；影响范围不可逆（生产部署、数据迁移、公开 API 变更）。
五步怀疑循环：Step 1 CLAIM（用两三行写出主张与为何重要）；Step 2 EXTRACT（剥离推理，只交付最小可审查单元与契约）；Step 3 DOUBT（用对抗性提示调用新鲜上下文审查者）；Step 4 RECONCILE（把发现与产出文本比对后分类）；Step 5 STOP（有界停止）。
跨模型升级：单模型审查者会与原作者的盲点共享，换用架构不同的更冷模型可捕捉这些盲点。交互式会话中每次都要主动向用户提供该选项，绝不静默跳过。

使用方式

应用时使用该清单：

Doubt cycle:
- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
- [ ] Step 4: RECONCILE — classified every finding against the artifact text
- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)

Step 1 需写出紧凑的主张，示例：

CLAIM: "The new caching layer is thread-safe under the
        read-heavy workload described in the spec."
WHY THIS MATTERS: a race here corrupts user data and is
                  hard to detect in QA.

Step 2 交付产物与契约，剥离自己的推理；若是一份 500 行的 PR，应先拆解。

Step 3 的审查者提示必须是对抗性的，例如：

Adversarial review. Find what is wrong with this artifact.
Assume the author is overconfident. Look for:
- Unstated assumptions
- Edge cases not handled
- Hidden coupling or shared state
- Ways the contract could be violated
- Existing conventions this might break
- Failure modes under unexpected input

Do NOT validate. Do NOT summarize. Find issues, or state
explicitly that you cannot find any after thorough examination.

ARTIFACT: <paste artifact>
CONTRACT: <paste contract>

只传递 ARTIFACT + CONTRACT，不传 CLAIM，以免诱导审查者附和。

跨模型升级在交互式会话中始终要提供；选择 CLI 后需先确认工具在 PATH 中、测试其可运行、与用户确认确切调用方式与参数，再调用。示例形态（需按自己安装的工具核对参数，语法因实现与版本而异）：

# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.
# Then pipe via stdin so shell metacharacters in the artifact stay inert.

# Codex (read-only sandbox keeps the CLI from writing to your workspace):
codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md

# Gemini ('--approval-mode plan' is read-only; '-p ""' triggers non-interactive
# mode and the prompt is read from stdin):
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md

Step 4 的分类按优先级依次为：契约误读、有效且可操作、有效但属权衡、噪声。Step 5 的停止条件为：下一轮只返回琐碎或已考虑过的发现，或完成 3 轮循环，或用户明确说 ship it。

适用场景

在以下情形应用该技能：在不确定下即将做架构决策；即将提交非平凡代码；即将声称某个非显而易见的事实（「这是安全的」「这能扩展」「这符合规范」）；在不完全理解的代码中工作。

在以下情形不适用：机械操作（重命名、格式化、移动文件）；遵循清晰无歧义的用户指令；阅读或总结已有代码；正确性显而易见的一行改动；纯工具操作（运行测试、列文件）；用户明确要求速度优先于验证。

限制

该技能设计用于主会话编排器，Step 3 需要能生成新鲜上下文审查者。不应将其加入 persona 的 skills frontmatter，因为遵循 Step 3 的 persona 会生成另一个 persona，属于编排反模式。
在子代理上下文中（Claude Code 禁止嵌套生成子代理）无法嵌套运行，首选路径是向用户说明并交由主会话处理；仅作为最后手段存在降级的自问回退，且其结果须标记为降级。
迭代有界：超过 3 轮不得独自继续打磨，应升级给用户；若因产物过大而认为 3 轮不够，说明产物过大，应回到 Step 2 拆解，而不是放宽上限。
绝不在没有用户明确授权的情况下调用外部 CLI，每次调用都是独立的授权。
非交互环境（CI、/loop、autonomous-loop、定时运行）跳过跨模型，且必须在输出中声明该跳过。

技能介绍

用途

主要能力

使用方式

适用场景

限制