addy-doubt-driven-development

Use the doubt cycle: write a compact CLAIM, extract the smallest reviewable artifact plus its contract, then spawn a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding as contract misread, actionable, trade-off, or noise before reconciling.

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 be used together.

Skip it for mechanical operations like renaming or formatting, unambiguous user instructions, one-line changes with obvious correctness, reading or summarizing code, and pure tooling operations. It applies only to non-trivial decisions such as branching logic, cross-boundary changes, or irreversible operations.

Yes. In interactive sessions the skill always offers cross-model escalation via external CLIs such as Gemini or Codex, piping the prompt through stdin with a read-only sandbox. Each invocation requires explicit user authorization and is skipped with an announcement in non-interactive contexts.

Passing your CLAIM or reasoning 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 those two inputs are provided.

It cannot run nested inside a subagent context, where only a degraded self-questioning fallback is possible. The loop is bounded at three cycles, and a fresh reviewer lacking context can produce noise, so findings must be re-classified against the artifact text rather than rubber-stamped.