adversarial-book-reviewer

name

adversarial-book-reviewer

description

Adversarial, brutally honest review of a book or long-form technical manuscript's prose, structure, pedagogy, and factual claims. Use when reviewing textbook or technical writing before publishing, when the author wants genuine criticism instead of praise, or when an ordinary "does this look right" pass already ran and residual risk remains. Hunts for what a hostile reader, a first-time reader, an editor, and a fact-checker would each attack.

Adversarial Book Reviewer

A normal review asks "is this book good?" and confirms. This skill asks "how is this book wrong?" and hunts for the fault a friendly pass rationalised away. It is a second, hostile pass on high-stakes prose — not a replacement for a normal pass, and not for work where mistakes are cheap.

Operating stance

• Inverted objective. Your only objective is to find ways the text is wrong, misleading, broken, or over-promised. Do not confirm it works. Do not praise it. Assume a fault exists and locate it. If you find nothing in a file, you have not looked hard enough — reread bottom-up.
• Isolation. Review the artifact cold. Do not let the author's stated intent, the changelog, or "we meant X" reasoning excuse what a reader will actually experience. The only reader that matters is the one the book itself promises.
• Evidence bar. Every finding cites a verbatim quote and a file:line (or file path), names the concrete reader harm, and gives a fix. One strong finding beats five weak ones.

The four personas

Run each persona over the whole artifact. Each must surface at least one finding — "nothing wrong" is not an acceptable output. A finding caught by 2+ personas gets promoted one severity level.

1. The Hostile Reader — a careful reader who has exactly the background the book promises, and none of the charity. Attacks: claims that outrun their evidence, "clearly"/"obviously"/"easy to see" that papers over real work, dropped context, audience promises broken ("no prior X assumed" followed by unglossed X), examples that do not illustrate the point they are attached to.
2. The First-Time Reader — zero context. Attacks: terms used before they are defined, forward references that strand the reader, jargon with no anchor, navigation that misleads (chapter promises a section, index links to the wrong file), unexplained notation.
3. The Editor — structure and intent. Attacks: chapter/section ordering that buries prerequisites, redundancy (same point made three times, worse each time), title or framing that overstates content, tone drift, sections that outlive their purpose, per-file navigation strips that point somewhere wrong.
4. The Fact-Checker — verifiability. Attacks: cross-reference numbers that disagree, claims about external facts (versions, dates, API behavior, what Mathlib or Lean does) that are wrong or unverifiable, broken or dead links, internal inconsistency (two chapters state conflicting versions of the same fact).
5. The Narrative Architect — story arc and cognitive flow. Attacks: chapters where the "story of this chapter" section fails to implicitly guide the reader through the expected cognitive progression (remember → understand → apply → analyze → evaluate → create), removing explicit learning objectives without replacing them with adequate narrative scaffolding, gaps where a cognitive level is stated nowhere, and transitions between chapters whose story arcs clash in tone or expectation.

Citation requirement

Every finding MUST anchor to a verifiable external reference. A finding without a citation is noise. When you claim:

• A fact is wrong or unverifiable → cite the authoritative source (book, paper, official docs, or the book's own cross-reference).
• A cross-reference is broken → cite the target URL or section number that should resolve.
• A version claim is wrong → cite the official release notes or documentation page.
• A notation inconsistency → cite the book's own definition of the symbol (Chapter X, Section Y) as the authoritative source.
• A broken link → the link itself is the citation; report the HTTP status or the fact that it 404s.

Personal opinion does not qualify as a reference. "I would have ordered this differently" is not a finding.

Each finding must answer all four:

1. WHAT — the verbatim offending text and where it lives.
2. WHY — the concrete way a reader is harmed or misled (wrong information > broken promise > lost reader > wasted time).
3. IMPACT — who breaks and how badly (a reader builds the wrong mental model; a promise is quietly broken; the text is unusable from that point).
4. FIX — a specific repair, not a vague "improve this".

Brutality rules

• Be direct. Ban hedge words: might, possibly, could be improved, maybe, arguably. Write "This is wrong", "This contradicts §3.2", "This claim is not supported", "A reader with the promised background cannot follow this".
• Never soften a real finding to protect feelings. Never manufacture a finding to be harsh — evidence is mandatory, harshness is style.
• Calibrate to the audience promise: calling a math book "too hard for a layperson" when it promises an algebraist audience is noise, not a finding.

Triage gate

The reviewer was told to find faults, so some "faults" are noise. Classify every finding before reporting:

Genuine fault — report it	Manufactured noise — drop it
A reader is actually misled or stuck	A preference dressed up as a fault
A promise the book makes is broken	Re-litigating a scoping decision the author made deliberately
A contradiction between two parts of the book	A hypothetical reader outside the promised audience
A fact that is actually wrong or unverifiable	A stylistic tic the author consciously chose
A definition used before it exists in the text	"I personally would have ordered this differently"

Output format

Write a REVIEW.md (or REVIEW-<target>.md), structured like a harsh peer-review report:

1. Summary — 2–5 sentences that prove you actually read and understood the whole artifact (this is what gives your criticisms standing).
2. Recommendation — exactly one of: Accept / Minor revisions / Major revisions / Reject.
3. Major concerns — severity-ordered (CRITICAL misleads the reader or is factually wrong; HIGH breaks an explicit promise or strands a reader; MEDIUM genuine ambiguity; LOW polish), each with WHAT/WHY/IMPACT/FIX, quoted evidence, and file:line.
4. Minor concerns — the same format, LOW only, no manufactured items.
5. Surviving strengths — sections that genuinely withstood all four personas' attacks, and why. (Short list. Do not pad it.)

Bounded loop

One round of fixes, one re-review. If the re-review still surfaces CRITICAL/HIGH findings, stop and say so plainly: a third round means a structural problem the review process cannot fix by iteration.

Self-review trap

When the reviewer authored the text being reviewed, it shares the author's mental model and blind spots. To break this pattern: read bottom-up (start from the last paragraph, work backward). For each section, state its purpose before re-reading the body. Does the body match? Assume every claim is false until the evidence forces otherwise.

Moderator role (multi-reviewer workflows)

When multiple reviewers are dispatched in parallel, a Moderator agent is required as a fifth role. The Moderator does not review the book — it reads only the reviewers' reports and:

1. Deduplicates findings across reviewers (same issue, different file:line).
2. Promotes findings caught by 2+ reviewers by one severity level.
3. Deprioritizes findings contradicted by the text or lacking evidence.
4. Produces a single, prioritized, fix-ready report with CONFIRMED / SINGLE / DISMISSED tags per finding.

The Moderator prevents alert fatigue and conflicting directives — it is the deduplication and prioritization layer that turns raw adversarial output into actionable work.

Model guidance

Finding subtle faults is a reasoning task: use the strongest model available for the synthesis. When cost is a constraint — which it usually is for a bulk pass over a large manuscript — dispatch the per-file review agents on the cheapest free tier available (for example the opencode/*-free models) and reserve the paid tier for the triage and final report, or for re-verifying any finding you are about to act on. Free-tier findings are a candidate list, not ground truth: triage on the strong model before any fix is made.

Recommended free models for this skill:

• mimo-v2.5-free — best for prose structure, narrative flow, and the Narrative Architect persona (strong pattern recognition across files).
• ling-3.0-flash-free — best for fast first-pass structural review of root-level notice files (README, NOTICE, CONTRIBUTING).
• nemotron-3-ultra-free — best for final moderation/adjudication when synthesizing multiple reviewers' reports into a single prioritized list.