AI AI Tools Guidebook
Prompt Library

Next.js App Router Review Prompts for Server Components

Next.js App Router code review prompts — server vs client boundaries, server actions, route handlers, fetch caching, revalidation, streaming.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

Generic “review my Next.js code” misses App-Router-specific traps: a stray useState poisoning a server component, cache: 'no-store' accidentally going stale, a server action without revalidation. These 15 prompts each interrogate one App-Router-specific failure mode.

Who this is for

Engineers shipping App Router (Next 13.4+) apps, code reviewers approving server-action PRs, indie devs migrating from Pages Router, teams debugging hydration and caching surprises.

When not to use these prompts

Skip these for Pages-Router code (different model). Skip for static-only marketing sites where App Router’s server features aren’t used.

Prompt anatomy / structure formula

Every App Router review prompt should carry six elements:

  • Role: who the AI plays (architect / SRE / QA lead / release captain).
  • Context: repo / framework / runtime versions / files or diff in scope.
  • Goal: one concrete deliverable — review notes, plan, checklist, test file, handoff doc.
  • Constraints: what AI MUST NOT do (don’t rewrite, don’t auto-format, don’t guess versions).
  • Output format: numbered findings, markdown table, JSON, unified diff, or runnable code.
  • Examples / signal: 1-2 examples of “good” output, or what bad output looks like.

Best for

  • PR review for App Router migrations
  • Pre-launch caching and revalidation audit
  • Server action security review
  • Hydration / boundary debugging
  • Performance regression hunts after Next.js upgrades

15 copy-ready prompt templates

1. Server vs client boundary audit

Run first — boundary bugs cascade.

You are a senior Next.js reviewer. Audit this App Router code for SERVER vs CLIENT boundary violations: (1) files with `"use client"` that should be server (no interactivity), (2) server files importing client-only APIs (window, useState), (3) client components receiving non-serializable props, (4) deep client trees that could be shifted to server. For each: file:line, why it's wrong, the fix. Do not refactor.

2. Server action correctness review

Review every `"use server"` action in this code for: (1) input validation (zod / valibot / manual), (2) auth check at the top of the action, (3) `revalidatePath` or `revalidateTag` after mutation, (4) error handling that returns typed result (not throw), (5) idempotency for retries. Output: action name | finding | severity.

3. Route handler review

Review `route.ts` handlers in `app/api/`: (1) Method handlers (GET/POST/etc) — any missing? (2) Response shape consistency, (3) `dynamic = "force-dynamic"` vs default — is the choice intentional? (4) Auth middleware coverage, (5) CORS for cross-origin. List findings with file:line.

4. Fetch caching audit

Audit every `fetch()` call in server components and route handlers. For each: (1) cache mode (default / no-store / force-cache / revalidate=N), (2) is the choice appropriate for the data freshness needs? (3) any duplicate fetches per request that should be deduped, (4) any user-specific data accidentally cached publicly. File:line evidence required.

5. revalidatePath / revalidateTag coverage

Map every mutation (server action, POST route handler, webhook). For each: (1) Does it call revalidatePath or revalidateTag? (2) Does the tag/path match the data being invalidated? (3) Are there reads that won't see the mutation because they aren't tagged? List gaps as: mutation | should invalidate | currently invalidates.

6. Streaming and Suspense audit

Review use of Suspense boundaries and streaming in this App Router code. Identify: (1) slow data fetches not wrapped in Suspense, (2) loading.tsx files missing where they'd help LCP, (3) waterfalls of awaited fetches that should be parallelized, (4) Suspense boundaries placed too high (whole-page loading) or too low (jittery). Suggest specific Suspense placements.

7. Metadata and SEO review

Audit Next.js metadata (`generateMetadata` + static metadata): (1) every route has a title and description? (2) Open Graph and Twitter card present for shareable routes? (3) `alternates.canonical` set for routes reachable at multiple URLs? (4) Dynamic metadata using the same data as the page (no duplicate fetch)? File:line.

8. Image and asset optimization review

Review `<Image>` usage in this code: (1) `width` and `height` explicit (no layout shift)? (2) `priority` set on above-fold images? (3) `sizes` attribute correct for responsive use? (4) `remotePatterns` in next.config covers all sources? (5) Any `<img>` tags that should be `<Image>`? Output: image | issue.

9. Middleware review

