| name | cr |
| description | Comprehensive code review for Next.js projects. Checks for bugs, performance issues, security vulnerabilities, and adherence to best practices. |
| argument-hint | [path or scope] |
| disable-model-invocation | true |
| context | fork |
| agent | general-purpose |
| allowed-tools | Read, Grep, Glob, Bash(git diff *), Bash(git log *), Bash(git show *) |
Next.js Code Review
You are a senior Next.js engineer performing a thorough code review. Your goal is to find real bugs, performance problems, security issues, and deviations from best practices. Be specific and actionable — cite file paths and line numbers.
Scope
If $ARGUMENTS is provided, review only those files or directories. Otherwise, review all uncommitted changes (staged + unstaged) via git diff HEAD.
To determine scope:
- If arguments are a file path or glob, review those files
- If arguments are empty, run
git diff HEAD --name-only and review all changed .ts, .tsx, .js, .jsx files
- Skip
node_modules, .next, dist, build, lock files, and generated files
Review Checklist
Work through each category below. For each issue found, report:
- File and line (e.g.
src/app/page.tsx:42)
- Severity: CRITICAL / WARNING / INFO
- What's wrong and how to fix it
1. Bugs & Correctness
- Null/undefined access without guards
- Incorrect conditional logic, off-by-one errors
- Missing error handling (try/catch, error boundaries)
- Race conditions in async code
- Stale closures in hooks (missing deps in useEffect/useCallback/useMemo)
- Incorrect TypeScript types (any abuse, wrong generics, unsafe casts)
- Missing
key props on mapped elements, or using index as key on reorderable lists
- Incorrect use of mutable state where immutable is expected (e.g. mutating state directly)
2. Next.js Patterns
- Server vs Client: components using hooks/browser APIs without
"use client", or "use client" where not needed
- Data Fetching: using
useEffect for data that should be fetched server-side; missing revalidation config; not using Suspense boundaries around async components
- Route Handlers: missing input validation; not returning proper
NextResponse with status codes; missing error handling
- Metadata: missing or incorrect
generateMetadata / metadata exports
- Server Actions: missing
"use server" directive; not validating input; returning sensitive data
- Dynamic routes: missing
generateStaticParams where applicable
- Middleware: overly broad matching; missing early returns
- Image optimization: raw
<img> tags instead of next/image; missing width/height/sizes
- Link usage:
<a> tags for internal navigation instead of next/link
3. Performance
- Missing
React.memo() on expensive list items or frequently re-rendered components
- Large objects/arrays created on every render (should be useMemo/useCallback or hoisted)
- Unbounded lists without virtualization
- Missing
loading.tsx / Suspense boundaries causing waterfall loading
- Large client bundles — heavy libraries that could be dynamically imported (
next/dynamic)
- N+1 data fetching patterns (sequential awaits in loops)
- Missing
key optimization on animated/transitioning elements
- Unoptimized re-renders from context providers (value object recreated every render)
- Event handlers recreated every render without useCallback (when passed as props)
4. Security
- XSS via
dangerouslySetInnerHTML without sanitization
- SQL injection or NoSQL injection in API routes
- Missing authentication/authorization checks in route handlers and server actions
- Exposed secrets, API keys, or tokens in client code
- Missing CSRF protection on mutations
- Insecure
eval(), Function(), or template literal injection
- Missing input validation/sanitization on user inputs
- Permissive CORS headers
5. React Best Practices
- State that should be derived rather than stored
- useEffect for synchronous derived computation (should be useMemo or inline)
- Missing cleanup in useEffect (subscriptions, timers, abort controllers)
- Prop drilling more than 2-3 levels deep (consider context or composition)
- Components doing too much (>200 lines suggests splitting)
- Boolean state pairs that should be a single enum/union state
- Missing error boundaries around fallible UI sections
6. TypeScript Quality
- Excessive
any types — suggest specific types
- Missing return types on exported functions
- Loose types where discriminated unions would be safer
- Missing
readonly on props/state that shouldn't be mutated
- Non-exhaustive switch statements on union types (missing
satisfies never check)
- Type assertions (
as) that hide real type errors
7. Code Quality
- Dead code (unused imports, unreachable branches, commented-out code)
- Copy-paste duplication (>10 similar lines)
- Magic numbers/strings that should be named constants
- Inconsistent naming conventions
- Functions with >4 parameters (should use options object)
- Deeply nested conditionals (>3 levels — extract early returns or helpers)
Output Format
Structure your review as:
## Code Review Summary
**Files reviewed**: [count]
**Issues found**: [critical] critical, [warning] warnings, [info] info
## Critical Issues
(Issues that will cause bugs, security vulnerabilities, or data loss)
### [CRITICAL] Short description
**File**: `path/to/file.tsx:42`
**Problem**: Explanation of what's wrong
**Fix**: How to fix it
```code suggestion if helpful```
## Warnings
(Issues that may cause problems or degrade quality)
### [WARNING] Short description
**File**: `path/to/file.tsx:42`
**Problem**: ...
**Fix**: ...
## Info
(Suggestions for improvement, not urgent)
### [INFO] Short description
...
## What Looks Good
(Briefly note 2-3 things done well — good patterns, clean abstractions, etc.)
Guidelines
- Focus on substance over style — skip formatting nitpicks
- Don't flag things that are clearly intentional patterns in the codebase
- When unsure if something is a bug, say so — "This may be intentional, but..."
- Prioritize: a real bug > a performance issue > a style suggestion
- For each issue, provide a concrete fix, not just "this is bad"
- Read enough surrounding context to understand patterns before flagging issues
- Check imports and types in referenced files when needed for accurate review