doubt-driven-development

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

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/MoofonLi/dev-ready --skill doubt-driven-development-moofonli
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/MoofonLi/dev-ready/tree/main/src/dev_ready/templates/claude/skills/doubt-driven-development
Command: npx skills add https://github.com/MoofonLi/dev-ready --skill doubt-driven-development-moofonli

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Confident answers are not always correct ones, and long coding sessions quietly turn assumptions into accepted facts. This Skill catches wrong directions early by forcing every non-trivial decision through an adversarial fresh-context review while course-correction is still cheap. ## Core Features & Use Cases - Five-Step Doubt Cycle: CLAIM the decision, EXTRACT the smallest reviewable artifact plus contract, DOUBT it with an adversarial fresh-context 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 — never your conclusion — with an issues-only prompt so the reviewer disproves rather than validates. - Cross-Model Escalation: Optionally routes the review through external CLIs like Gemini or Codex with read-only sandboxing, stdin piping, and explicit per-invocation user authorization. - Use Case: Before committing a new caching layer claimed to be thread-safe, the Skill extracts the diff and its contract, spawns a fresh reviewer instructed to find race conditions and unstated assumptions, then classifies each finding as contract misread, actionable, trade-off, or noise. ## Quick Start Ask your agent to apply doubt-driven development to review 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 a compact CLAIM of the decision, 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 proceeding.

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

Doubt-driven development is an in-flight posture applied per non-trivial decision while changes are still cheap, whereas code review is a post-hoc verdict on a finished artifact or PR. The two are complementary and can both be used.

When should I not use adversarial review on my code?

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 use Gemini or Codex CLI for a second opinion on code?

Yes, in interactive sessions the Skill offers cross-model escalation after the single-model review. Verify the binary works, pipe the prompt via stdin with a read-only sandbox, and get explicit user authorization for each invocation.

Why should the reviewer not receive my conclusion or reasoning?

Passing your CLAIM or reasoning biases the reviewer toward agreement with your conclusion. The reviewer must independently determine whether the artifact satisfies the contract, so it receives only the artifact and contract.

What are the limitations of fresh-context adversarial review?

A fresh reviewer lacks session context and can produce noise or false flags, so findings must be re-classified against the artifact text rather than rubber-stamped. The loop is bounded at three cycles; persistent substantive issues mean the artifact likely needs decomposition.