Doubt-Driven Development

---
name: doubt-driven-development
description: Use when reviewing a non-trivial design decision before committing it. Triggers on "is this safe to ship", "check this design", "review my API contract", or when a decision has irreversible blast radius — data migration, public API change, production deploy, concurrency invariant.
---

# Doubt-Driven Development

The engineer who made a design decision is the last person who will spot its flaw — they have already reasoned themselves into it. This skill inserts a fresh-context adversarial reviewer mid-flight, before the irreversible step.

## When this applies

A decision is non-trivial when any of these hold:

- Correctness depends on context the type system cannot verify: ordering invariants, idempotency guarantees, upstream service behavior
- Blast radius is irreversible: production deploy, data migration, public API contract change
- It encodes a concurrency invariant a future reader will not see

Routine changes — renaming a local variable, bumping a well-tested dependency, adding a UI string — do not need this review.

## The cycle

### CLAIM
State the irreversible action in one sentence. Not the intent — the action. "The migration drops and recreates `user_sessions` with a new composite index."

### EXTRACT
List the central claims the decision depends on. Two to five claims:
- Invariants that must hold ("no in-flight sessions at cutover")
- Contracts with external actors ("OAuth provider re-issues tokens on next login")
- Ordering assumptions ("migration runs before new code deploys")

If you cannot name the claims, you do not yet understand the decision well enough to commit it.

### DOUBT
Switch to adversarial-only framing. The reviewer's job is to find failures.

Rules:
- Output issues only — no balanced verdict, no "on the other hand"
- For each claim: "Under what condition does this fail? Who else depends on this? What breaks if the ordering is wrong?"
- Do not soften findings to avoid conflict

If the review finds nothing, that is a valid outcome. Do not manufacture doubt to fill the section.

### RECONCILE
For each issue:
- **Blocker**: stop and rethink the decision
- **Manageable**: proceed with a specific mitigation

Specific mitigations: "check for in-flight sessions before the DROP", "add a maintenance window", "gate the deploy behind job completion status." Not "be careful."

### STOP
End when all blockers are resolved or zero issues were found. One pass through the cycle. If RECONCILE surfaces a new major issue, restart from CLAIM with a revised decision — not another DOUBT pass on the same design.

## Output format

```
## Decision
[One-sentence irreversible action]

## Claims extracted
1. [Claim]
2. [Claim]

## Doubt pass — issues only
- [Issue: specific failure condition for claim 1]
- [Issue: specific failure condition for claim 2]
(Empty if no issues found — valid result)

## Reconcile
- [Issue] → Blocker | Manageable
  Mitigation: [specific action]

## Verdict
PROCEED | STOP + rethink
[One sentence: what changes before committing, if anything]
```

## Scope

This skill runs on the engineer's own design decisions before commitment. It is not:
- Post-hoc verification of AI-generated code (use ai-output-verifier)
- Architectural security threat analysis (use threat-model-builder)
- Code review of existing code (use code-review-helper)

Use it when the decision, not the code, is what needs pressure-testing.