frontend-code-reviewlisted

Review frontend / client-side code (Next.js App Router, React, TypeScript, Tailwind + shadcn/ui, axios + Zod + TanStack Query + RHF) for correctness, component duplication, API-binding conformance, convention adherence, accessibility, and performance. Use whenever the user asks to review, audit, critique, or sanity-check frontend code — "review this component", "code review the products binding", "review my changes / this PR / the diff", "is this screen production-ready", "check this React code for issues". It reads the frontend ARCHITECTURE.md + MODULE_REGISTRY.md so it reviews against THIS project's conventions and flags components/hooks/utils that duplicate existing shared pieces or registry entries (DRY), plus bindings that bypass the BFF/axios/Zod/Query standard. Standalone and read-only — run anytime, never auto-chained, and it does not modify source unless explicitly asked to apply fixes. Tuned for frontend; NOT for backend/Express/Mongoose review (that is backend-code-review). This is static code revi
vipincode/exr-agent-skills · ★ 0 · Code & Development · score 60

Install: claude install-skill vipincode/exr-agent-skills

# frontend-code-review Review frontend code against the project's own conventions and solid React/Next.js practice, and report findings the user can act on. What makes this more useful than a generic review: it reads the contract, so it reviews against *this* project (its BFF/axios path, envelope, Zod validation flow, TanStack Query usage, shared-component rule, feature-module layout) instead of imposing a personal style — and it checks new code against `MODULE_REGISTRY.md` to catch reinvented components, hooks, and utils. Standalone, read-only utility. Run on demand against a file, a feature module, a set of changed files, or a diff. **Never auto-invoked by other skills, and it does not edit source unless the user explicitly asks for fixes.** ## Step 1 — Establish scope and context **First resolve the project dir** for this (`frontend`) domain via `../LAYOUT.md` (read `.claude/workspace.json`; fall back to the repo root if a root `ARCHITECTURE.md` for a Next.js/React app exists with no manifest). The contract files and the code under review are **relative to that project dir** �� in a monorepo this keeps the review scoped to the frontend folder, not a sibling `backend/`. 1. **Scope** — what to review. Detect from the request: a named file/module, the working changes (`git diff`, staged, or a branch/PR), or "the project". If a repo is git-managed and the user says "my changes"/"this PR", review the diff, not the whole tree. Ask only if scope is genuinely unclear. 2. **Co