doubt-driven-development
Use when a non-trivial decision should not stand without a fresh-context challenge - isolate the artifact and contract, run an adversarial review before committing, and reconcile the findings while change is still cheap.
Best use case
doubt-driven-development is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when a non-trivial decision should not stand without a fresh-context challenge - isolate the artifact and contract, run an adversarial review before committing, and reconcile the findings while change is still cheap.
Teams using doubt-driven-development should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/doubt-driven-development/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How doubt-driven-development Compares
| Feature / Agent | doubt-driven-development | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when a non-trivial decision should not stand without a fresh-context challenge - isolate the artifact and contract, run an adversarial review before committing, and reconcile the findings while change is still cheap.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# Doubt-Driven Development Doubt-Driven Development is an in-flight challenge loop for non-trivial decisions. It is not a final code review and not a broad debate between many paths. It is a targeted attempt to disprove the current decision while the cost of changing course is still low. ## When to Use Apply this skill when the decision: - changes branching logic or invariants - crosses a module or service boundary - asserts a property the compiler will not prove for you - has irreversible or expensive blast radius - depends on context that a future reader will not automatically see Examples: - "this caching layer is safe under concurrency" - "this migration is reversible enough" - "this module boundary is the right one" ## When NOT to Use | Instead of doubt-driven-development | Use | |-------------------------------------|-----| | Choosing among several credible strategies | `council` | | Getting a general second opinion before or after implementation | `outside-voice` | | Proving a task is done with fresh command output | `verification-before-completion` | | Mechanical edits like renames, formatting, or file moves | do the task | ## Workflow ### 1. CLAIM - state what is standing Write the current claim in one or two lines, plus why it matters. Example: ```text Claim: the new retry logic is idempotent under duplicate delivery. Why it matters: if this is wrong, users can be double-charged. ``` If you cannot state the claim clearly, you do not have a reviewable decision yet. ### 2. EXTRACT - isolate the smallest reviewable unit Prepare only: - the artifact under review - the contract it must satisfy Do **not** include your whole reasoning trail. Handing the reviewer your conclusion biases the result. ### 3. DOUBT - run an adversarial review Use a fresh context if possible: - another agent - another model - another reviewer pass with only artifact plus contract Frame the prompt adversarially: ```text Find what is wrong with this artifact. Assume the author is overconfident. Look for hidden assumptions, broken contracts, edge cases, and failure modes. Do not validate the decision. Surface issues. ``` ### 4. Optionally offer a cross-model second opinion If the session is interactive and another CLI or model is available, explicitly offer a second opinion before reconciling. Do not silently skip the option. If the context is non-interactive, say that cross-model review was skipped. ### 5. RECONCILE - classify every finding For each finding, classify it as one of: 1. contract misread 2. valid and actionable 3. valid tradeoff 4. noise Re-read the artifact before deciding. Reviewer output is input, not verdict. ### 6. STOP - keep the loop bounded Stop when: - only trivial or already-addressed findings remain - three cycles have completed - the user explicitly accepts the tradeoff and wants to ship If major issues remain after three cycles, escalate instead of looping forever. ## Common Rationalizations | Rationalization | Reality | |----------------|---------| | "I'm already confident." | Confidence is exactly when blind spots are easiest to miss. | | "I'll just review it at the end." | Late review catches problems when the cost of change is highest. | | "The reviewer disagreed, so I must be wrong." | Fresh review is signal, not automatic verdict. Reconcile it. | ## Red Flags - Passing the claim itself to the reviewer instead of only artifact and contract - Asking "is this good?" instead of "find what is wrong" - Re-running the same unchanged artifact without new evidence - Treating reviewer output as authoritative without re-reading the artifact ## Verification - [ ] A concrete claim was stated before the review - [ ] The reviewer received artifact plus contract, not the whole reasoning chain - [ ] The review prompt was adversarial, not validating - [ ] Findings were classified before acting on them - [ ] The loop stopped because a real stop condition was met ## See Also - [`council`](../council/SKILL.md) - multi-path adversarial deliberation - [`outside-voice`](../outside-voice/SKILL.md) - broader second-opinion challenge, consult, or review - [`verification-before-completion`](../verification-before-completion/SKILL.md) - prove the final claim with live evidence
Related Skills
spec-driven-development
Use before starting any non-trivial feature to write a technical spec first — prevents misaligned implementation and scope creep
source-driven-development
Use when implementing framework-specific or library-specific code — verify non-trivial APIs against official documentation before writing them, and record the source in task notes, docs, or the PR.
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice