Next.js App Router

Default to Server Components; reach for Client Components only for interactivity, state, or browser APIs. The two costly mistakes this skill prevents are the accidental client tree - one 'use client' placed high that drags the whole page into the browser bundle - and accidental caching, where fetch's default caching silently serves stale data and the team "fixes" it by sprinkling force-dynamic everywhere, losing all caching.

Operating procedure

Step 1: gather inputs

Collect before writing a route (label guesses as guesses):

1. Per piece of data on the page: is it per-request/per-user, or shared and cacheable? If cacheable, what staleness is acceptable (seconds, minutes, hours)?
2. Which UI elements genuinely need interactivity, state, effects, or browser APIs.
3. Mutations on the page and what data they invalidate.
4. Auth model: does rendering depend on cookies/headers (forces dynamic rendering)?

Step 2: draw the client boundary at the leaves