doubt-driven-development

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

Updated Jul 10, 2026
One-click install
npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill doubt-driven-development-codecrafteradi2006
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/CodeCrafterAdi2006/Ink-and-Code/tree/main/Skills/doubt-driven-development
Command: npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill doubt-driven-development-codecrafteradi2006

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 — branching logic, cross-boundary changes, unverifiable invariants, irreversible operations — 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 its contract, DOUBT it with a fresh-context adversarial reviewer, RECONCILE findings by precedence (contract misread, actionable, trade-off, noise), 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: In interactive sessions it always offers a second opinion via external CLIs (Gemini, Codex) with read-only sandboxing, stdin piping to avoid shell injection, and explicit per-invocation user authorization. - Use Case: Before committing a new caching layer claimed to be thread-safe, extract the diff and its concurrency contract, spawn a fresh-context reviewer to hunt for races and unstated assumptions, then classify and act on the findings before merging. ## Quick Start Ask the agent to apply doubt-driven development to review the thread-safety claim of the new caching layer before committing it.

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 non-trivial code decision before committing it?▼

Name the decision as 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, then stop after trivial findings or three cycles.

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 use adversarial self-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 doubt-driven development run inside a subagent or persona?▼

No, it is designed for the main-session orchestrator because spawning a reviewer from inside a persona creates nested orchestration, which is forbidden. In subagent contexts it should escalate to the main session or use a flagged degraded self-questioning fallback.

How do I safely get a cross-model second opinion from an external CLI?▼

Verify the tool is in PATH and runs, confirm the exact invocation with the user, write the prompt to a file and pipe it via stdin to avoid shell injection, and use a read-only sandbox so embedded instructions in the artifact cannot execute against your workspace.

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

Handing the reviewer your conclusion biases it toward agreement and validation. Passing only the artifact and contract forces the reviewer to independently determine whether the artifact satisfies the contract.