doubt-driven-development

# Doubt-Driven Development ## Overview A 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. This 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. ## When to Use A decision is **non-trivial** when at least one of these is true: - 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 code - About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec") - Working in code you don't fully understand **When NOT to use:** - Mechanical operations (renaming, formatting, file moves) - Following a clear, unambiguous user instruction - Reading or summarizing existing code - One-line changes with obvious correctness - Pure tooling operations (running tests, listing files)...