Adversarial Review

Adversarial Review

Overview

Stress-test thinking before committing. Use separated perspectives first, then synthesize; do not collapse into a generic pros/cons list.

For implementation plans, code changes, tests, debugging hypotheses, or critique requests, prefer independent reviewer contexts and consensus-ranked findings. Consensus is useful only when independence is real.

Choose the Mode

Capability Check

Apply Proportionality first. For work warranting subagents, select the eligible reviewer roster using the Model Diversity Heuristic and available independent contexts. Record the roster and count (at most three for Rubber Duck), then derive the execution path below. Rubber Duck dispatch reuses that selection; excluded providers do not count.

For a substantive artifact, target three independent reviewer contexts whenever possible; see Proportionality below for when a smaller artifact does not warrant three. When eligible providers or independent contexts are insufficient, reduce the selected count and disclose the downgrade.

Proportionality. Three reviewers are for a substantive artifact — a plan, a design, a diff, a decision with real consequences. For a single function, a one-line question, or a change you could fully critique yourself in a couple of steps, run single-agent, say so, and skip the subagent overhead. Do not spawn reviewers whose combined cost exceeds the value of the critique.

Output length

Match length to the findings, not to the section list. Report every section the mode calls for, but collapse an empty one to a single line instead of padding it. Lead with the highest-priority finding. Do not restate the artifact back to the user, and do not repeat the same finding in full in both the consensus-ranked list and the recommended-changes list — cross-reference it.

Model Diversity Heuristic

The goal is three independent, high-effort reasoning contexts from OpenAI, Anthropic, and xAI. Select by provider, tier, and generation, never by version number. For xAI, choose the newest exposed frontier general-reasoning Grok model. Google and Gemini models are not eligible reviewer substitutes.

Never hardcode a model version — not in this file, and not in your selection reasoning. A concrete version is wrong the moment the runtime updates, and a stale allow-list silently degrades the review by excluding models that did not exist when it was written. Enumerate what the runtime actually exposes at request time, then rank it.

Selection rules:

1. Enumerate, then rank. Ask the runtime which models it exposes and group them by provider. Do not assume any particular provider or model exists. If the runtime exposes no model list or no provider metadata, tier selection is not possible — do not guess a lineup from memory. Say so, select the independent contexts available without claiming model control, and disclose model diversity not confirmed. Capability Check derives the execution path from the selected count.
2. Use the preferred provider trio. Assign one reviewer each from OpenAI, Anthropic, and xAI. Independence comes from different providers, not from three variants of one family. Do not fill a missing slot with Google or Gemini; reduce the reviewer count and disclose the downgrade.
3. Take each provider's frontier general-reasoning tier — the tier that provider positions for its hardest reasoning and agentic work — and the newest generation of that tier.
4. Exclude the small/fast tier. Skip anything the runtime labels or markets as mini, small, flash, lite, nano, turbo, instant, fast, cheap, or economical, and any model presented as the lightweight sibling of a larger one. Judge by the runtime's own tier description at request time, not by a remembered list of names — tier labels change.
5. Reasoning effort: xhigh for every reviewer. Request xhigh for each selected model even when it exposes a higher setting. If a model does not expose xhigh, or effort is not controllable, leave effort unset and disclose the limitation rather than silently choosing another level or implying that xhigh was set.
6. Code review: a code-specialized model may hold a reviewer slot only if it is that provider's frontier tier; otherwise keep general-reasoning models.
7. Never fabricate. If a provider, model, or effort level is not actually exposed, do not invent it and do not substitute a small-tier model to fill a slot. Run the reviewers you can, reduce the count, and disclose model diversity not confirmed.
8. Fewer than three providers is a downgrade to disclose, not a reason to lower the tier bar. Two frontier reviewers beat three where one is a small-tier stand-in.

Degeneration-of-Thought Safeguard

Do not let the same context that produced the artifact be the only critic. Prefer fresh reviewer contexts. If fresh contexts are unavailable, disclose single-context critique and lower confidence in the review.

Premortem Pass

Before listing findings, each Rubber Duck reviewer writes one failure narrative:

It is 18 months from now and this shipped system failed in the most damaging credible way. What happened, who was affected, what decision caused it, and which current assumption made it possible?

Use the failure narrative as input to the findings list. Trace each credible failure back to a specific current decision, assumption, missing test, missing control, or operational gap.

