Critic

---
name: critic
description: Critical editorial review of one post draft - a prose-quality critique as the reader content/VOICE.md describes (dead transitions, paragraphs that do not earn their place, ungrounded generalities, AI-tic sentences the writer rationalised, cuts the writer would not make) and a two-pass fact-check of every externally verifiable claim against primary sources, with a verdict, a confidence and an action per claim. Read-only on the draft. Use before a post ships, from write-post at its critique stage, or when asked to critique, fact-check or edit a draft hard.
argument-hint: <post slug or path under content/blog/>
---

# Critic

The repo is the current directory. The post is the one the user named
(`content/blog/<slug>.md`); if none, ask. One post per run. Read it as a
senior editor and fact-checker who did not see the conversation that
produced it: find what its writer rationalised away and what they
assumed was true. The review is worth most when that is literally true,
which is why `write-post` runs this procedure in isolation (below).

## Read first

In this order: `content/VOICE.md` in full (the reader you read as, the
rules, what is never claimed); `content/editorial/workshop.yaml` if it
exists and, when its `glossary` role names a file inside a workshop
present on disk, that file (the references the site allows); the draft.

Do not re-run the voice rules: `review-voice` covers the banned words,
the mark, the claim words and the structural fields. This pass is
editorial judgment and the external fact-check.

## Part 1 — prose quality

Read the draft as the reader `VOICE.md` § Who reads describes, with five
minutes of attention and no patience for marketing prose. Mark:

1. **Sentences that read as generated**: hedging chains, mechanical
   three-item rhythms, abstract value statements any vendor could sign,
   sentences whose specificity drops to zero in the second half.
2. **Transitions that add nothing** ("This is important because", "As we
   have seen", "Building on this"): if the paragraph loses nothing without
   it, cut it.
3. **Paragraphs that do not earn their place**: a restatement of the
   previous one; a concept introduced and dropped; "the product is good
   at X" with no concrete anchor.
4. **Ungrounded generalities** the reader would push back on ("many
   companies", "fast", "teams appreciate"): how many, how fast, which.
5. **Cuts the writer would not make**: the piece at its target length
   without losing the argument.

For each: the verbatim quote, the section (its heading), a one-line
reason, a rewrite or a cut shown with its surrounding context applied.

## Part 2 — the fact-check, two passes, primary sources

In scope: regulatory dates and effective dates; article, section and
annex numbers; named cases and rulings; named public bodies and what
they did; cited statistics; public technical facts; named standards and
their revisions. Out of scope: anything about the site's own product,
company or customers (the voice rules and the owner govern those), and
subjective characterisations (Part 1).

**Source tiers.** Tier 1: the regulator's or court's own site, the
official text (EUR-Lex for EU law, the standards body, the project's own
documentation, the publishing organisation's primary report). Tier 2:
reputable secondary sources with editorial standards (established trade
press, named legal commentary, peer-reviewed papers, public agencies'
briefings). Tier 3: aggregators, blogs, vendor pages, AI overviews:
navigation aids, never the basis of a verdict.

**Pass 1**, per claim: two distinct queries (one anchored to the primary
source, one to the topic); fetch the best primary source and read for
the exact value; fetch a corroborating source. Verdict: VERIFIED (a Tier
1 source confirms and a second source agrees), DISPUTED (sources
disagree on the value), FALSE (the primary source contradicts it),
UNVERIFIED (no Tier 1 source within budget). Budget: four tool calls.

**Pass 2**, on every claim that is not VERIFIED: diagnose why Pass 1
failed; two new query angles (the regulator's full name in lay words;
the official short title with the number as the regulator formats it;
the case with its court and year; the statistic with its publisher and
year); at least two new authoritative fetches. Pass 2 may upgrade,
downgrade (including a Pass 1 VERIFIED that a credible contradiction
undermines) or confirm. Budget: four more tool calls. Pass 2 is never
skipped.

**Confidence.** HIGH: a Tier 1 source explicit on the value plus a
corroborating source (VERIFIED only). MEDIUM: Tier 1 with interpretation,
or Tier 2 sources agreeing. LOW: Tier 2/3 only, or recent and
inconsistent sources; never VERIFIED. Be conservative on the verdict,
aggressive on the search: a false VERIFIED is a published error.

## Report

Exactly one report, no preamble, no closing commentary:

```
CRITIC REVIEW — <file> — <YYYY-MM-DD>

— SUMMARY —
Prose findings: <n>
Fact-check: <n> claims (<verified>/<disputed>/<false>/<unverified>); Pass 2 ran on <n>, changed <n>
Recommended cut: about <n> words

— PART 1: PROSE —
[P<n>] <section> <category>
Found: "<verbatim>"
Issue: <one line>
Fix:   "<rewrite>" | [CUT: <the context with the cut applied>]

— PART 2: FACTS —
[F<n>] <section>
Claim:   "<verbatim>"
Pass 1:  <verdict> via <URL> + <URL> | no Tier 1 source in budget
Pass 2:  not needed | queries: <q1> | <q2>; fetched: <URL> | <URL>; result: <upgraded/downgraded/confirmed>
Final:   <VERIFIED/DISPUTED/FALSE/UNVERIFIED>  Confidence: <HIGH/MEDIUM/LOW>  Action: <KEEP/REWORD/CITE/CUT>
Notes:   <what the primary source says, or what conflicts>

— PART 3: NOT VERIFIED (out of scope) —
<one line per factual claim left to the owner: the site's own product, customers, internals>
```

The review is read-only: no edits, no staged changes, no helper files.
If the file cannot be read, one failure line and stop.

## Then

Only with the user's approval, apply the chosen cuts and rewrites in the
file; a FALSE or UNVERIFIED claim is rewritten or removed, never kept on
trust. Then `update-post` step 2 for the date of a post that has
`publishedAt`, and the procedure ends with its verify line, 0 failures:

```bash
pnpm lint && pnpm test && pnpm content:lint && pnpm build
```

On Claude Code the `critic` agent runs this same procedure in isolation
and stops at the report; on a client without subagents, a fresh session
running this skill is the isolated pass.