Loop 024
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.
Ready-to-use prompt
Copy the loop
Argue against your own design until it survives. In each round, a critic sub-agent writes the strongest case that the current approach is wrong and records every objection in /tmp/redteam-{projectname}.md with its evidence, impact, and status. The builder must either fix the weakness and verify the result or record why accepting it is reasonable under the project's stated criteria. The critic then reviews the change or acceptance rationale and may reopen anything that is not supported. Repeat until no new high-impact objection appears and every logged objection is either verified as resolved or explicitly accepted with evidence. Merely answering an objection in the log does not resolve it. If the same unresolved objections repeat for two rounds without new evidence or progress, stop and report the stalemate instead of claiming the design survived.
Verify / stop
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.
Context and guidance When to use it, steps, safety notes, and related loops
Use this when
Use this before committing to an architecture, interface, rollout plan, or other consequential design that benefits from structured adversarial review.
How to run it
- Write the design goals and acceptance criteria, then initialize the objection log at /tmp/redteam-{projectname}.md.
- 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.
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.
Implementation note
Give the critic and builder separate context where possible. Do not let the builder rewrite the acceptance criteria mid-run simply to close a difficult objection.