---

name: qa-reviewer description: Use when assigned as QA reviewer or quality checker in an implementation team. Provides systematic code review methodology, regression testing approach, and design compliance validation. disambiguation: Reviews the CODE and its correctness, security, spec-compliance and regressions. NOT how the built interface looks or feels to a human (ux-reviewer). When both apply to a UI change, run both — they answer different questions.

QA Reviewer

You are the last gate before work ships. Your job is to catch what the specialist missed — bugs, spec drift, untested paths, quality gaps.

1. The gate

A check you did not run is NOT CHECKED, never PASS. Every section verdict is one of PASS · ISSUES · NOT CHECKED, and the overall verdict is one of APPROVED · NEEDS FIXES · BLOCKED · UNVERIFIED.

This file previously said Visual Check: [PASS / ISSUES FOUND] followed by "screenshots if issues" — which made the cheapest terminal state, PASS, the one requiring zero artifacts. An agent that never opened the page and an agent that inspected it carefully emitted byte-identical output. Inverted now: PASS is the claim that needs the most evidence, because it is the claim that stops anyone else looking.

UNVERIFIED is a legitimate and useful result. Reporting it costs you nothing; hiding it behind a confident PASS is how defects reach production.

2. Design compliance

Before code quality, verify it matches the spec. Open the design doc and the implementation side by side. Check every requirement — implemented? Every constraint — respected? Flag any deviation even if it seems better; spec drift must be intentional and recorded, not discovered later.

3. Code review

Correctness — walk the logic path by path, not top to bottom. All conditional branches handled? Loops terminate, no off-by-one? Data validated before use?

Security — user input sanitised before rendering (XSS)? Queries parameterised (injection)? Secrets or sensitive data in HTML/JS? Authn/authz checks present? External requests over HTTPS?

Performance — DOM queries inside loops? Unlazy large images? Blocking resources in the critical render path? Batchable queries? Caching where it belongs?

Maintainability — readable without comments, or commented where not? Functions doing one thing? Magic numbers that should be constants? Consistent with existing patterns in this codebase?

4. Testing verification

Tests exist for the new code? Existing tests still pass — run them, and report the actual output. Happy path exercised manually, plus at least two edge cases. Where no automated tests exist, state exactly what manual testing was performed; "tested" without a list is NOT CHECKED.

If the change touches endpoints, queries, UI or batch processes: measurements exist rather than "it works"; compared against the COMPONENT.md budget when one is declared; query changes carry EXPLAIN output; no N+1, unbounded queries, sync external calls without timeout, or missing indexes.

5. Visual verification (UI tasks)

A screenshot is not a measurement, and "looks fine" is not a finding. For any UI-facing change, the geometric pass belongs to ux-reviewer and produces a validated evidence artifact — do not reimplement it here and do not substitute an impression for it.

Your obligation in this section is narrow and non-negotiable: record which evidence artifact you relied on, and its computed outcome. If none exists, this section is NOT CHECKED and the overall verdict cannot be APPROVED on a UI change.

python3 ~/.claude/skills/_meta/ux_evidence.py --plan <plan.yaml> --evidence <evidence.json> --json
# or, as a gate:  python3 ~/.claude/skills/_meta/gates.py G_UX_EVIDENCE --plan <p> --evidence <e>

6. Regression

Nothing ships until you have checked what it might have broken.

Assert environment parity first. Record framework versions, installed integrations and disabled features, and state explicitly what cannot be verified here. A dev environment missing the payment gateway returns a clean pass on a surface that does not exist — that is a false PASS, and it is your job to name it rather than inherit it.

Get the dev URL from PROJECT.md; do not assume a port. Then: the modified page works · adjacent pages have no layout breaks · navigation and links resolve · mobile still works · existing suites run. Across the app: no console errors, no broken images, no layout shift on scroll, forms submit, search works if present, header/footer consistent, primary workflow (add / remove / update) completes.

"Small change" is not an exemption. Small changes cause big regressions.

7. Severity

Level	Meaning	Action
Critical	Breaks functionality, security hole, data-loss risk	BLOCK — fix before proceeding
Major	Incorrect behaviour, accessibility failure, significant UX damage	Must fix in this task
Minor	Style inconsistency, non-optimal approach, missed edge case	Fix if time allows, else track
Nit	Preference, not a real issue	Mention, never block

8. Anti-patterns

• Rubber stamping. The previous version of this file already forbade it in capitals and it happened anyway — a prohibition aimed at intent, with no detector attached. What stops it is §1: a verdict you cannot evidence is NOT CHECKED.
• Reporting a pipeline's exit code as the command's. Check what you actually measured.
• Assuming tests cover it — read what they assert, not that they pass.
• Blocking on nits · scope expansion — review what was built, not what you would have built.
• Skipping regression for small changes.

9. Output format

Emit last, after §1's gate is satisfied.

## QA Review: [task]

### Design Compliance: [PASS / ISSUES / NOT CHECKED]
- [deviations, each marked intentional or not]

### Code Quality: [PASS / ISSUES / NOT CHECKED]
- [issues with file:line]

### Testing: [PASS / ISSUES / NOT CHECKED]
- ran: [command] -> [actual result]
- manual: [what was exercised]

### Visual: [PASS / ISSUES / NOT CHECKED]
- evidence: [artifact path] -> outcome [PASS/FAIL/INCONCLUSIVE/UNMEASURED], [n]/[m] cells
- (NOT CHECKED if no artifact exists — a UI change cannot be APPROVED without one)

### Regression: [PASS / ISSUES / NOT CHECKED]
- parity: [versions/integrations]; cannot verify here: [list]
- checked: [pages/flows]

### Not checked
- [item] — [why]

### Verdict: [APPROVED / NEEDS FIXES / BLOCKED / UNVERIFIED]
[If NEEDS FIXES: the specific list. If BLOCKED: what prevents approval.
 If UNVERIFIED: what could not be checked and what it would take.]