doubt-driven-development

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

9|1|Updated Aug 28, 2026
One-click install
npx skills add https://github.com/RisorseArtificiali/skills --skill doubt-driven-development-risorseartificiali
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/RisorseArtificiali/skills/tree/main/forked/doubt-driven-development
Command: npx skills add https://github.com/RisorseArtificiali/skills --skill doubt-driven-development-risorseartificiali

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Long coding sessions accumulate context that quietly turns assumptions into facts, and confident answers are not always correct ones. This Skill catches wrong directions early by forcing every non-trivial decision through a fresh-context adversarial review while course-correction is still cheap. ## Core Features & Use Cases - Bounded doubt cycle: A five-step loop (CLAIM, EXTRACT, DOUBT, RECONCILE, STOP) that names the decision, isolates the smallest reviewable artifact, invokes an adversarial fresh-context reviewer, classifies findings, and stops after at most three cycles. - Adversarial reviewer prompt: A fixed prompt that instructs reviewers to find issues rather than validate, receiving only the artifact and contract so the orchestrator's conclusions cannot bias the review. - Cross-model escalation: In interactive sessions the user is always offered a second opinion from an external CLI (Gemini or Codex) with read-only sandboxing and stdin piping to prevent shell injection; in non-interactive contexts the skip is announced. - Use Case: Before committing a caching layer claimed to be thread-safe, the orchestrator extracts the diff and the concurrency contract, spawns a fresh reviewer biased to disprove the claim, reconciles the findings, and fixes a real race condition before merge. ## Quick Start Ask the agent 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 get a second opinion on a code decision before committing?▼

Apply the doubt cycle: write a compact CLAIM, 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 changing anything.

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

Doubt-driven development is an in-flight posture that cross-examines individual non-trivial decisions while course-correction is cheap. A code review is a post-hoc verdict on a finished artifact such as a pull request, and the two are complementary.

When should I not use adversarial review on 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 use an external model like Gemini or Codex CLI for cross-model review?▼

Yes, in interactive sessions the user is always offered a cross-model second opinion. The agent verifies the CLI exists and works, confirms the exact invocation, pipes the prompt via stdin, and uses a read-only sandbox; non-interactive contexts skip it with an announced notice.

Why must the reviewer not receive my original claim or reasoning?▼

Handing the reviewer your conclusion biases it toward agreement and produces validation instead of scrutiny. The reviewer receives only the artifact and the contract so it independently determines whether the artifact satisfies the contract.

What happens if the reviewer keeps finding issues after multiple cycles?▼

The loop is bounded at three cycles. If substantive issues remain after that, escalate to the user rather than grinding a fourth cycle, and if the artifact is too large for the bound, decompose it into smaller reviewable units.