doubt-driven-development

Use 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 asks it to find issues rather than validate. Classify each finding against the artifact text, then stop after trivial findings, three cycles, or user override.

Code review and PR review are post-hoc verdicts on a finished artifact, while doubt-driven development is an in-flight posture applied per decision while changes are still cheap. The two are complementary and meant to 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, or when the user explicitly prioritizes speed. It applies only to non-trivial decisions such as branching logic, cross-boundary changes, or irreversible operations.

No. Claude Code does not allow a subagent to spawn another subagent, so the DOUBT step only works from the main-session orchestrator. Inside a subagent, surface the limitation to the user or use a degraded self-questioning fallback flagged as not fresh-context.

Only with precautions: never interpolate the artifact into a shell-quoted argument, write the prompt to a file and pipe it via stdin, run the CLI in a read-only sandbox, and get explicit user authorization for every invocation. This prevents shell execution and prompt injection from the artifact.