doubt-driven-development

Apply the doubt cycle: write a compact CLAIM, 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 decision while changes are still cheap, whereas code review is a post-hoc verdict on a finished artifact like 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.

Yes, after verifying the binary works, write the adversarial prompt plus artifact and contract to a file and pipe it via stdin using a read-only sandbox mode. Never interpolate artifacts into shell-quoted arguments, and always get explicit user authorization per invocation.

Passing your conclusion biases the reviewer toward agreement, defeating the purpose of fresh-context review. The reviewer must independently determine whether the artifact satisfies the contract, so only ARTIFACT and CONTRACT are passed.

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 also bounded at three cycles; larger artifacts must be decomposed first.