When to use it

You have a draft ready: a reply to an unhappy client, a quote, a document that will circulate inside the company. It reads well, you go over it and it convinces you. That is exactly the risky moment: whoever wrote a text reads it already knowing what they meant, and skips over the holes. The adversarial reviewer belongs here, before you send, when a mistake costs you face and not just an edit.

It matters twice as much when the assistant wrote the draft. Generated text sounds confident even when it has skipped a request or promised something you cannot deliver. A confident tone tells you nothing about how solid the content is.

What you need

Any AI assistant (Claude, ChatGPT, Gemini: the method is identical), the draft to check, and the material it came from: the original request, the data, the context. A reviewer without the source material only checks the form. With the material it also checks whether you kept your promises and answered everything.

To try the playbook dry, the course has a set of sample emails from a web studio (in Italian, which makes them a realistic multilingual exercise): write a reply to one of them and run it through the reviewer.

The steps

1 · Keep writing and reviewing apart. Do not ask the same assistant, in the same reply, to write and then criticise: it will tend to defend what it just produced. Open a fresh conversation, or at least assign a different role explicitly. It is the same principle as prompt chaining: one step produces, the next works on the first step’s output.

2 · Give the reviewer a hostile brief and a minimum threshold. The most common failure is the polite reviewer, the one that answers “looks fine to me”. You cure it by asking for a minimum number of problems, or an explicit statement that there are none:

Act as the adversarial reviewer of this draft. Your job is not to approve it: it is to find what is wrong before the recipient does.

Check, in this order:
1. PROMISES: does the draft promise dates, figures, actions? Is each one verifiable, or vague ("soon", "as soon as possible")?
2. REQUESTS COVERED: compare against the source material. Is there any question or request the draft does not answer?
3. UNVERIFIED CLAIMS: does it state statuses or facts ("it's already in progress", "we checked") that might not be true?
4. TONE: is it right for the recipient and the situation? Too defensive, too cold, too familiar?
5. ERRORS: typos, grammar, wrong names.

Find AT LEAST 3 problems. If after an honest check you find fewer, say so and explain why the draft holds up. For each problem: what is wrong, why it is a risk, how to fix it.

SOURCE MATERIAL:
[paste the original request, the data, the context]

DRAFT TO CHECK:
[paste your draft]

3 · You decide which findings to accept. The reviewer finds, you choose. Some findings will be right, others not: maybe the “too familiar” tone was deliberate because you are on first-name terms with that client. Fix the real ones, drop the ones that come from the reviewer not knowing the relationship. The final call stays yours.

4 · Rewrite and, if the stakes are high, pass once more. Apply the fixes and, for an important document, send the new version back to the reviewer one last time. A single extra round is almost always enough: beyond that, the reviewer starts inventing problems to justify its presence.

A full example

Fabio from Cantine Valtellina writes twice in one hour (emails 4 and 10): he chases the product-page changes he asked for two weeks ago, says he is embarrassed in front of his management, and in a second message adds “the new logo too, whenever you can”.

A plausible first draft: “Hi Fabio, you are right and we apologise for the delay. The changes to the product page are in progress and you will see them online soon. Thanks for your patience.”

The adversarial reviewer, with both emails in front of it, returns five findings: “soon” is a vague promise, and Fabio needs a date he can report to management; the draft ignores the second email, the new logo, as if it never arrived; “in progress” asserts a status you should verify before writing it, or it becomes a lie that gets found out; the text is only defensive, it gives Fabio nothing concrete to tell his superiors; and there is a wording slip. Four substantial problems and one of form, all real, all caught before sending. The rewrite puts in a real date, answers on the logo too, and replaces the apology with a plan.

Common mistakes

The reviewer that is too polite. Without the minimum threshold (“at least 3 problems”) the assistant approves to please you. The threshold forces it to actually look, and the escape clause (“if you find fewer, explain why it holds up”) stops it inventing flaws to hit the number.

Reviewing without the source material. If you give only the draft, the reviewer checks the form and tells you it “reads well”. The real value, the skipped requests and the broken promises, only shows with the original request beside it.

Accepting every finding blindly. The reviewer does not know your history with that client. Some of its notes miss the target: step 3 exists for that, and the filter is you.

The team variant

When several people write things that go out in the company’s name, the step 2 prompt becomes a shared saved instruction (a Claude Project or a team GPT), with the checklist adapted to you: the five items plus the ones that usually burn you, like “did you quote the order number?” or “did you cc accounting?”. Whoever writes runs it themselves before sending, and quality stops depending on one person’s off day.

The skill “Critical review” packages this loop into an installable instruction, and the chapter “Trusting the right amount” explains when a second pass is worth it and when it is wasted time.