doubt-driven

# Doubt-Driven Development ## Three principles 1. **A confident answer is not a correct one.** Long sessions turn assumptions into "facts" without anyone noticing. 2. **The reviewer gets the artifact and the contract, never your reasoning or your conclusion.** A prompt biased to disprove, not approve, catches what a summary-and-agree pass would wave through. 3. **The loop is bounded, not recursive.** It stops at trivial findings, three cycles, or user override — and three unresolved cycles is information about the artifact, not a reason to grind a fourth. ## Overview Doubt-driven development materializes a fresh-context reviewer, biased to **disprove**, not approve, before any non-trivial output stands. This is an in-flight posture, not a post-hoc gate. A verdict on a finished artifact arrives too late to change direction cheaply. Doubt-driven cross-examines non-trivial decisions while course-correction still costs little. ## When to Use A decision is **non-trivial** when at least one of these holds: - It introduces or modifies branching logic - It crosses a module or service boundary - It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants) - Its correctness depends on context the future reader cannot see - Its blast radius is irreversible (production deploy, data migration, public API change) Apply the skill when: - About to make an architectural decision under uncertainty - About to commit non-trivial cod...