Doubt Driven Development
Run a fresh-context adversarial pass on branching logic, cross-boundary changes, and unverifiable claims before you commit or ship irreversible work.
Overview
Doubt-Driven Development is an agent skill most often used in Ship (also Build, Operate) that subjects non-trivial decisions to a fresh-context adversarial review before they stand.
Install
npx skills add https://github.com/addyosmani/agent-skills --skill doubt-driven-developmentWhat is this skill?
- Defines non-trivial decisions (branching, boundaries, unverifiable invariants, irreversible blast radius)
- Materializes a reviewer biased to disprove—not approve—before output stands
- Explicitly not `/review` on finished artifacts; applies while you are still deciding
- Triggers on architectural uncertainty, commits, and high-stakes claims
- Optimized when verifying now is cheaper than debugging production later
Adoption & trust: 2k installs on skills.sh; 49.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Long agent sessions and confident outputs hide wrong assumptions until after you commit, deploy, or migrate data.
Who is it for?
Solo builders about to commit branching logic, cross-service changes, or irreversible production work under uncertainty.
Skip if: Trivial edits, typos, or work where types and compilers already prove correctness and blast radius is negligible.
When should I use this skill?
Correctness matters more than speed, unfamiliar code, high stakes (production, security-sensitive logic, irreversible operations), or when verifying now beats debugging later.
What do I get? / Deliverables
Non-trivial choices get cross-examined while you can still change course, reducing costly production debug cycles.
- Adversarial findings on the decision under review
- Course corrections before commit or deploy
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is an in-flight verification posture right before code stands—not a post-hoc verdict on a finished artifact. Review is the best primary facet: it cross-examines decisions while course-correction is still cheap, distinct from generic testing or security scanning alone.
Where it fits
Cross-examine a new idempotency handler before merging a payment webhook path.
Challenge ordering and invariant claims in a PR while the diff is still small.
Stress-test assumptions in auth-sensitive branching before release.
Disprove comfort with a data migration plan before it runs irreversibly in production.
How it compares
Use as an in-flight skepticism gate instead of waiting for a finished-artifact review pass at the end.
Common Questions / FAQ
Who is doubt-driven-development for?
Indie and solo developers using Claude Code, Cursor, or similar agents when correctness, unfamiliar code, or irreversible blast radius outweigh speed.
When should I use doubt-driven-development?
During Build before large refactors; in Ship before commits and security-sensitive merges; in Operate before production deploys, data migrations, or public API changes when invariants are not compiler-checked.
Is doubt-driven-development safe to install?
It is procedural guidance without mandated tool calls; review the Security Audits panel on this Prism page before installing from any third-party skills repo.
SKILL.md
READMESKILL.md - 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) - The user has explicitly asked for speed over verification If you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above. ## Loading Constraints This skill is designed for the **main-session orchestrator**, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer. - **Do NOT add this skill to a persona's `skills:` frontmatter.** A persona that follows Step 3 would spawn another persona — the orchestration anti-pattern explicitly forbidden by `references/orchestration-patterns.md` ("personas do not invoke other personas"). - **If you find yourself applying this skill from inside a subagent context** (where Claude Code prevents nested subagent spawn): the preferred path is to surface to the user that doubt-driven cannot run nested and let the main session handle it. As a last resort only, a degraded self-questioning fallback exists — rewrite ARTIFACT + CONTRACT as a fresh self-prompt with a hard mental separator from your prior reasoning, and walk Steps 1–5. This is **not fresh-context review** (you carry your own context with you), so flag the result as degraded and prefer escalation whenever the user is reachable. ## The Process Copy this checklist when applying the skill: ``` Doubt cycle: - [ ] Step 1: CLAIM — wrote the claim + why-it-matters - [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning - [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt - [ ] Step 4: RECONCILE — classified every finding against the artifact text - [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override) ``` ### Step 1: CLAIM — Surface what stands Name the decision in two or three lines: ``` CLAIM: "The new caching layer is thread-safe under the read-heavy workload described in the spec." WHY THIS MATTERS: a race here corrupts user data and is hard to detect in QA. ``` If you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it. ### Step 2: EXTRACT — Smallest reviewabl