The devil's-advocate loop

A critic-and-builder workflow that attacks a design, tracks every objection, and requires evidence before an objection can be closed.

Use when

Use this before committing to an architecture, interface, rollout plan, or other consequential design that benefits from structured adversarial review.

The loop

Before committing to an architecture, interface, or rollout plan, have a critic argue that it is wrong. Record each objection, impact, and status in a repository-local log at .agent-reviews/redteam.md. The builder must fix and verify each high-impact weakness or document why it is accepted; the critic may reopen unsupported answers. Stop when no high-impact objection remains or the same issues repeat for two rounds without new evidence. Finish with the decision, resolved and accepted objections, evidence, and any stalemate.

Steps

• Write the design goals and acceptance criteria, then initialize .agent-reviews/redteam.md inside the repository and keep it out of commits.
• Have the critic present the strongest evidence-backed case against the current design and rank each objection by impact.
• Have the builder repair the weakness or document an explicit acceptance rationale, then verify the result against the stated criteria.
• Let the critic reopen weak answers and repeat until the objections are closed with evidence or the loop reports a stalemate honestly.

Verification

No high-impact objection remains open. Every logged objection is verified as resolved or explicitly accepted with evidence, or the final report truthfully records a two-round stalemate.

Why it works

Separating critic and builder roles makes disagreement explicit. A persistent objection log prevents circular debate, while evidence-based closure stops the builder from declaring success by explanation alone.