| name | nextjs |
| description | Build, review, and refactor Next.js (App Router) frontend projects with TypeScript. Use for tasks like creating pages/layouts, routing, server components vs client components, data fetching patterns, UI component structure, forms/validation, auth integration points, env vars, linting/testing, and production deployment readiness. |
nextjs
Use this skill to implement or review a Next.js frontend in a consistent, production-friendly way.
Defaults (unless repo dictates otherwise)
- Next.js App Router (
app/) - TypeScript
- Server Components by default; add
"use client"only when needed - CSS: Tailwind if already present; otherwise follow existing styling approach
Workflow
- Identify project mode
- New app: decide App Router vs Pages Router (prefer App Router unless constrained).
- Existing app: follow current structure, conventions, and tooling.
- Establish app structure (App Router)
app/layout.tsx: global shell (providers, fonts, nav).app/page.tsx: landing page.- Route groups for domains:
app/(dashboard)/...,app/(marketing)/.... - Shared UI:
components/(reusable),app/**/_components/(route-scoped). - Types/utilities:
lib/(fetchers, helpers),types/.
- Server vs client boundaries
- Prefer Server Components for data loading and initial render.
- Use Client Components for: event handlers, stateful UI, browser APIs, client-only libraries.
- Keep props serializable across the boundary; avoid passing functions/classes.
- Data fetching patterns
- Prefer colocated server fetchers in
lib/and call them from Server Components. - Use
fetch()with Next caching semantics when appropriate. - Handle loading and errors with
loading.tsx/error.tsxper route segment.
- Forms and validation
- Use server actions when appropriate; otherwise route handlers (
app/api/...) + client submit. - Validate on server; optionally mirror on client.
- Env vars & config
- Document required env vars; use
process.env.X. - Only expose public vars with
NEXT_PUBLIC_prefix.
- Quality gates
- Run
lintandtypecheck(and tests if present). - Ensure accessibility basics: labels, focus states, keyboard navigation.
- Avoid breaking route segments/URLs; add redirects when changing paths.
Output expectations when making changes
- Keep diffs small and localized.
- Prefer composition over complex shared state.
- Add a short usage note (routes added, env vars, how to run) when you introduce new capabilities.