| name | doubt-driven-development |
| description | Challenge assumptions and hidden dependencies before they become bugs |
| difficulty | senior |
| domains | ["general"] |
Overview
Every "I'm sure this is fine" is a future incident. This skill applies systematic skepticism to assumptions in requirements, implementations, and integrations before they ship.
When to Use
- When something "seems obvious" but hasn't been verified
- When implementing code that depends on external behavior
- When code review reveals an implicit assumption
- When debugging a "that's impossible" bug
Process
Step 1: List your assumptions
For every non-trivial implementation, write down all the things that must be true for it to work. Make implicit assumptions explicit.
Step 2: Classify by risk
For each assumption: what is the cost if it's wrong? High-cost assumptions must be verified before shipping.
Step 3: Verify high-cost assumptions
How to verify:
- Write a test that fails if the assumption is wrong
- Find the source of truth (spec, documentation)
- Measure it (add a log, run a query)
- Ask someone who knows
Step 4: Make remaining assumptions visible
For assumptions you can't verify before shipping: document them as known assumptions. Future engineers must be able to find them.
Verification Requirements