doubt-driven-development

Use the doubt cycle: write a compact CLAIM naming the decision, extract the smallest reviewable artifact plus its contract, and spawn 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 non-trivial decision while changes are still cheap to reverse. A code review or /review pass 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, the skill supports cross-model escalation through Gemini CLI or Codex CLI in a read-only sandbox. The agent must verify the binary works, confirm the exact invocation with you, pass only the artifact and contract via stdin, and obtain explicit authorization for each run.

Passing your claim or reasoning biases the reviewer toward agreeing with your conclusions. Supplying only the artifact and contract forces the reviewer to independently determine whether the work satisfies its requirements, which surfaces genuine blind spots.

At most three cycles. Stop earlier when findings become trivial or the user says ship it. If substantive issues remain after three cycles, escalate to the user or decompose the artifact rather than continuing to loop.