What is Doubt-Driven Development and how does it differ from a standard code review?

Doubt-Driven Development is an in-flight adversarial scrutiny process applied to non-trivial decisions before they're finalized, not a verdict on finished artifacts like `/review`. It forces cross-examination at decision points while course-correction is still cheap, preventing long sessions from quietly turning assumptions into unquestioned facts.

When should I apply Doubt-Driven Development?

Apply it when about to make an architectural decision under uncertainty, commit non-trivial code, claim a non-obvious fact (like "this is safe" or "this scales"), or work in code you don't fully understand. A decision is non-trivial if it introduces branching logic, crosses module boundaries, asserts unverifiable properties, depends on hidden context, or has irreversible blast radius.

When should I NOT use Doubt-Driven Development?

Skip it for mechanical operations (renaming, formatting, file moves), following clear unambiguous instructions, reading or summarizing existing code, one-line changes with obvious correctness, pure tooling operations, or when the user explicitly asks for speed over verification.

What are the five steps in the Doubt-Driven Development process?

Step 1: CLAIM — name the decision and why it matters. Step 2: EXTRACT — isolate the artifact and contract, stripped of reasoning. Step 3: DOUBT — invoke a fresh-context reviewer with an adversarial prompt. Step 4: RECONCILE — classify every finding against the artifact text. Step 5: STOP — meet the stop condition (trivial findings, 3 cycles, or user override).

Can I use Doubt-Driven Development inside a persona or subagent?

No. This skill is designed for the main-session orchestrator only. Do not add it to a persona's `skills:` frontmatter, as a persona following Step 3 would spawn another persona, creating a forbidden orchestration anti-pattern. If nested in a subagent context, surface to the user that doubt-driven cannot run nested and let the main session handle it.

Skill

Challenge non-trivial code decisions with fresh-context review

Name: Doubt-Driven Development
Availability: OnlineOnly
Author: addyosmani

Doubt-driven development materializes a fresh-context reviewer biased to disprove, not approve, before non-trivial output stands, catching silent context drift

Get skill

addyosmani

Own this? Claim it

Spark score

out of 100

Updated 28 days ago

Source checked Aug 24, 2026

Version 15.16.0

Add to Favorites

Why it matters

Prevent confident but incorrect decisions from shipping by materializing an adversarial, fresh-context reviewer that actively tries to disprove non-trivial code, architecture, or assertion claims before they become expensive to fix.

Outcomes

What it gets done

Spawn isolated reviewers to challenge architectural decisions under uncertainty

Cross-examine thread-safety, invariant, and correctness claims the compiler cannot verify

Surface unstated assumptions and edge cases in branching logic or cross-boundary calls

Offer cross-model second opinions via CLI tools to catch single-model blind spots

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-doubt-driven-development | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Doubt-Driven Development

Doubt-driven development materializes a fresh-context reviewer biased to disprove, not approve, non-trivial decisions during active development. It catches silent context drift that accumulates in long sessions, where assumptions quietly harden into accepted "facts" without scrutiny. Use it when making non-trivial decisions in extended sessions where context accumulates and assumptions may calcify. Apply it in-flight while course-correction is still cheap, not as a post-completion verdict like `/review`.

What it does

Doubt-driven development is a discipline that materializes a fresh-context reviewer to cross-examine non-trivial decisions while course-correction is still cheap. It operates on the principle that confident answers are not necessarily correct ones, and that long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. The reviewer is biased to disprove, not approve, catching silent drift before output stands.

When to use - and when NOT to

Use doubt-driven development when making non-trivial decisions during active development sessions, especially in long contexts where assumptions may have quietly calcified into accepted truths. Apply it in-flight, while changes are still inexpensive to make, rather than waiting for a finished artifact.

Do not use this as a replacement for /review. /review is a verdict on a finished artifact; doubt-driven development is an in-flight posture applied during the decision-making process itself, not after completion.

Inputs and outputs

Non-trivial decisions get cross-examined by a fresh-context reviewer biased to disprove, not approve, surfacing how long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing.

Who it's for

Doubt-driven development serves those working in extended sessions where context accumulates and assumptions can silently harden. It is for those who recognize that confidence and correctness are not synonymous, and who value catching errors while correction costs remain low. Unlike /review, which evaluates completed work, this approach embeds skeptical validation directly into the decision-making flow.

Source README

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.

FAQ

Common questions

Discussion