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.