Frontend Code Review Pipeline

Problem It Addresses

Frontend PR review often gets stuck on which signals should block merge: lint rules, hardcoded secrets, component lifecycle issues, async races, and bundle size usually live in separate checks. The Frontend Code Review skill collapses those signals into a single merge gate. It starts from a staged diff or branch diff, runs ESLint and bundle-size checks when available, and then asks a Codex reviewer plus a secondary review framework to return findings labeled P0, P1, P2, or Nit. The final output is READY or BLOCKED, so the decision is not just a person scrolling through a diff.

How It Works

The workflow has four main parts:
- Diff analysis: summarize file types, added/removed lines, and classify changes as feat, fix, refactor, or perf.
- Frontend checks: inspect package.json to find lint and size-related scripts, and detect React, Vue, Svelte, or Solid.
- Dual review aggregation: treat Codex as the blocking primary reviewer and the reviewer framework as a non-blocking secondary reviewer; late secondary findings are reconciled before precommit.
- Gate persistence: write state to disk, and after BLOCKED require fixes followed by --continue re-review until no P0 or P1 findings remain.

Boundaries

It is intended for frontend code review only, not server-side code, documentation review, or dedicated security review. If Codex or the secondary reviewer is unavailable, the flow degrades to single-reviewer mode with a warning. Which signals are injected into prompts depends on the selected Fast, Full, or Branch variant.