doubt-driven-development

Apply the doubt cycle: write the claim compactly, extract the smallest reviewable artifact plus its contract, and invoke a fresh-context reviewer with an adversarial prompt that finds issues rather than validates. Classify each finding against the artifact text, then loop until findings are trivial or three cycles complete.

Doubt-driven development is an in-flight posture applied per decision while changes are still cheap to reverse, whereas code review is a post-hoc verdict on a finished artifact such as a pull request. The two are complementary and both should be used.

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. The skill targets only non-trivial decisions.

Yes, cross-model escalation routes the artifact and contract to an external CLI such as Gemini CLI or Codex CLI through stdin with a read-only sandbox. In interactive sessions the option is always offered, and each invocation requires explicit user authorization.

Passing the original claim or reasoning biases the reviewer toward agreement with the author's conclusions. Supplying only the artifact and contract forces the reviewer to independently determine whether the work satisfies its requirements.

The loop stops after three cycles and escalates to the user, since persistent substantive findings indicate the artifact may not be ready. If the artifact is too large for three cycles, it should be decomposed into smaller reviewable units instead of extending the loop.