---
name: prd-review
description: Runs a full acceptance review of finished work against a PRD, requirement by requirement, with a pass, fail or unverified verdict and evidence for each, then updates the progress ledger. Use before a handoff, a release or a stakeholder demo, or when the user says review, audit, QA this, check everything against the PRD, are we done, is this ready, or does this meet the brief. Also use when the user wants a final check of design or code against the brief's hard rules.
---

# PRD Review

prd-next checks one step at a time. This skill checks everything at once, against the PRD, before work leaves the user's hands. Its output is a verdict per requirement that someone else could repeat and get the same answer.

Write in plain punctuation. No em-dashes.

## Rules that do not change

1. **Judge against the PRD, not against taste.** The test for each requirement is its own acceptance check, and for Brief rules, the quoted words. Do not add rules the PRD never stated. If something looks wrong but breaks no requirement, list it separately as an observation.
2. **Three verdicts only: pass, fail, unverified.** `pass` needs evidence that someone could open. `fail` says what failed, where, and which requirement. `unverified` says exactly what is missing (a device, a person, a file) and who can supply it. There is no "mostly".
3. **Never pass on a guess.** "Should work", "looks like", "probably" are `unverified`.
4. **Check what was actually opened.** If only part of the work was read, say how much. A requirement that applies everywhere (a typeface, a wording rule) is `unverified` for the part that was not read.
5. **Retired or superseded work is out of scope**, but only if the user said so. Record the decision, then exclude it.
6. **Report, do not repair.** This skill finds problems. Fixing them is a separate step the user chooses.

## Workflow

1. **Find the files.** The PRD, its ledger, and the work (a canvas link, Figma, files, a repo, a build). If the work is not available, stop and ask for it, as in prd-handoff. A review of nothing is not a review.
2. **Sync first if needed.** If the user changed the work or the PRD since the ledger was last updated, run prd-next's `drift`, `resync` and its sync step (`references/sync.md`, `references/read-artifacts.md`) so the review runs against the current state.
3. **Build the checklist.** Run `python3 scripts/review.py checklist LEDGER`. It lists every in-scope requirement (Proposed and dropped ones are left out) with its acceptance check and a `how` field: `scan` (testable by script; a hint, confirm it), `look` (needs eyes on the screen or output), `read` (copy review of text), `device` (needs a real device or live system), `person` (needs a named person's yes).
4. **Run the checks, cheapest first.**
   - `scan`: use prd-next's `scripts/scan_canvas.py` for design files, or grep and tests for code. Pass only if the whole in-scope set was scanned.
   - `read`: read every string in the work that the rule covers. Say how many were read.
   - `look`: open the screens, or screenshots of them, in the right theme and state. Record which ones.
   - `device` and `person`: usually `unverified`. Say exactly what to run and who must confirm, in one line each.
5. **Write the verdicts table** as `| ID | Verdict | Evidence |` and save it as `<slug>-review.md` next to the PRD, with a short summary above it. Then run `python3 scripts/review.py lint FILE LEDGER` and fix everything it lists.
6. **Update the ledger** with prd-next's `scripts/ledger.py`: `set R# done --evidence "..."` for passes, `set R# review --evidence "..."` for fails, and leave unverified ones as `doing` with what is missing. `log` the review.
7. **Report** in the format below. Do not paste the table into chat; send the file.

## Summary format

```
Review: [slug], [date], scope: [what was opened, how much]
Pass: [n]   Fail: [n]   Unverified: [n]
Fails: [each in one line: ID, where, the quoted rule it breaks]
Cannot confirm from here: [what is needed, from whom]
Observations (not in the PRD): [short list, or none]
Verdict: [Ready to hand off / Hand off with these listed gaps / Not ready, fix the fails first]
```

Give the verdict that the numbers support. A single fail on a quoted Brief rule means "Not ready".

## After the review

- Fails on Brief rules: offer exactly two paths per fail, fix the work or change the rule (hand to prd-change if they change the rule).
- Passes and unverified items feed prd-handoff: passes go in Included, unverified go in Not included with the reason.
- If everything in scope passes, say so, and offer the handoff.