/review-frontend

description: Comprehensive React/TypeScript frontend code review with per-area review skills, run in parallel where the agent supports subagents and sequentially otherwise.
name: review-frontend
disable-model-invocation: true

Frontend Code Review

Arguments

• `--parallel`: Hint to fan out per technology area when the agent supports subagents (see Step 5). When unsupported, the review runs sequentially with identical output.
• Path: Target directory (default: current working directory)

Step 1: Identify Changed Files

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.(tsx?|jsx?|mjs|cjs|css)$|^(remix|vite)\.config\.'

Step 2: Detect Technologies

# Detect Remix v2 (any official adapter). When matched, the Remix-specific
# surface is delegated to the review-remix-v2 skill in Step 4.
grep -E '"@remix-run/(react|node|cloudflare|deno|serve)"' package.json | head -3

# Detect React Flow
grep -r "@xyflow/react\|ReactFlow\|useNodesState" --include="*.tsx" -l | head -3

# Detect Zustand
grep -r "from 'zustand'\|create\(\(" --include="*.ts" --include="*.tsx" -l | head -3

# Detect Tailwind v4
grep -r "@theme\|@layer theme" --include="*.css" -l | head -3

# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.test\.tsx?$'

Step 3: Load Verification Protocol

Load the [review-verification-protocol](../review-verification-protocol/SKILL.md) skill before any substantive judgment on code.

**Pass before Step 5:** The skill is loaded (or its checklist is open in context). Do not classify severity or write findings until this gate clears.

Step 4: Load Skills

Read each applicable skill below (open its `SKILL.md`) so its guidance is in context before you review that area.

**Remix v2 branch (Step 2 detected `@remix-run/*` in package.json):**

• Load [review-remix-v2](../review-remix-v2/SKILL.md) — umbrella orchestrator that loads all six Remix v2 area review skills (routing, data-flow, forms, error-boundaries, perf/SSR, meta+sessions) with its own detection telemetry. Run it for the Remix-specific surface and consolidate its findings into this review's output.
• Do NOT also load [react-router-code-review](../react-router-code-review/SKILL.md) — Remix v2 sits on React Router v6 but routes through Remix's route module conventions, which [remix-v2-routing-review](../remix-v2-routing-review/SKILL.md) (loaded via the umbrella) covers in that context.
• Still load [shadcn-code-review](../shadcn-code-review/SKILL.md) and the conditional skills below — they're orthogonal to the Remix layer and apply to component/styling/state code regardless of router.

**Non-Remix branch (default):**

• [react-router-code-review](../react-router-code-review/SKILL.md)
• [shadcn-code-review](../shadcn-code-review/SKILL.md)

**Conditionally load based on detection (both branches):**

| Condition | Skill | |-----------|-------| | @xyflow/react detected | [react-flow-code-review](../react-flow-code-review/SKILL.md) | | Zustand detected | [zustand-state](../zustand-state/SKILL.md) | | Tailwind v4 detected | [tailwind-v4](../tailwind-v4/SKILL.md) | | Test files changed | [vitest-testing](../vitest-testing/SKILL.md) |

Step 5: Review

**If the agent supports subagents** (and `--parallel` is requested or appropriate), dispatch one subagent per technology area in parallel; **otherwise** run the same areas sequentially in a single context. Both paths produce identical output.

Parallel path: 1. Detect all technologies upfront 2. Dispatch one subagent per technology area, each loading its skill and reviewing its domain 3. Wait for all subagents to return 4. Consolidate findings

Sequential path: 1. Load applicable skills 2. Review React Router patterns first 3. Review shadcn/ui patterns 4. Review detected technology areas 5. Consolidate findings

Step 6: Verify Findings

Before reporting any issue: 1. Re-read the actual code (not just diff context) 2. For "unused" claims - did you search all references? 3. For "missing" claims - did you check framework/parent handling? 4. For syntax issues - did you verify against current version docs? 5. Remove any findings that are style preferences, not actual issues

**Pass before promoting to Critical/Major:** For that item, (2)–(4) are satisfied with a concrete artifact when applicable — e.g. opened file at `FILE:LINE`, grep/search output for references, or cited parent/framework code — not only diff context.

Step 7: Review Convergence

Single-Pass Completeness

You MUST report ALL issues across ALL categories (style, logic, types, tests, security, performance) in a single review pass. Do not hold back issues for later rounds.

Before submitting findings, ask yourself:

• "If all my recommended fixes are applied, will I find NEW issues in the fixed code?"
• "Am I requesting new code (tests, types, modules) that will itself need review?"

If yes to either: include those anticipated downstream issues NOW, in this review, so the author can address everything at once.

Scope Rules

• Review ONLY the code in the diff and directly related existing code
• Do NOT request new features, test infrastructure, or architectural changes that didn't exist before the diff
• If test coverage is missing, flag it as ONE Minor issue ("Missing test coverage for X, Y, Z") — do NOT specify implementation details like mock libraries, behaviour extraction, or dependency injection patterns that would introduce substantial new code
• Typespecs, documentation, and naming issues are Minor unless they affect public API contracts
• Do NOT request adding new dependencies (e.g. Mox, testing libraries, linter plugins)

Fix Complexity Budget

Fixes to existing code should be flagged at their real severity regardless of size.

However, requests for **net-new code that didn't exist before the diff** must be classified as Informational:

• Adding a new dependency (e.g. Mox, a linter plugin)
• Creating entirely new mo