doubt-driven-development

Apply the doubt cycle: write a compact CLAIM, extract the smallest reviewable artifact plus its contract, and spawn a fresh-context reviewer with an adversarial prompt that finds issues rather than validating. 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 non-trivial decision while changes are still cheap, whereas /review is a post-hoc verdict on a finished artifact such as a 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. It applies only to non-trivial decisions.

Yes, in interactive sessions the Skill always offers cross-model review. It verifies the CLI exists and works, writes the prompt to a file piped via stdin to avoid shell injection, uses a read-only sandbox, and requires explicit user authorization for each invocation.

Passing the CLAIM or your conclusions biases the reviewer toward agreement. The reviewer receives only the artifact and the contract so it independently determines whether the artifact satisfies the contract, producing genuine disproof rather than validation.

A fresh reviewer lacks session context and can produce false flags, so findings must be reconciled against the artifact text rather than rubber-stamped. The loop is bounded at three cycles, and it cannot run nested inside a subagent persona without degraded self-questioning.