doubt-driven-development

Use the doubt cycle: write a compact CLAIM, extract the smallest reviewable artifact plus its contract, and hand both to a fresh-context reviewer with an adversarial prompt that asks for issues only. Classify each finding against the artifact text, then iterate up to three cycles.

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 such as a pull request. The two are complementary and can both 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.

Yes, the skill supports cross-model escalation by writing the adversarial prompt, artifact, and contract to a file and piping it via stdin to the CLI in a read-only sandbox. Each invocation requires a PATH check, a working-binary test, and explicit user authorization.

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 bounded at three cycles, and large artifacts must be decomposed before review.