doubt-driven-development

Subjects non-trivial decisions to adversarial fresh-context review before they stand.

Updated Jun 23, 2026
One-click install
npx skills add https://github.com/jampissarandev/Expense-Tracker --skill doubt-driven-development-jampissarandev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/jampissarandev/Expense-Tracker/tree/main/.github/skills/doubt-driven-development
Command: npx skills add https://github.com/jampissarandev/Expense-Tracker --skill doubt-driven-development-jampissarandev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Confident answers are not always correct ones, and long sessions quietly turn assumptions into facts. This Skill catches wrong decisions while course-correction is still cheap by forcing every non-trivial decision through an adversarial fresh-context review before it stands. ## Core Features & Use Cases - Five-step doubt cycle: CLAIM the decision, EXTRACT the smallest reviewable artifact plus contract, DOUBT it with an adversarial reviewer, RECONCILE findings by precedence, and STOP at a bounded condition (trivial findings, 3 cycles, or user override). - Adversarial reviewer prompting: Passes only the artifact and contract to a fresh-context reviewer with an issues-only prompt, never the author's conclusion, avoiding validation bias. - Cross-model escalation: Optionally routes the artifact to an external CLI reviewer (Gemini CLI, Codex CLI) with read-only sandboxing, stdin piping, and explicit per-invocation user authorization. - Use Case: Before committing a caching layer claimed to be thread-safe, extract the diff and its contract, spawn a fresh-context reviewer instructed to find race conditions and unstated assumptions, then classify each finding as contract misread, actionable, trade-off, or noise. ## Quick Start Ask the assistant to apply doubt-driven development to the architectural decision or non-trivial code change you are about to commit.

Frequently Asked Questions about doubt-driven-development

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

FAQPage Schema
How do I verify a code decision before committing it?

Use the doubt cycle: write the claim in two lines, extract the smallest reviewable artifact plus its contract, and spawn a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding as contract misread, actionable, trade-off, or noise before reconciling.

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

Code review is a post-hoc verdict on a finished artifact like a pull request. Doubt-driven development is an in-flight posture that cross-examines individual non-trivial decisions while course-correction is still cheap, before the code is ever committed.

When should I not apply adversarial review to my changes?

Skip it for mechanical operations like renaming or formatting, one-line changes with obvious correctness, reading or summarizing code, pure tooling operations, and when the user explicitly prioritizes speed over verification.

Can I get a second opinion from a different AI model?

Yes, the skill offers cross-model escalation via external CLIs such as Gemini CLI or Codex CLI in interactive sessions. Each invocation requires a PATH check, a working-binary test, read-only sandboxing, stdin piping, and explicit user authorization.

Why should the reviewer not receive my original claim?

Passing the claim biases the reviewer toward agreement with your conclusion. The reviewer should receive only the artifact and the contract so it independently determines whether the artifact satisfies the contract.

How many review cycles should a decision go through?

Stop when findings become trivial, after three cycles, or when the user overrides. If three cycles still surface substantive issues, escalate to the user or decompose the artifact rather than looping further.