playbooks

home / skills / yldgio / codereview-skills / nextjs

nextjs skill

/skills/nextjs

This skill helps you review Next.js 14+ App Router patterns for server components, data fetching, performance, and accessibility to ship robust apps.

npx playbooks add skill yldgio/codereview-skills --skill nextjs

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.2 KB
---
name: nextjs
description: Next.js 14+ App Router patterns, Server Components, API routes, and performance optimization
---

## Next.js Code Review Rules

### Security (Critical)
- Server Actions must validate and sanitize all input
- No secrets exposed in client components
- Check `headers()` and `cookies()` usage is server-side only
- Sanitize all dynamic values (file names, HTTP headers) to prevent injection attacks
- Never use HTML comments (`<!-- -->`) in production code
- Validate and escape all user-provided content before rendering

### App Router Structure
- Verify `app/` directory structure follows conventions (`page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`)
- Check `use client` directive is only used when necessary (event handlers, hooks, browser APIs)
- Server Components should not import client-only libraries (useState, useEffect, etc.)
- Implement error boundaries with `error.tsx` for error handling
- Use error boundaries to catch and handle errors in Server Components
- Provide fallback UIs for errors with proper error messages

### Data Fetching
- Prefer Server Components for data fetching over client-side fetching
- Check for proper use of `cache()` for request deduplication
- Validate `revalidate` options for ISR (Incremental Static Regeneration)
- Ensure `generateStaticParams()` is used for static generation of dynamic routes

### Performance (Essential)
- Images must use `next/image` with explicit `width`/`height` or `fill`
- Fonts should use `next/font` for automatic optimization
- Check for proper `Suspense` boundaries around async components
- Verify no blocking data fetches in layouts (affects all child routes)

### API Routes
- Validate HTTP methods (check `req.method` or use route handlers)
- Implement authentication and authorization
- Return appropriate HTTP status codes
- Handle errors gracefully with try-catch
- Sanitize and validate all inputs
- Use proper CORS headers when needed

### Accessibility
- Use semantic HTML elements
- Include `alt` text on all images
- Ensure keyboard navigation works
- Test with screen readers
- Maintain proper heading hierarchy
- Add ARIA labels where needed

### Testing
- Write unit tests for critical components
- Test Server Components and Server Actions
- Use integration tests for data fetching flows
- Test error boundaries and error states
- Include e2e tests for critical user flows
- Validate test coverage for mission-critical features

### Dependencies
- Keep Next.js and React versions compatible
- Check for breaking changes when updating
- Audit third-party packages for security and compatibility
- Use official Next.js plugins when available
- Avoid excessive dependencies for simple functionality

### Edge Runtime (Advanced)
- Review usage of Edge runtime for API routes
- Ensure Edge-compatible code (no Node.js-specific APIs)
- Use Edge runtime for latency-sensitive operations
- Be aware of Edge runtime limitations (memory, execution time)
- Test Edge functions thoroughly

### Common Anti-patterns
- Avoid `use client` at layout level (makes all children client components)
- Avoid fetching same data in multiple components (use cache or pass as props)
- Avoid `dynamic = 'force-dynamic'` without justification

Overview

This skill provides concise, practical review rules and guidance for Next.js 14+ App Router projects focused on Server Components, API routes, and performance optimization. It codifies security checks, app-router structure conventions, data-fetching patterns, performance musts, accessibility, testing, and edge-runtime considerations. The goal is to help teams ship resilient, fast, and secure Next.js applications with repeatable code-review checkpoints. Guidance targets common anti-patterns and real-world trade-offs for modern Next.js apps.

How this skill works

The skill inspects app-router structure and component types to ensure Server vs. Client boundaries are correct, checks data-fetching and caching strategies, and validates API route practices including input validation and HTTP handling. It flags performance issues like improper image/font usage and missing Suspense boundaries, enforces security rules (no secrets on client, input sanitization), and evaluates accessibility and testing coverage. For advanced flows it reviews Edge runtime compatibility and dependency upgrade risks.

When to use it

  • During pull-request reviews for Next.js 14+ projects using the App Router
  • When migrating pages to Server Components or converting to the App Router
  • Before releasing performance-sensitive features or public APIs
  • When introducing Edge functions or changing runtime targets
  • While auditing security, accessibility, or QA test coverage

Best practices

  • Validate and sanitize all inputs in Server Actions and API routes; never trust client input
  • Keep secrets and server-only APIs out of client components; enforce server-side checks for headers() and cookies()
  • Prefer Server Components for data fetching; use cache() and revalidate only where appropriate
  • Use next/image with explicit width/height or fill and next/font for fonts to ensure automatic optimization
  • Wrap async UI with Suspense boundaries and avoid blocking fetches in layouts
  • Implement error boundaries (error.tsx) and provide clear fallback UIs with safe error messages

Example use cases

  • Code review checklist for PRs converting a route to Server Components
  • Audit for a performance regression after a dependency upgrade
  • Security review before exposing a new API route or webhook
  • Checklist when adopting Edge runtime for low-latency endpoints
  • Pre-release accessibility and e2e test verification for critical user journeys

FAQ

Should I always use Server Components for data fetching?

Prefer Server Components for most data fetching for better performance and smaller client bundles; use client fetching only when you need client-side interactivity or subscriptions.

When is the Edge runtime a good choice?

Use Edge for latency-sensitive, read-heavy, or geo-distributed endpoints, but ensure code is Edge-compatible (no Node APIs) and test memory/execution constraints.