doubt-driven-development

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

Updated Mar 14, 2026
One-click install
npx skills add https://github.com/yourlabpt/yourlabpt_website --skill doubt-driven-development-yourlabpt
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/yourlabpt/yourlabpt_website/tree/main/projects/skills/doubt-driven-development
Command: npx skills add https://github.com/yourlabpt/yourlabpt_website --skill doubt-driven-development-yourlabpt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Long 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 - 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). - Cross-model escalation: In interactive sessions it always offers a second opinion via external CLIs like Gemini or Codex, with read-only sandboxing and stdin piping to avoid shell injection. - Use Case: Before committing a new caching layer claimed to be thread-safe, extract the diff and its contract, hand them to an adversarial reviewer, classify each finding as contract misread, actionable, trade-off, or noise, and iterate until findings are trivial. ## 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?▼

Name the decision as a compact claim, extract the smallest reviewable artifact plus its contract, and hand both to a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding against the artifact text, then iterate up to three cycles or until findings are trivial.

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

A 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, 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 doubt-driven development run inside a subagent or persona?▼

No, it is designed for the main-session orchestrator because spawning a reviewer from a persona violates the no-nested-personas rule. Inside a subagent it can only run a degraded self-questioning fallback, and the result should be flagged as such.

How does cross-model review work with Gemini or Codex CLI?▼

In interactive sessions the agent always offers a cross-model second opinion, verifies the CLI exists and works, confirms the exact invocation with the user, and pipes the prompt via stdin with a read-only sandbox. In non-interactive contexts cross-model is skipped and the skip is announced.