---
name: doubt-driven-development
description: Subject every non-trivial decision to a fresh-context adversarial review before it stands, while course-correction is still cheap. Use when correctness beats speed: unfamiliar code, production or security-sensitive logic, irreversible operations, or any confident claim that is cheaper to verify now than debug later. Not for post-hoc PR review: use a code review skill. Not for splitting independent work across agents: use dispatching-parallel-agents.
license: MIT
metadata:
  author: TechTide AI (Alex Cinovoj)
  provenance: rewritten from patterns in Addy Osmani's agent-skills (MIT)
  category: Methodology & Process
---

# Doubt-Driven Development

A confident answer is not a correct one. Long sessions quietly promote assumptions into "facts", so before a non-trivial output stands, a fresh-context reviewer biased to disprove it gets a shot at it. This is in-flight cross-examination, not a final review gate.

## When It Applies

A decision is non-trivial when any of these hold: it adds or changes branching logic, crosses a module or service boundary, asserts a property the compiler cannot verify (thread safety, idempotence, ordering), depends on context a future reader cannot see, or has irreversible blast radius (deploys, migrations, public API changes).

Skip it for: renames, formatting, file moves, one-liners with obvious correctness, reading or summarizing code, following a clear explicit instruction, or when the user asked for speed over verification. Doubt every keystroke and you ship nothing.

## The Doubt Cycle

Copy this checklist per cycle:

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

1. **CLAIM.** Name the decision in two or three lines: the claim, and why being wrong is expensive. Cannot write it that compactly? You have a vibe, not a decision. Surface it first.
2. **EXTRACT.** The reviewer gets the artifact and its contract, never the journey. Code: the diff or function, not the file. Decision: the proposal in 3-5 sentences plus the constraints it must satisfy. Strip your reasoning: hand over conclusions and you get back validation of your conclusions. If the unit will not fit in one careful read, decompose before reviewing.
3. **DOUBT.** Spawn a fresh-context subagent with an adversarial prompt. Framing decides the answer, so demand disproof:

   ```
   Adversarial review. Find what is wrong with this artifact.
   Assume the author is overconfident. Look for: unstated
   assumptions, unhandled edge cases, hidden coupling, contract
   violations, broken conventions, failure modes under bad input.
   Do NOT validate. Do NOT summarize. Find issues, or state that
   you cannot find any after thorough examination.
   ARTIFACT: <artifact>
   CONTRACT: <contract>
   ```

   Never pass the CLAIM: handing the reviewer your conclusion biases it toward agreement. Optionally, and only with the user's explicit go-ahead, get a second opinion from a different model; if you do, pass artifact and contract through a file or stdin, never interpolated into a shell-quoted argument, and keep the external tool read-only.
4. **RECONCILE.** Reviewer output is data, not verdict. Re-read the artifact against each finding, then classify in this precedence order, first match wins: contract misread (fix the contract, re-cycle), valid and actionable (change the artifact, re-loop), valid trade-off (accept, document explicitly), noise (correct under context the reviewer lacked; ask whether adding that context to the contract would have prevented the false flag). Rubber-stamping the reviewer is the same failure as ignoring it.
5. **STOP.** Stop when the next cycle returns only trivial or known findings, or after 3 cycles (escalate, do not grind a fourth alone), or when the user says ship it. Three cycles of substantive findings is information about the artifact: surface it. If 3 cycles feels insufficient because the artifact is big, the artifact is too big: return to step 2 and decompose. Do not lift the bound.

## Verification

At the end of a doubt cycle, audit the transcript. Expect: the reviewer received artifact plus contract only (no CLAIM, no reasoning), the prompt demanded issues rather than approval, and every finding has a written classification. If any finding was classified without re-reading the artifact text, redo step 4 for that finding before the decision stands.

## Good vs Bad

Judgment call: prompting the reviewer about a new caching layer.

**Bad:** "I built a thread-safe caching layer for read-heavy loads, here's my reasoning, is this good?" Conclusion handed over, validation requested, validation received.

**Good:** "Adversarial review. ARTIFACT: [the 40-line cache class diff]. CONTRACT: concurrent reads during single-writer invalidation must never return stale entries after commit. Find violations." The reviewer independently attacks the property.

## Footguns

- **Passing your reasoning along.** The reviewer inherits your blind spots and agrees with you. Fix: artifact and contract only, always.
- **Deferring to the fresh reviewer.** Fresh also means context-poor; findings can be wrong. Fix: classify against the artifact text, use the noise category deliberately.
- **Re-spawning on an unchanged artifact.** Same input, same findings, you are stalling. Fix: change the artifact or the contract before the next cycle.
- **Doubting after commit.** That is post-hoc review; the cheap correction window is gone. Fix: run the cycle before the decision stands, at claim time.

## Red Flags

Stop if you catch yourself thinking or saying:

- "I'm confident, skip the doubt step this once"
- "Spawning a reviewer is too expensive here"
- "The reviewer will just nitpick"
- "I'll doubt it at the end during review"
- "The reviewer found nothing serious" (when you passed it your conclusions)
- "Two cycles of findings, zero classified actionable" (that is doubt theater: you are validating, not doubting; escalate)

The letter of the cycle is the spirit of the cycle. Any workaround that leaves the claim unexamined by fresh context is skipping the skill, whatever it is called.

## Completion Checklist

- [ ] Non-trivial decisions named as compact CLAIMs before standing
- [ ] Reviewer got artifact plus contract, not the CLAIM or reasoning
- [ ] Prompt was adversarial, not approval-seeking
- [ ] Every finding classified by the precedence order
- [ ] Stop condition met and recorded, 3-cycle bound respected
- [ ] Accepted trade-offs documented where the user sees them

Any box unchecked: not done. Fix or say so.