doubt-driven-development

Reviews non-trivial implementation decisions through fresh-context adversarial subagent critique before they stand.

Updated Apr 6, 2026
One-click install
npx skills add https://github.com/toderian/project_template --skill doubt-driven-development-toderian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/toderian/project_template/tree/main/plugins/agents-extras/skills/doubt-driven-development
Command: npx skills add https://github.com/toderian/project_template --skill doubt-driven-development-toderian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Confident implementation decisions often go unchallenged until they fail in production. This Skill subjects non-trivial decisions to an adversarial review by a fresh-context reviewer that sees only the artifact and its contract, not your reasoning, catching unsound choices before they become final. ## Core Features & Use Cases - Fresh-Context Adversarial Review: Dispatches a reviewer subagent with only the smallest reviewable artifact, its contract, and a refute-first instruction, deliberately withholding your justification to avoid anchoring. - Trigger Criteria: Fires on decisions that branch logic, cross module boundaries, assert unverifiable properties (safe, atomic, idempotent), or carry irreversible blast radius like migrations and deletions. - Bounded Iteration with Stop Rule: Runs at most 3 review rounds, stopping early when findings are trivial, and escalates to the human when findings do not converge. - Use Case: Before merging a schema migration you believe is backwards-compatible, run a doubt cycle so a reviewer tries to break that claim against the actual diff and contract. ## Quick Start Ask the agent to doubt or stress-test the implementation decision you just made before finalizing it.

Frequently Asked Questions about doubt-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I stress-test an implementation decision before committing to it?

Run a doubt cycle: hand a fresh-context reviewer the smallest reviewable artifact plus its contract and a refute-first instruction, withholding your own reasoning. The reviewer tries to break the decision against the actual text and reports findings grounded in quoted lines.

When should I run adversarial review on a code decision?

Run it when a decision branches logic, crosses a module boundary, asserts an unverifiable property like atomicity or backwards compatibility, or is hard to reverse such as a data migration. Skip it for trivial or easily reversible decisions.

What is the difference between doubt-driven-development and plan review?

Plan review techniques like grilling or a plan-critic interrogate an overall plan with the user. Doubt-driven development operates one level down, reviewing individual implementation decisions as they are made during coding.

How many review rounds should an adversarial decision review take?

At most three rounds. Stop earlier when a round surfaces only trivial findings, and never re-dispatch an identical prompt. Three rounds with non-converging findings means the decision is genuinely hard and should be escalated to a human.

When should I not use adversarial review for a decision?

Skip it when a decision is trivial or easy to reverse, since you can simply reverse it later. The discipline mirrors ADR criteria: no real trade-off and no irreversibility means no doubt cycle is warranted.