Review Constitution

Every Rubber Duck review checks these categories:

• correctness
• security
• reliability
• performance
• maintainability
• test coverage
• observability
• operational failure modes
• data integrity
• dependency and supply-chain risk

For UI work, also check accessibility, empty/loading/error states, and user trust. For AI-agent or LLM work, also check prompt injection, excessive agency, insecure output handling, sensitive information disclosure, and overreliance.

Adversarial Reviewer Lenses

Reviewer lenses should be distinct. Prefer three of:

• Security/abuse reviewer: attack surface, trust boundaries, authorization, injection, secrets, abuse paths.
• Correctness/data-integrity reviewer: edge cases, invalid input, state transitions, silent wrong results, data loss.
• Reliability/operations reviewer: retries, timeouts, partial failure, deploy/rollback, monitoring, incident response.
• Performance/scale reviewer: load cliffs, concurrency, memory growth, resource leaks, N+1 work, throttling.
• Future maintainer reviewer: confusing abstractions, undocumented invariants, brittle coupling, misleading names.
• Product/user-harm reviewer: confusing UX, broken promises, user trust, accessibility, privacy expectations.

Do not send identical persona instructions to all reviewers unless the user explicitly asks for repeated sampling.

SPAR Mode

1. State: Mode: SPAR.
2. Frame the core tension in one sentence.
3. Pick 3-5 roles with genuinely conflicting incentives.
4. If execution path is multi-model-subagents or parallel-subagents, dispatch one role per agent in parallel. Otherwise simulate roles sequentially and say so.
5. For each role, give the strongest objection, strongest support, hidden assumption, and failure mode.
6. Synthesize only after role perspectives.
7. End with the single most important open question. If decision-blocking information is genuinely missing, end with up to three such questions instead — but do not pad to more than one when one suffices.

Use sections: Conflict framing, Roles, Perspective [Role], Synthesis, Open question(s).

Rubber Duck Mode

1. State: Mode: Rubber Duck.
2. Choose the execution path from Capability Check.
3. For multi-model-subagents, launch the selected reviewer roster in parallel with its chosen models, effort settings, and distinct Adversarial Reviewer Lenses.
4. For parallel-subagents, launch the selected number of independent critique subagents in parallel without claiming distinct model coverage.
5. For single-subagent, launch one critique subagent and perform synthesis yourself; do not count the synthesizer as a second reviewer.
6. For single-agent, perform the critique yourself and disclose that no subagent was launched.
7. Each reviewer must receive the same critique target and must not see other reviewers' findings during the first pass.
8. Each reviewer runs the Premortem Pass, checks the Review Constitution, and returns findings in the Reviewer Output Schema.
9. Focus only on high-signal issues: correctness, security, reliability, missing tests, bad assumptions, and edge cases.
10. Separate accepted findings from rejected or unverified concerns.

Use sections: Critique target, Execution disclosure, Consensus-ranked findings, Single-reviewer findings worth considering, Recommended changes, Rejected or unverified concerns, Next action.

Reviewer Output Schema

Ask each reviewer to return findings in this shape:

- title:
  category:
  severity: critical | high | medium | low
  confidence: high | medium | low
  evidence:
  recommended_change:
  dedupe_key:

The dedupe_key should be a short normalized label for matching equivalent issues across reviewers, such as auth-cache-leakage, missing-timeout, or unchecked-null-input.

Each reviewer ends with:

Recommendation: <fix | investigate | ship-as-is> because <one-line reason naming the strongest finding>

Severity and Confidence Calibration

• critical: likely data loss, security breach, privilege escalation, irreversible user harm, or production outage.

• high: plausible major reliability, correctness, auth, privacy, or operational failure.

• medium: localized bug, missing test, maintainability risk, or performance issue with bounded impact.

• low: minor issue or speculative concern with limited impact.

• high confidence: directly evidenced by code, plan text, test output, or reproducible reasoning.

• medium confidence: plausible and specific, but not fully proven.

• low confidence: speculative, ambiguous, or dependent on unstated assumptions.

Single-reviewer critical or high findings with high-confidence evidence must stay visible even without consensus.

Evidence Standards

Every finding must cite specific evidence: file path and line, plan section, data flow, threat path, reproduction idea, or concrete assumption. Vague concerns are not actionable findings.

