react-nextjs

React Next.js Implementation Patterns

Use this skill when the task is specifically about Next.js behavior on top of React. Reuse the general react skill for component discipline and this skill for app-structure, rendering model, and data-fetching rules.

When to Use

• Building, refactoring, or debugging Next.js routes, layouts, loading/error states, or server/client component boundaries
• Implementing data fetching, server actions, route handlers, or cache/revalidation logic in Next.js
• Working with Next.js metadata, SEO, Open Graph, or font optimization
• Reviewing Next.js code for correct server/client boundary usage, runtime safety, or rendering model

When NOT to Use

• Task is about React component logic, hooks, or state without Next.js specifics — use react alone
• Task is about Vue, Nuxt, or non-React frameworks — use the appropriate framework skill
• Task is about backend API logic in a separate service (not Next.js route handlers) — use backend skills

Delivery Workflow

Use the checklist below and track progress:

React Next.js progress:
- [ ] Step 1: Discover App Router or Pages Router conventions
- [ ] Step 2: Map server and client boundaries explicitly
- [ ] Step 3: Implement data flow, routing, and mutations
- [ ] Step 4: Verify caching, metadata, and error/loading states
- [ ] Step 5: Test the route behavior and runtime assumptions

Routing and Composition

• Follow the existing router model first. Do not introduce App Router patterns into Pages Router code or the reverse without need.
• Keep route structure intentional: layout, page, loading, error, and nested segments should reflect real product boundaries.
• Keep framework-level concerns in route files and push reusable UI into shared React components.
• Treat route params, search params, and server-derived state as explicit inputs, not implicit globals.

Server and Client Boundaries

• Default to server-first where the project already uses that model.
• Add client components only when interactivity, browser APIs, or client-side state actually require them.
• Keep client boundaries small so most rendering can stay server-driven.
• Do not pass unnecessary heavy objects across server-client boundaries.
• Make serialization constraints visible when designing props and action payloads.