doubt-driven-development

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

Review decisions for risky assumptions using adversarial fresh-context analysis.

Updated May 3, 2026

Search Tags:#software engineering #code review #decision making #risk analysis #adversarial review #fresh context

Ready to run

npx skills add https://github.com/kevindree/geehoo-gateway --skill doubt-driven-development-kevindree

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: doubt-driven-development
Source: https://github.com/kevindree/geehoo-gateway/tree/main/.github/skills/doubt-driven-development
Command: npx skills add https://github.com/kevindree/geehoo-gateway --skill doubt-driven-development-kevindree

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Doubt-Driven Development helps you avoid shipping confident but unverified decisions by forcing a fresh-context adversarial review before non-trivial choices stand.

Core Features & Use Cases

Adversarial review of decisions: Turns architectural choices, branching logic, and high-stakes claims into reviewable artifacts with explicit contracts.
Fresh-context challenge: Uses a separate reviewer mindset to look for unstated assumptions, edge cases, hidden coupling, and contract violations.
Bounded reconciliation: Classifies findings as actionable, trade-off, or noise so you can correct real issues without overreacting to false alarms.
Use case: Before merging unfamiliar code or approving a production-impacting change, apply the process to surface risks while correction is still cheap.

Quick Start

Apply doubt-driven development to the current decision by writing the claim, extracting the artifact and contract, and asking a fresh-context reviewer to find issues before you proceed.

Frequently Asked Questions about doubt-driven-development

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

FAQPage Schema

How do I catch bad assumptions in architectural choices before they ship?▼

To catch bad assumptions before they ship, apply an adversarial fresh-context review to extract the artifact and contract, then classify findings against the text to surface hidden risks. This forces a separate reviewer mindset to look for unstated edge cases and contract violations.

What is adversarial code review and how does it find risky assumptions?▼

Adversarial code review challenges non-trivial decisions by using a fresh-context reviewer mindset to find unstated assumptions, hidden coupling, and contract violations. It classifies findings as actionable, trade-off, or noise to correct real issues without overreacting.

When do I need a fresh-context review for unfamiliar code?▼

You need a fresh-context review for unfamiliar code when correctness matters more than speed, such as before merging cross-module changes or approving production-impacting decisions. It surfaces risky assumptions while correction is still cheap.

Can I use doubt-driven development for high-stakes claims and cross-module changes?▼

Yes, you can apply doubt-driven development to high-stakes claims and cross-module changes by turning them into reviewable artifacts with explicit contracts. A bounded reconciliation process then classifies findings to ensure you correct real issues without overreacting to false alarms.

How do I classify findings from an adversarial review without overreacting to false alarms?▼

You classify findings from an adversarial review through bounded reconciliation, sorting issues as actionable, trade-off, or noise against the artifact text. This explicit classification prevents overreacting to false alarms while correcting real contract violations.

What are the limitations of using an adversarial review process for code decisions?▼

The process is limited by its requirement for an explicit artifact and contract, making it unsuitable for trivial tasks where speed matters more than correctness. It also requires bounded iteration to prevent reconciliation from stalling development on noise.