Neura Market
prompt logo

prompt

Free

Bias toward disproof. Question every non-trivial decision.

FreeFree tier
Inputs: textOutputs: text
Type
Open Source
Visit Website GitHub (40 stars)

About prompt

Doubt-Driven Development Architect is a structured AI prompt designed to act as an adversarial reviewer for non-trivial software decisions. It follows the principle that a confident answer is not necessarily a correct one, and biases toward disproof rather than approval. The prompt defines clear criteria for identifying non-trivial decisions (e.g., branching logic, cross-service boundaries, irreversible changes) and provides a five-step 'Doubt Cycle' (Claim, Extract, Doubt, Reconcile, Stop) to systematically challenge assumptions while keeping course correction cheap. It explicitly excludes mechanical tasks and situations where speed is prioritized over verification, ensuring focused application on high-impact choices.

Key Features

Adversarial review methodology for in-flight decisions
Defines non-trivial decision criteria (branching, boundaries, unverifiable properties, irreversible changes)
Five-step Doubt Cycle: Claim, Extract, Doubt, Reconcile, Stop
Fresh-context reviewer to break assumptions before commitment
Explicit stop conditions to avoid over-analysis
Designed for architectural and code-level decisions

Pros & Cons

Pros
  • Systematically reduces assumptions and context-blindness
  • Catches errors early, before irreversible actions like deploy or API change
  • Provides repeatable, structured process for decision validation
  • Includes explicit stop conditions to prevent analysis paralysis
Cons
  • Only applicable to non-trivial decisions; not helpful for routine tasks
  • Relies on the user correctly identifying when doubt should be applied
  • May slow down workflow if applied too often
  • Effectiveness depends on the user's ability to articulate clear claims

Best For

Reviewing architectural decisions under uncertaintyChecking non-trivial code before commitVerifying non-obvious claims about safety, scalability, or specification complianceWorking in unfamiliar codebasesAssessing thread safety, idempotence, ordering, or invariants

FAQ

When should I apply doubt?
Apply doubt when a decision is non-trivial: it introduces or modifies branching logic, crosses module or service boundaries, asserts a property the type system cannot verify, depends on invisible context, or has irreversible blast radius (production deploy, data migration, public API change). Do not apply doubt to mechanical operations, clear instructions, reading code, one-line obvious changes, or when speed is explicitly requested.
What is the Doubt Cycle?
The Doubt Cycle consists of five steps: Step 1 (CLAIM): State the decision and why it matters. Step 2 (EXTRACT): Isolate the artifact and contract, stripping reasoning. Step 3 (DOUBT): Invoke a fresh-context reviewer with an adversarial prompt. Step 4 (RECONCILE): Classify every finding against the artifact text. Step 5 (STOP): Halt when findings are trivial, after three cycles, or on user override.
How does this differ from a code review?
Unlike final review of finished artifacts, this approach cross-examines in-flight decisions while course-correction is still cheap. It biases toward disproof, not approval, and materializes a fresh-context reviewer to break silent assumptions before commitment.