# Writing a great review

For the `review` type (gear / plugin / pack). A strong Scrybe review is **verdict-first, specific,
and honest** — the kind a peer actually trusts. The structured fields carry the scannable facts;
the body carries the story. (Vibe/appearance options live in `docs/layouts.md`.)

## The fields (the renderer turns these into the rating, pros/cons cards, and specs)
- **`subject`** — the product name (also the page `<h1>`).
- **`reviewType`** — `gear` · `plugin` · `pack`.
- **`rating`** — 0–5, halves OK; renders as stars. Use the real scale and don't inflate:
  `5` essential · `4–4.5` strong, with caveats · `3` situational · `≤2` skip.
- **`pros` / `cons`** — 3–4 short, concrete bullets each (side-by-side cards). Pros say *why*;
  cons are genuinely honest (an all-pros review reads like an ad).
- **`specs`** — `{ format, daw, … }` clean key/values. Only facts you can verify.
- **`buyLink` / `demoAudio`** — `null` until you have the real URL / audio. The build's
  **facts-to-confirm** list reminds you; never invent them.

## The body recipe (the narrative — not a repeat of the fields)
1. **Lead with the verdict.** First 1–2 sentences: what it is + your take. No throat-clearing.
2. **Ground it in real work.** "For *Away* the kit came from…" — specifics beat adjectives.
3. **The one thing that matters.** The single decisive trait (the GGD kick; Kontakt's *space*),
   explained concretely — that's the paragraph readers came for.
4. **A screenshot.** One `figure` with `src: "/assets/img/reviews/<slug>-*.jpg"` — stub it; the
   missing-assets report tells you the exact file to drop in. Caption it.
5. **Who it's NOT for.** The honest limit. This is what earns trust.
6. **Pull quote.** Lift the sharpest line as a `pullQuote` (cite the artist).

Keep pros/cons/specs in the **fields**, not restated in prose — body = story, fields = the scan.

## Voice & honesty
- First-person, specific, dry — the producer voice (`voice/voice-guide.md`; obey the banlist).
- It's an opinion piece, so the *opinions* are yours to write — but **never fabricate hard facts**:
  price, version numbers, measured specs, the buy link, demo audio. Leave them `null` / omitted.
- Screenshots stay stubs until real images exist; the build flags every missing one.

## Template
```json
{
  "$schema": "../schemas/review.schema.json",
  "type": "review", "schemaVersion": 1,
  "title": "<Product>", "slug": "<product>", "date": "<YYYY-MM-DD>",
  "summary": "<the verdict in one line>",
  "subject": "<Product>", "reviewType": "plugin", "rating": 4.5,
  "pros": ["<why it's good 1>", "<why it's good 2>", "<why it's good 3>"],
  "cons": ["<honest limit 1>", "<honest limit 2>"],
  "specs": { "format": "VST3 / AU / AAX", "daw": ["Logic"] },
  "buyLink": null, "demoAudio": null,
  "body": [
    { "block": "prose", "markdown": "<verdict-first lead → real use case → the one decisive trait → who it's not for>" },
    { "block": "figure", "src": "/assets/img/reviews/<slug>.jpg", "alt": "<what it shows>", "caption": "Screenshot stub.", "width": "wide", "ratio": "16x9" },
    { "block": "pullQuote", "text": "<the sharpest line>", "cite": "<artist>" }
  ]
}
```

Worked examples in the repo: `content/reviews/get-good-drums.json`, `content/reviews/kontakt-8.json`.