Adversarial Review

Orchestrate a multi-model panel of adversarial reviewers — each powered by a different AI model, each assigned a distinct attack vector. The goal is not balanced feedback: it is to surface every weakness, assumption gap, edge case, and failure mode before they reach production.

Skill workflow: pre-mortem (stress-test before building) → adversarial-review (tear apart what was built) → adr (record decisions that emerged from the review)

Step 1: Assess complexity

Before launching reviewers, assess what is being reviewed. Size up the blast radius of a mistake — how bad would it be if there is a subtle flaw here?

🟢 Simple — A small, isolated change: a single-function fix, a one-line config change, a trivial renaming, a minor doc correction. → Push back gently. Tell the user: "This looks pretty straightforward — a full adversarial panel might be more than you need here. Want me to proceed anyway, or would a quick inline review do the job?" Wait for their answer before continuing.

🟡 Medium — A self-contained feature: a new endpoint, a module-level refactor, a small architectural decision, a PR with 3–10 file changes, a design doc scoped to one component. → Launch 1–2 reviewers. Default to 1 if the scope is truly narrow and well-contained. Escalate to 2 if there are non-trivial architectural dimensions or the failure mode of getting this wrong is costly.