Review `middleware.ts`: (1) matcher config covers the intended routes only (no overmatching)? (2) Auth checks early-return correctly? (3) Header / cookie mutations applied via `NextResponse.next({headers})` rather than mutating request? (4) Any heavy work that should be in a route handler? File:line findings.

10. Cookies and session review

Audit cookie usage across server components, server actions, and route handlers: (1) any reads via `cookies()` in places that force dynamic when static would work? (2) httpOnly / secure / sameSite flags correct? (3) Session reads duplicated per request (should be cached with `cache()`)? (4) Cookies set in server components (illegal — should be in actions / routes)?

11. Error and not-found boundary review

Review `error.tsx`, `global-error.tsx`, `not-found.tsx`: (1) Every route segment with possible errors has one? (2) Error boundaries log to observability? (3) `reset()` functions are wired up? (4) `notFound()` called from data-fetch paths that 404? List missing files and missing handlers.

12. Parallel and intercepting routes review

If this app uses parallel routes (`@slot`) or intercepting routes (`(.)folder`), audit: (1) Default slots present where required? (2) Slot loading / error files in place? (3) Intercepting routes degrade correctly when accessed directly via URL? If no parallel/intercepting routes exist, say so — do not invent.

13. dynamic / static rendering audit

For each route segment, determine rendering mode (static / dynamic / ISR). Output a table: route | mode | trigger (cookies()/headers()/searchParams/fetch no-store) | intentional? Flag routes that became dynamic unintentionally — those are usually perf regressions.

14. App Router upgrade compat review

Use after bumping the Next.js minor/major.

I just upgraded Next.js from {fromVersion} to {toVersion}. Review this code for breakage / new-best-practice opportunities specific to that upgrade: deprecated APIs in use, new caching defaults, new metadata or Image features, changed TypeScript types. Output: file | change | severity (breaking / warning / nice-to-have).

Variables to swap: fromVersion, toVersion — e.g., 14.0, 15.1

15. App Router findings → fix PR plan

Run last to convert findings into a PR sequence.

Take the findings from previous App Router reviews and group them into 3-5 PRs sized for solo review (each < 400 LOC diff). For each PR: title, files touched, dependency on other PRs, rollback plan. Output as markdown.

Common mistakes

  • Reviewing as if it were Pages Router — App Router has different caching, data fetching, and component models.
  • Missing revalidatePath / revalidateTag after mutations — stale reads in production.
  • Marking everything "use client" — kills the server component benefit; review for unnecessary client boundaries.
  • Accepting dynamic = "force-dynamic" without questioning — often hides a cache misconfiguration.
  • Skipping middleware matcher review — overmatching middleware tanks edge perf.
  • Not checking server actions for auth at the top — server actions are publicly callable.
  • Ignoring cookies() / headers() calls that force dynamic rendering of pages meant to be static.

How to push results further

  • Always start a Next.js review with the server/client boundary pass (template 1) — other findings cascade from there.
  • Demand file:line evidence and the exact import that triggered the issue.
  • Run cache audit per route, not globally — caching expectations differ by route type.
  • For server actions, require the reviewer to call out auth, validation, and revalidation explicitly.
  • Use the upgrade-compat prompt every time you bump Next.js — it catches default changes (caching, fetch).
  • Track findings in a checklist and re-run after each fix PR — caching bugs love to come back.
  • Pair human review with next build && next start perf comparison — review prompts don’t catch real LCP regressions.

FAQ

  • Does this work for Pages Router too?: No — the model is different. Use generic React review prompts for Pages Router code.
  • How do I scope a server action review when the action calls many helpers?: Paste the action file plus the immediate helpers it calls. Don’t paste the whole repo — focus matters more than coverage.
  • Will AI know about the latest Next.js version?: Specify the version in the prompt. AI knowledge cutoffs vary; for very recent releases, also paste the relevant changelog snippet.
  • How do I review streaming behavior without running the app?: Static review catches structure (Suspense boundaries, await ordering). For real streaming behavior, you need profiling — use these prompts for code-shape issues only.
  • Can I run all 15 in one prompt?: You can but findings will blur. Run boundary first, then caching, then everything else.
  • What about Edge runtime?: Add to the prompt: “Some routes run on Edge — flag Node-only APIs used in Edge-runtime files.”

Tags: #Prompt #Coding #Next.js #Code review

Related Articles