doubt-driven-development

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

Doubt-driven development is an in-flight check on individual non-trivial decisions while changes are still cheap to reverse. A code review like /teikk-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, and pure tooling operations. The skill applies only to non-trivial decisions involving branching logic, cross-boundary changes, or irreversible blast radius.

No, it is designed for the main-session orchestrator because spawning a reviewer from a persona violates the depth-1 orchestration rule. In a subagent context, escalate to the main session, or use a degraded self-questioning fallback flagged as not fresh-context review.

After a single-model review, the agent offers to send the artifact to an external CLI like Gemini CLI or Codex CLI. It runs in a read-only sandbox with the prompt piped via stdin, requires explicit user authorization per invocation, and is skipped with an announcement in non-interactive contexts.

Passing your CLAIM or reasoning biases the reviewer toward agreeing with your conclusion. Supplying only the artifact and contract forces the reviewer to independently determine whether the artifact satisfies the contract, which is the point of fresh-context review.