doubt-driven-development

Use the doubt cycle: write a compact CLAIM naming the decision, extract the smallest reviewable artifact plus its contract, then invoke a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding against the artifact text and stop after trivial findings, three cycles, or user override.

Doubt-driven development is an in-flight posture applied per non-trivial decision while changes are still cheap, whereas a code review is a post-hoc verdict on a finished artifact or PR. 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.

Yes, the skill offers cross-model escalation through external CLIs such as Gemini or Codex in interactive sessions. Each invocation requires a PATH check, a working-binary test, user confirmation of the exact command, and a read-only sandbox with the prompt piped via stdin.

Passing your claim or reasoning biases the reviewer toward agreement with your conclusions. Supplying only the artifact and contract forces the reviewer to independently determine whether the artifact satisfies the contract.

A fresh reviewer lacks session context, so it can produce false flags that must be classified as noise during reconciliation. It also cannot run nested inside a subagent persona, where only a degraded self-questioning fallback is available.