doubt-driven-development

Use the doubt cycle: state the decision as a compact CLAIM, extract the smallest reviewable artifact plus its contract, and pass only those to a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding as contract misread, actionable, trade-off, or noise before acting.

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 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 piping the artifact, contract, and adversarial prompt via stdin to a verified CLI in read-only sandbox mode. 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 receives only the artifact and contract so it independently determines whether the artifact satisfies the contract.

Stop when findings become trivial, after three cycles, or when the user says ship it. If three cycles still surface substantive issues, escalate to the user or decompose the artifact rather than looping further.