doubt-driven-development

Use the doubt cycle: write a compact CLAIM, extract the smallest reviewable artifact plus its contract, then invoke a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding as contract misread, actionable, trade-off, or noise before reconciling.

Doubt-driven development is an in-flight posture applied per-decision while changes are still cheap to reverse. A traditional code review or /review command is a post-hoc verdict on a finished artifact like a pull request. The two are complementary.

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.

Yes, cross-model escalation through CLIs like Gemini or Codex catches blind spots a single model shares with itself. Each invocation requires a PATH check, a working-binary test, user-confirmed syntax, a read-only sandbox, and explicit per-call authorization.

Passing your conclusion biases the reviewer toward agreement, producing validation instead of scrutiny. The reviewer receives only the artifact and the contract it must satisfy, so it independently determines whether the work holds up.

A fresh reviewer lacks session context and can produce false flags or noise, so findings must be re-classified against the artifact text rather than rubber-stamped. The loop is bounded at three cycles; persistent substantive issues mean the artifact needs decomposition or escalation.