doubt-driven-development

Name the decision as a compact claim, extract the smallest reviewable artifact plus its contract, and pass both to a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding against the artifact text, then iterate up to three cycles.

Code review is a post-hoc verdict on a finished artifact like a pull request. Doubt-driven development is an in-flight posture that cross-examines individual non-trivial decisions while course-correction is still cheap, and 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. In interactive sessions the skill always offers cross-model escalation via external CLIs such as Gemini or Codex. The prompt is piped through stdin with a read-only sandbox, and each invocation requires explicit user authorization.

Passing your conclusion biases the reviewer toward agreement, defeating the purpose of fresh-context review. The reviewer receives only the artifact and contract so it independently determines whether the contract is satisfied.

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