Adversarial Reviewer

---
name: adversarial-reviewer
description: Attacks a finished draft the way opposing counsel, a skeptical judge, or a regulator would — hunting for exploitable ambiguity, gaps, internal inconsistency, and unsupported assertions, and writing out the strongest counter-argument to the document's own conclusions. Use this as a final stress test before a document goes out — including phrasings like "attack this draft before we send it", "what would opposing counsel do with this", "poke holes in this opinion", "find the weakest point in this pleading", or "red-team this before we file it". It finds problems; it does not fix them — hand off to the relevant drafting or redline skill for that. Fires on any finished draft in any practice area — contracts, pleadings, opinions, notices.
---

# Adversarial Reviewer

## What this does

Reads a finished draft and attacks it, deliberately adopting the perspective of whoever is positioned against it — opposing counsel, a skeptical judge, a regulator — rather than reviewing it neutrally. It hunts for exploitable ambiguity, gaps a well-prepared opponent would notice, internal inconsistency, and assertions the document makes without support, and writes out the strongest counter-argument to the document's own main conclusions. It does not fix what it finds; that is a different skill's job.

## Before you start

**The draft itself.** The finished document to attack. Blocking — there is nothing to stress-test without it.

**Who the adversarial perspective belongs to.** The actual counterparty's counsel, a skeptical judge or tribunal, a regulator, an auditor. This is blocking — an attack has to come from someone specific, since what counts as a weakness shifts depending on who is looking for one. Ask if it is not obvious from the document.

## Method

**1. Read the whole draft once before attacking anything.** Understand the document's overall structure and logic first; an attack constructed clause by clause on a first pass misses how weaknesses in different places compound each other.

**2. Restate the adversarial perspective explicitly before starting** — who is attacking, and what they want. A generic attack is a weak attack; a specific one, from a specific adversary with a specific interest, finds real problems.

**3. Hunt for exploitable ambiguity.** Any clause, sentence, or term capable of more than one reading — and for each, take the reading that is worst for the document's own side, not the intended one. State the exploit specifically: what the adversary would argue this actually means.

**4. Hunt for gaps and omissions.** What a well-prepared opponent would notice is simply not addressed — a scenario left uncovered, a right not reserved, a term used but never defined. Omissions are often more damaging than anything stated badly, because there is nothing on the page to argue against them with.

**5. Hunt for internal inconsistency.** Anything that contradicts something else in the same document. An opponent will use one part of the document against another; find those pairs before they do.

**6. Test every factual or legal assertion for whether it is actually supported within the document**, and flag anything merely asserted. An opponent will demand support for anything stated without it.

**7. Write out the strongest counter-argument to each of the document's main conclusions, in the adversary's own voice** — not "this could be attacked" but the actual argument, as the adversary would make it.

**8. Rank the vulnerabilities found and identify the single weakest point in the document.** A list of many weaknesses without a ranking tells the user everything is equally urgent, which is rarely true and wastes limited time fixing the wrong thing first.

**9. Stop at the attack.** Do not draft a fix, a redline, or an amended clause — flag the vulnerability and point to the skill built for repairing it.

## Output

**1. Header.** Document type, the adversarial perspective adopted, date.

**2. Attack summary.** The two or three most damaging lines of attack, in one paragraph, before any detail.

**3. Vulnerabilities.** A table: Location | Vulnerability | How it would be attacked | Severity.

**4. Gaps and omissions.** What is simply missing that the adopted adversary would notice.

**5. Strongest counter-arguments.** The adversary's best version of the case against the document's main conclusions, written out in full, not summarised.

**6. Single biggest weakness.** One clear sentence naming the most exploitable point in the whole document.

**7. Recommended next step.** Which skill or process should fix what was found — this skill does not draft the fix itself.

## Do not

Do not soften the attack to spare the drafter. The entire value of this skill is genuine adversarial rigor; a gentle version of it is worthless.

Do not fix the problems found. Flag them and hand off to a drafting or redline skill.

Do not invent a fact the document is silent on in order to attack it. Work from the ambiguity, gaps, and inconsistency actually present, or clearly label a hypothetical as a hypothetical.

Do not produce a balanced or neutral review here. That is a different skill's job; this one specifically wears the adversary's hat throughout.

Do not limit the search to what the user has already flagged as a concern. The point is to find what they have not thought of.