doubt-driven-development

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

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/nntoan/ultra-omp --skill doubt-driven-development-nntoan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/nntoan/ultra-omp/tree/main/packages/proflow/skills/doubt-driven-development
Command: npx skills add https://github.com/nntoan/ultra-omp --skill doubt-driven-development-nntoan

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 directions in non-trivial decisions while course-correction is still cheap, instead of discovering them in production. ## Core Features & Use Cases - Five-step doubt cycle: CLAIM the decision, EXTRACT the smallest reviewable artifact plus contract, DOUBT it with a fresh-context 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: In interactive sessions, explicitly offers a second opinion via external CLIs such as Gemini or Codex with read-only sandboxing and per-invocation user authorization. - Use Case: Before committing a new caching layer claimed to be thread-safe, run the doubt cycle so an isolated reviewer hunts for race conditions, unstated assumptions, and contract violations before the code ships. ## 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 verify a code decision before committing it?▼

Use the doubt cycle: state the claim, extract the smallest reviewable artifact plus its contract, and have a fresh-context reviewer attack it with an issues-only 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?▼

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 apply adversarial review to my work?▼

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. In interactive sessions the skill always offers cross-model escalation through external CLIs such as Gemini or Codex, using read-only sandboxing and stdin piping. Each invocation requires explicit user authorization and is skipped with an announcement in non-interactive contexts.

Why does the reviewer only receive the artifact and contract?▼

Passing the author's claim or reasoning biases the reviewer toward agreement and validation. Providing only the artifact and contract forces the reviewer to independently determine whether the work satisfies its requirements.

What are the limitations of fresh-context review?▼

A fresh reviewer lacks session context and can produce false flags or noise, so findings must be re-classified against the artifact text rather than rubber-stamped. The loop is bounded at three cycles, after which unresolved issues are escalated to the user.