doubt-driven-development

Name: doubt-driven-development
Availability: InStock
Author: Boris

Runs adversarial fresh-context reviews of non-trivial outputs using doubt cycle CLAIM-EXTRACT-DOUBT-RECONCILE-STOP.

1|1|Updated Apr 11, 2026

Search Tags:#safety #review #code-review #decision-making #adversarial #doubt-driven

Ready to run

npx skills add https://github.com/Borisserz/FoodTracker --skill doubt-driven-development-borisserz

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/Borisserz/FoodTracker/tree/main/.agents/skills/skills/doubt-driven-development
Command: npx skills add https://github.com/Borisserz/FoodTracker --skill doubt-driven-development-borisserz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to disprove, not approve — before any non-trivial output stands.

Core Features & Use Cases

Fresh-context reviewer that challenges assumptions and surfaces blind spots.
Adversarial prompts and artifact-contract framing to test robustness.
A formal doubt cycle (CLAIM, EXTRACT, DOUBT, RECONCILE, STOP) to maintain auditable decisions.
When to use: for architectural decisions, production changes, security-sensitive logic, or any high-stakes code or data work.

Quick Start

Provide an artifact and a contract, and run an adversarial review to surface unstated assumptions and edge cases before proceeding.

Frequently Asked Questions about doubt-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

What is adversarial code review and how does it surface blind spots in architectural decisions?▼

Adversarial code review introduces a fresh-context reviewer biased toward disproof rather than approval. It challenges accumulated assumptions during high-stakes architectural decisions by materializing a reviewer focused on disproving outputs before they proceed to production.

How do I run an adversarial review for security-sensitive production changes?▼

Provide an artifact and a contract, then execute the structured doubt cycle: CLAIM, EXTRACT, DOUBT, RECONCILE, STOP. This formal process audits security-sensitive production changes by forcing disproof of assumptions before allowing the output to stand.

Can I use doubt-driven development for data workflows or is it limited to software engineering?▼

Doubt-driven development applies across both software and data workflows. It is designed for any non-trivial, high-stakes output where context is partial, enabling rigorous adversarial examination of decisions regardless of the specific engineering domain.

What's the difference between standard code review and a fresh-context adversarial review?▼

Standard code review typically seeks approval, while adversarial review uses a fresh-context reviewer explicitly biased to disprove. The structured doubt cycle maintains auditable decisions by testing robustness through adversarial prompts rather than validating existing assumptions.

When should I not use adversarial review for my code or data outputs?▼

Adversarial review targets non-trivial, high-stakes outputs like architectural decisions and security-sensitive logic. For routine or low-stakes changes where context is complete and consequences are minimal, the rigorous doubt cycle may introduce unnecessary overhead.

Does doubt-driven development support cross-model opinions to broaden code review coverage?▼

Yes, doubt-driven development supports optional cross-model opinions to broaden review coverage. This expands the adversarial examination by introducing diverse fresh-context perspectives to disprove assumptions in architectural and security-sensitive decisions.