Nextjs Best Practices
Give your coding agent a concrete App Router playbook so Server vs Client splits, caching, and file-based routes stay consistent while you ship Next.js UI.
Overview
nextjs-best-practices is an agent skill for the Build phase that applies Next.js App Router principles for Server Components, data fetching, and routing patterns.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill nextjs-best-practicesWhat is this skill?
- Decision tree for Server vs Client Components and when to split parent/child
- Data-fetching matrix: static default, ISR revalidate, and no-store dynamic
- App Router file conventions: page, layout, loading, error, not-found
- Route organization patterns: groups, parallel routes, and layout composition
- 3 major principle sections: Server vs Client, Data Fetching, Routing
Adoption & trust: 562 installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps blurring Server and Client boundaries or picking the wrong fetch/cache strategy on App Router routes.
Who is it for?
Solo builders or tiny teams building or refactoring Next.js 13+ App Router apps who want agent-generated code to match framework defaults.
Skip if: Projects still on the Pages Router only, or teams that need deployment/CI guidance rather than in-repo UI architecture rules.
When should I use this skill?
Building or refactoring Next.js App Router UI, data fetching, or route structure with an agent.
What do I get? / Deliverables
Implementation follows a consistent App Router model—clear component split, documented fetch strategy, and standard route files—so features are easier to ship and maintain.
- Server/Client component boundaries aligned to the decision tree
- Route files and fetch/cache choices documented in implementation
Recommended Skills
Journey fit
Next.js structure and rendering choices are applied during product implementation, before launch polish. The skill centers on pages, layouts, routing conventions, and component boundaries—classic frontend build work.
How it compares
Use as an in-editor conventions skill—not a substitute for the official Next.js docs or a hosted MCP that scaffolds projects for you.
Common Questions / FAQ
Who is nextjs-best-practices for?
Indie and solo developers using AI coding agents on Next.js App Router products who need repeatable rules for components, data loading, and route files.
When should I use nextjs-best-practices?
During Build (frontend) while adding routes, layouts, or data-bound pages; also when reviewing agent output that mixes client hooks into server components or omits loading/error boundaries.
Is nextjs-best-practices safe to install?
It is procedural guidance with Read/Write/Edit/Glob/Grep tooling—review file changes like any skill and check the Security Audits panel on this Prism page before trusting third-party packs.
SKILL.md
READMESKILL.md - Nextjs Best Practices
# Next.js Best Practices > Principles for Next.js App Router development. --- ## 1. Server vs Client Components ### Decision Tree ``` Does it need...? │ ├── useState, useEffect, event handlers │ └── Client Component ('use client') │ ├── Direct data fetching, no interactivity │ └── Server Component (default) │ └── Both? └── Split: Server parent + Client child ``` ### By Default | Type | Use | |------|-----| | **Server** | Data fetching, layout, static content | | **Client** | Forms, buttons, interactive UI | --- ## 2. Data Fetching Patterns ### Fetch Strategy | Pattern | Use | |---------|-----| | **Default** | Static (cached at build) | | **Revalidate** | ISR (time-based refresh) | | **No-store** | Dynamic (every request) | ### Data Flow | Source | Pattern | |--------|---------| | Database | Server Component fetch | | API | fetch with caching | | User input | Client state + server action | --- ## 3. Routing Principles ### File Conventions | File | Purpose | |------|---------| | `page.tsx` | Route UI | | `layout.tsx` | Shared layout | | `loading.tsx` | Loading state | | `error.tsx` | Error boundary | | `not-found.tsx` | 404 page | ### Route Organization | Pattern | Use | |---------|-----| | Route groups `(name)` | Organize without URL | | Parallel routes `@slot` | Multiple same-level pages | | Intercepting `(.)` | Modal overlays | --- ## 4. API Routes ### Route Handlers | Method | Use | |--------|-----| | GET | Read data | | POST | Create data | | PUT/PATCH | Update data | | DELETE | Remove data | ### Best Practices - Validate input with Zod - Return proper status codes - Handle errors gracefully - Use Edge runtime when possible --- ## 5. Performance Principles ### Image Optimization - Use next/image component - Set priority for above-fold - Provide blur placeholder - Use responsive sizes ### Bundle Optimization - Dynamic imports for heavy components - Route-based code splitting (automatic) - Analyze with bundle analyzer --- ## 6. Metadata ### Static vs Dynamic | Type | Use | |------|-----| | Static export | Fixed metadata | | generateMetadata | Dynamic per-route | ### Essential Tags - title (50-60 chars) - description (150-160 chars) - Open Graph images - Canonical URL --- ## 7. Caching Strategy ### Cache Layers | Layer | Control | |-------|---------| | Request | fetch options | | Data | revalidate/tags | | Full route | route config | ### Revalidation | Method | Use | |--------|-----| | Time-based | `revalidate: 60` | | On-demand | `revalidatePath/Tag` | | No cache | `no-store` | --- ## 8. Server Actions ### Use Cases - Form submissions - Data mutations - Revalidation triggers ### Best Practices - Mark with 'use server' - Validate all inputs - Return typed responses - Handle errors --- ## 9. Anti-Patterns | ❌ Don't | ✅ Do | |----------|-------| | 'use client' everywhere | Server by default | | Fetch in client components | Fetch in server | | Skip loading states | Use loading.tsx | | Ignore error boundaries | Use error.tsx | | Large client bundles | Dynamic imports | --- ## 10. Project Structure ``` app/ ├── (marketing)/ # Route group │ └── page.tsx ├── (dashboard)/ │ ├── layout.tsx # Dashboard layout │ └── page.tsx ├── api/ │ └── [resource]/ │ └── route.ts └── components/ └── ui/ ``` --- > **Remember:** Server Components are the default for a reason. Start there, add client only when needed.