doubt-driven-development

Use the doubt cycle: state the claim, extract the smallest reviewable artifact plus its contract, and spawn a fresh-context reviewer with an adversarial prompt that finds issues rather than validates. Classify each finding against the artifact text, then iterate up to three cycles.

Doubt-driven development is an in-flight posture that cross-examines individual non-trivial decisions while course-correction is cheap. A code review is a post-hoc verdict on a finished artifact such as a pull request. The two are complementary and can be used together.

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. It applies only to non-trivial decisions.

Yes, cross-model escalation pipes the artifact and contract to external CLIs like Gemini or Codex in read-only sandbox mode. Each invocation requires explicit user authorization, a PATH check, and stdin piping to avoid shell injection from artifact content.

Passing your claim or reasoning biases the reviewer toward agreement with your conclusions. The reviewer must independently determine whether the artifact satisfies the contract, so only those two inputs are provided.

A fresh reviewer lacks session context and can produce false positives classified as noise or contract misreads. It also cannot run nested inside a subagent persona, where only a degraded self-questioning fallback is available.