doubt-driven-development

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

665|3|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/rizqinrr/viserys-agent --skill doubt-driven-development-rizqinrr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/rizqinrr/viserys-agent/tree/main/skills/doubt-driven-development
Command: npx skills add https://github.com/rizqinrr/viserys-agent --skill doubt-driven-development-rizqinrr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Long coding sessions quietly turn assumptions into facts, and confident answers are not always correct ones. This Skill forces every non-trivial decision through an adversarial fresh-context review while course-correction is still cheap, catching hidden failure modes before they reach production. ## Core Features & Use Cases - Structured Doubt Cycle: A five-step loop (CLAIM, EXTRACT, DOUBT, RECONCILE, STOP) that names each decision, isolates the smallest reviewable artifact, and bounds the review to three cycles. - Adversarial Reviewer Prompting: Spawns a fresh-context reviewer biased to disprove, passing only the artifact and contract so the reviewer is never anchored on your conclusions. - Cross-Model Escalation: Optionally routes the artifact through an external CLI (Gemini, Codex) in a read-only sandbox for a second opinion from a different model architecture. - Use Case: Before committing a thread-safety change to a caching layer, you state the claim, hand the diff and its contract to an adversarial reviewer, classify the findings, and fix real issues before the code lands. ## Quick Start Ask the agent to apply doubt-driven development to stress-test the architectural decision or 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 stress-test a code decision before committing it?

Use the doubt cycle: write a compact CLAIM naming the decision, extract the smallest reviewable artifact plus its contract, then spawn a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding as contract misread, actionable, trade-off, or noise before changing anything.

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

Doubt-driven development is an in-flight posture applied per decision while changes are still cheap to reverse. A code review or /review pass is a post-hoc verdict on a finished artifact such as a pull request. 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 renames and formatting, one-line changes with obvious correctness, reading or summarizing code, and explicit user instructions. The skill applies only to non-trivial decisions such as branching logic, cross-boundary changes, or irreversible operations.

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

Yes. In interactive sessions the skill always offers cross-model escalation through tools like the Gemini or Codex CLI, invoked in a read-only sandbox with the prompt piped via stdin. In non-interactive contexts cross-model is skipped and the skip is announced.

Why does the reviewer only receive the artifact and contract?

Passing your claim or reasoning biases the reviewer toward agreeing with your conclusions. Supplying only the artifact and the contract it must satisfy forces the reviewer to independently determine whether the work holds up.

How many doubt cycles should run before escalating?

Stop after three cycles, when findings become trivial, or when the user says ship it. If substantive issues remain after three cycles, escalate to the user or decompose the artifact rather than looping further.