For security findings, include STRIDE category when applicable, affected entry point, trust boundary crossed, exploit path, impact, and mitigation.

Consensus Aggregation

After reviewers finish:

1. Normalize equivalent findings by dedupe_key, title, evidence, and recommended change.
2. Group matching findings across reviewers.
3. Rank grouped findings by number of independent reviewers that found the issue.
4. Break ties by severity, then confidence, then evidence quality.
5. Keep single-reviewer findings in a separate section when they are high severity, well-evidenced, or plausibly important.
6. Do not discard a serious issue only because one reviewer found it.
7. Do not inflate consensus by counting the main assistant's synthesis as an additional reviewer.
8. Treat contradictory findings as a signal. Preserve the disagreement and recommend how to resolve it.

For each consensus-ranked finding, show:

Priority:
Found by:
Severity:
Confidence:
Issue:
Evidence:
Recommended change:

Cross-Examination Round

After independent first-pass reviews, the synthesizer may show reviewers the other findings and ask:

What did they miss? Which of your original findings should change? Which disagreement is itself a risk?

Do not count this second round as new independent consensus. It is for refinement, conflict discovery, and missed-assumption detection only.

If all reviewers agree too neatly, run a groupthink check: ask one reviewer to identify what shared assumption could make all reviewers wrong.

Reviewer Failure Handling

If one or more reviewers fail:

• Continue with completed reviewers when at least one usable review exists.
• Disclose which reviewer failed and whether its model was requested.
• Rank consensus by completed reviewer count, not the original target of three.
• Do not invent missing reviewer findings.
• If no reviewer returns usable findings, fall back to single-agent critique and disclose the fallback.

Judge/Synthesizer Rules

The final synthesizer is a judge, not a fourth reviewer. It deduplicates, evaluates evidence, preserves disagreements, ranks findings, and recommends action. It does not add consensus votes.

LOC is not a proxy for risk. A tiny auth, permissions, data deletion, billing, or security-boundary change can require full adversarial review.

Always Disclose

Before the substantive answer, state:

• selected mode
• execution path
• subagents actually launched, including agent/tool names when available
• model and reasoning-effort requested for each subagent, or model not changed / model diversity not confirmed
• whether three independent reviewer contexts were achieved
• whether consensus ranking was performed

Never pretend agents were launched or models were changed. Say an agent was launched only if you personally invoked a tool for it in this conversation and can name the tool or agent. Say a model changed only if the runtime confirmed it or the subagent tool accepted a concrete model override. Otherwise say model not changed; retain the actual execution path and launched count.

Portability Fallbacks

• No slash commands: invoke by name, e.g. "Use adversarial-review on..."
• Unknown CLI or no skill loader: paste or include this SKILL.md at conversation start and say, "Use the adversarial-review skill from this file on my next request."
• Skill not loading: if the assistant does not mention adversarial-review or choose SPAR/Rubber Duck mode, assume the file was not loaded.
• No model override: run three independent subagents if possible and disclose model diversity not confirmed; never substitute a small-tier model to fill a slot.
• No three-subagent support: run the available critique subagent count and disclose the downgrade.
• No rubber-duck agent: use generic critique subagents.
• No subagents: simulate separated perspectives sequentially and disclose that limitation.

Common Mistakes

Example

User: "Use adversarial-review on this plan: cache all GET responses in memory for 10 minutes."

Expected shape: choose Rubber Duck mode; disclose whether three model-diverse subagents were launched; collect independent findings; normalize equivalent issues; rank by consensus.

Example consensus:

• Reviewer A found issues 1, 2, and 3.
• Reviewer B found issues 2, 3, and 4.
• Reviewer C found issues 1 and 2.

Final ranking:

1. Issue 2: found by 3 reviewers.
2. Issues 1 and 3: found by 2 reviewers.
3. Issue 4: found by 1 reviewer, retained only if severity/evidence justifies it.

For the cache example, likely high-priority findings include auth leakage from shared cache keys, invalidation gaps, per-user/per-permission cache keys, stale reads, memory growth, missing observability, and missing tests for authorization boundaries.

Disclosure example:

Mode: Rubber Duck
Execution path: multi-model-subagents
Subagents launched: three critique agents
Models: provider-family diversity requested; exact model versions not hard-coded
Three independent reviewer contexts: achieved
Consensus ranking: performed