doubt-driven-development

1# Doubt-Driven Development
2 
3## Overview
4 
5A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to **disprove**, not approve — before any non-trivial output stands.
6 
7This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
8 
9## When to Use
10 
11A decision is **non-trivial** when at least one of these is true:
12 
13- It introduces or modifies branching logic
14- It crosses a module or service boundary
15- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
16- Its correctness depends on context the future reader cannot see
17- Its blast radius is irreversible (production deploy, data migration, public API change)
18 
19Apply the skill when:
20 
21- About to make an architectural decision under uncertainty
22- About to commit non-trivial code
23- About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec")
24- Working in code you don't fully understand
25 
26**When NOT to use:**
27 
28- Mechanical operations (renaming, formatting, file moves)
29- Following a clear, unambiguous user instruction
30- Reading or summarizing existing code
31- One-line changes with obvious correctness
32…