doubt-driven-development

Name the decision as a compact CLAIM, extract the smallest reviewable artifact plus its contract, and spawn a fresh-context reviewer with an adversarial prompt that asks it to find issues rather than validate. Classify each finding against the artifact text, then stop after trivial findings, three cycles, or user override.

Doubt-driven development is an in-flight posture applied per decision while changes are still cheap to reverse, whereas a code review 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.

No, it is designed for the main-session orchestrator because spawning a fresh-context reviewer from a persona would create nested subagents, which platforms like Claude Code forbid. A degraded self-questioning fallback exists but must be flagged as degraded and escalated when possible.

In interactive sessions the agent must always offer a cross-model review after the single-model pass. If accepted, it verifies the CLI exists and runs, writes the prompt to a file, pipes it via stdin with a read-only sandbox, and never invokes the CLI without explicit per-call user authorization.

Passing the original claim or the author's reasoning biases the reviewer toward agreement. Supplying only the artifact and contract forces the reviewer to independently determine whether the artifact satisfies the contract, which is the point of fresh-context review.