review

name	review
description	Read a piece of writing phrase by phrase for how it could be misread — connotation, ambiguity, double meaning, unintended implicature — against a stated goal and audience, and report the misreadings with suggested rewrites. Use when the user says "check this email/message/copy", "how will this read", "review the wording/tone", "could this be taken the wrong way", "is this clear", "read this before I send it", or pastes a draft and asks whether it lands. Read-only — it never edits the text; use /subtext:fix to apply rewrites.
allowed-tools	Read, Task
disable-model-invocation	false
user-invocable	true
model	opus
effort	high

subtext — phrase-level misreading review

Read a piece of writing the way a second reader with no attachment to it would: every phrase, asking "how else could this be taken?" Report the readings that would land wrong for the intended audience, each with a fix. Never edit the text here — this skill only reports. (Applying rewrites is /subtext:fix.)

The one law

Every finding names a concrete misreading, or it is dropped. "A reader could take this as X" is a finding. "This could be clearer" is noise — and noise is what gets a review tool uninstalled. If you cannot state the specific wrong meaning a real member of the audience would take, do not report it.

Step 1 — Get the framing (goal, audience, stakes)

You cannot judge a phrase without knowing what the text is for. Establish three things:

• Goal — what the text should accomplish (persuade, inform, apologize, decline, confirm).
• Audience — who reads it and in what frame of mind (a customer, a hiring manager, the public internet, a grieving colleague, a skeptical exec).
• Stakes — how costly a misreading is. This sets the severity bar (Step 4). A tweet and a legal notice do not get the same threshold.

If the user stated these, use them. If not, infer them from the text and context, state your inference in one line, and proceed — do not interrogate. Ask only when the inference is genuinely ambiguous and the analysis would change depending on the answer (e.g. you can't tell if a blunt message is meant for a close teammate or a new client).

The fixture corpus carries the framing as leading HTML comments (goal: / audience: / stakes:); read them if present.

Echo the framing back as the first line of your report so a wrong inference is immediately visible and correctable.

Step 2 — FIND (coverage first)

Sweep the text phrase by phrase through all seven lenses. The lens catalog — what each catches, the tell, examples — is in .agents/reference/lenses.md; read it. The seven:

1. Connotation — loaded, euphemistic, or register-mismatched word choice.
2. Lexical ambiguity — a word with a second common sense.
3. Syntactic ambiguity — a second grammatical parse (attachment, scope, coordination).
4. Double meanings — idioms, innuendo, unintended puns, homophones, name collisions.
5. Implicature — what the phrase implies beyond its literal content (hedges, agentless passives, presupposition triggers like "still" / "already").
6. Audience-shifted readings — how it lands for a non-native, cross-cultural, hostile, or skimming reader.
7. Goal alignment — one whole-text pass: does the cumulative tone and emphasis serve the goal, even when no single phrase is wrong?

Maximize recall here. Report every candidate misreading, including ones you are unsure about — a separate verify step (Step 3) filters. Do not self-censor at this stage; under-reporting now is not recoverable later. For each candidate, record: the exact quoted phrase (with enough surrounding text to locate it), the lens, the misreading scenario in one sentence, and a severity guess.

Still apply the one law even while maximizing recall: a candidate must have a nameable wrong meaning. "Awkward phrasing" with no misreading is not a candidate.

Step 3 — VERIFY (adversarial, fresh context)

A model that just flagged a phrase will defend the flag. So hand each candidate to a reader that has not seen your reasoning: spawn the misread-verifier agent (via the Task tool) and ask it to refute the finding — "would a reasonable member of THIS audience actually read it that way?"

• Fan out: one verifier call per finding (or a small batch), run in parallel, so verification doesn't serialize.
• Give the verifier only what it needs: the full text (for context), the quoted phrase, the goal/audience/stakes, and the claimed misreading. Do not give it your severity guess or your reasoning — it judges fresh.
• Keep a finding only if the verifier agrees the misreading is one the stated audience would plausibly take. Drop the ones that survive only as theoretical pedantry. The verifier may also adjust severity.

If spawning a sub-agent isn't available in the current surface, run the refutation inline as a distinct, deliberately adversarial pass — re-read each finding cold and ask whether the audience would truly take the wrong meaning, or whether only a pedant would. The separation of jobs is what matters; the sub-agent is how we keep the context fresh.

Step 4 — REPORT

The exact output shape is frozen in docs/contracts/review-report-v1.md. Follow it. In short:

1. Framing line — the goal / audience / stakes you analyzed against.
2. Findings, ranked by severity (high → low). Each: the quoted phrase and where it is, the lens, the misreading in one sentence, and one or two suggested rewrites that remove the misreading without changing the meaning or flattening the voice.
3. Whole-text verdict — two or three sentences on cumulative tone and goal fit.

Severity bar, scaled by stakes:

• high stakes (legal, public, a bereavement, an irreversible send): report medium and high findings; mention high-value low findings.
• medium stakes (most work email, marketing copy): report high and the clearest medium findings.
• low stakes (a casual note, an internal changelog): report high findings only; stay quiet otherwise.

Cap low-severity findings at ~5. A wall of nitpicks is how the tool gets ignored. If there are more, report the top few and say how many you held back.

A clean bill of health is a valid, first-class result. If the text holds up for its goal and audience, say so plainly in one or two sentences and stop. Do not manufacture findings to look useful — that is measured directly as a false positive against the clean corpus, and it is the fastest way to lose the user's trust.

Scope controls (cost and latency)

• On a long document, review in sections and report per section; don't hold the whole thing in one pass if it strains attention.
• On a repeat run of a text the user is iterating on, review only the changed paragraphs unless asked for a full re-read — re-flagging unchanged, already-seen phrases is noise.
• The verifier fan-out is the main cost. For low-stakes text, a single inline adversarial pass is a reasonable substitute for per-finding sub-agent calls.

Self-review blind spot

If you drafted the text earlier in this same conversation, you share the author's context and will under-flag. Say so, and lean harder on the fresh-context verifier — or run the whole find step as a sub-agent too, so it reads the text cold.