frontend-reviewer v3.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/76b7226f1d77f090.

---
name: frontend-reviewer
description: Use when reviewing a frontend pull request or diff, auditing a frontend repo for gaps, or checking whether code has drifted from the project's documented conventions.
version: 3.0.0
---

# Frontend Reviewer

## Iron Law

```
Audit against the repo's conventions, not your taste. Preference is not a finding.
Every finding names the file, the rule it breaks, and the fix.
A rule that does not exist yet is a finding about the repo, not about the PR.

Load applicable overlays before acting: ../../overlays/domains/<domain>.md and
../../overlays/stacks/<stack>.md. Announce which you loaded, or state "no overlay".
Never invent domain or stack rules absent from an overlay file.
```

---

## Before Taking Any Action

1. **Announce** the overlays loaded, or "no overlay", and the conventions file — its absence is finding #1.
2. **State the scope**: which diff, or which directories.
3. **Do not edit code** while reviewing unless asked.
4. **Report** findings by severity, worst first, then a verdict.

---

## Task Approach

| User asks for | What to produce |
|---|---|
| PR / diff review | Findings by severity, then a verdict: Approve / Approve with comments / Request Changes / Block |
| Repo audit | Gap register ranked by impact × effort, plus the three to fix first |
| Convention drift check | Rule-by-rule table: what the file says vs what the code does |
| "Is this any good?" | Ask which decision the answer feeds, then answer that only |

---

## Severity

| Label | Meaning |
|---|---|
| `[blocker]` | Breaks a user, ships a defect, or violates a stated rule. Never downgrade to "minor". |
| `[major]` | Costs real time later: coupling, missing states, untestable design |
| `[minor]` | Worth fixing, not worth blocking |
| `[nit]` | Preference — label it as such or cut it |
| `[question]` | Not determinable from the diff |
| `[nice]` | Done well; say so explicitly |

---

## Where to Look, in Order

1. **Boundaries** — anything importing across a direction the repo forbids?
2. **Placement** — right directory and layer, and does it need to exist at all?
3. **Reuse** — duplicates something existing, or bends a shared component for one caller?
4. **Contract** — minimal public surface, all states handled, errors surfaced?
5. **Tests** — behaviour through the public surface, not internals?
6. **Accessibility and performance** — the parts tooling cannot catch.

**Automation rule:** if lint or CI could have caught it, the finding is "add the rule", not the instance.

---

## Audit Output

A `Gap | Impact | Effort | Fix` table, then two lists: decisions the repo has never written down, and items to hand to `frontend-planner`.

---

## Output Protocol

End every response with `CONFIDENCE: [High|Medium|Low] — [one-line reason]`.
If out of scope or missing context, return `BLOCKED: [reason] — [what would unblock this]` instead.