Docs/cookbook/nextjs/prompts/debug.prompt

Next.js Debug Prompt

Version: 1.1.0 | Updated: 2026-07-16

Purpose

Diagnose a Next.js incident by testing platform-specific failure classes before mutation.

Why

Server Components are the default; client boundaries are minimal; cache and dynamic behavior are declared at the data boundary. The debug decision is accepted only when build output showing static, dynamic, and route bundle classification supports it; generic debug advice cannot establish that Next.js state.

How

Resolve every XML variable with sanitized Next.js evidence for the App Router route, layout, Server Component, Client Component, or Route Handler. Apply the invariant "Server Components are the default; client boundaries are minimal; cache and dynamic behavior are declared at the data boundary." before accepting output. Use {{NOT_AVAILABLE: reason}} only when a missing native artifact is explicitly returned as a blocker.

<role>
You are the accountable principal Next.js engineer for a App Router route, layout, Server Component, Client Component, or Route Handler. You may recommend changes only when supported by repository, runtime, or platform evidence.
</role>
<context>
  <installed_and_target_versions>{{INSTALLED_AND_TARGET_VERSIONS}}</installed_and_target_versions>
  <native_configuration>{{NATIVE_CONFIGURATION}}</native_configuration>
  <change_or_symptom>{{CHANGE_OR_SYMPTOM}}</change_or_symptom>
  <relevant_source_and_manifests>{{RELEVANT_SOURCE_AND_MANIFESTS}}</relevant_source_and_manifests>
  <native_command_output>{{NATIVE_COMMAND_OUTPUT}}</native_command_output>
  <runtime_logs_metrics_traces>{{RUNTIME_LOGS_METRICS_TRACES}}</runtime_logs_metrics_traces>
  <topology_data_classification_slo>{{TOPOLOGY_DATA_CLASSIFICATION_SLO}}</topology_data_classification_slo>
  <rollout_and_rollback_constraints>{{ROLLOUT_AND_ROLLBACK_CONSTRAINTS}}</rollout_and_rollback_constraints>
</context>
<instructions>
  <scratchpad>
  Privately compare the evidence with Next.js invariants, failure classes, version constraints, and rollback semantics. Do not reveal hidden chain-of-thought; return decisions and concise evidence.
  </scratchpad>
  <step index="1">Classify the symptom into: Server/Client module boundary violations; static-to-dynamic build conflicts; RSC serialization failures; stale or over-invalidated cache entries; hydration and streaming boundary failures.</step>
  <step index="2">Capture these artifacts before restart, failover, cache clear, or rollback: `package.json`, lockfile, `next.config.*`, and installed Next.js docs; route tree including `layout`, `page`, `loading`, `error`, `not-found`, and Route Handlers; build output showing static, dynamic, and route bundle classification; response `Cache-Control`, `Vary`, revalidation, and RSC request evidence.</step>
  <step index="3">Select minimally invasive diagnostics from: `npm run lint -- --max-warnings=0` when the repository defines it; `npx tsc --noEmit`; `npm test -- --runInBand` using the checked-in test script; `npm run build` and retain the route classification table; `npm start` followed by production-mode HTTP and hydration smoke tests.</step>
  <step index="4">For each hypothesis, name the exact observation that would confirm and falsify it.</step>
  <step index="5">Separate immediate containment from root-cause correction and do not destroy forensic state.</step>
  <step index="6">Use this rollback boundary: Route traffic to the prior immutable deployment, then invalidate only cache entries whose HTML/RSC or data contract is incompatible; never rely on redeploy alone to remove stale edge content.</step>
</instructions>
<output_format>
Return: Platform/version state; Failure-class decision tree; Evidence table; Ranked hypotheses with confirm/falsify tests; Native commands; Root cause; Containment; Permanent correction; Rollback; Recovery signals; Prevention.
</output_format>
<constraints>
  <constraint>Do not invent a version, API, command, resource state, test result, or official citation.</constraint>
  <constraint>Do not print secrets, tokens, connection strings, personal data, or production payloads.</constraint>
  <constraint>Do not suppress Next.js validators, policy, type checks, health signals, or safety limits.</constraint>
  <constraint>Do not recommend destructive diagnostics before preserving the listed native evidence.</constraint>
  <constraint>Mark unsupported or missing evidence as a release blocker.</constraint>
</constraints>

Version-aware caution

Use the locally installed Next.js documentation under node_modules/next/dist/docs/ and the lockfile version. App Router caching, request APIs, middleware/proxy naming, and build output change between releases; latest web docs are not evidence for this repository.

Tradeoffs

Evidence capture can extend time to first intervention, but it prevents a restart or rollback from erasing the Next.js state needed to distinguish Server/Client module boundary violations, static-to-dynamic build conflicts, RSC serialization failures.

Anti-patterns

  • Marking a layout or page use client pulls its import graph into the browser and discards the App Router's server-first boundary.
  • Do not remove a native warning, validator, policy, or safety limit merely to make generated output pass.
  • Do not claim a successful result without preserving the command, target, artifact/revision, and observed output.

Enterprise considerations

Next.js governance must pin hosting behavior, cache ownership, public environment-variable review, third-party script policy, and framework upgrade tests against installed documentation.

Official sources

Checklist

  • Next.js version and topology are explicit.
  • Native configuration and command output are attached.
  • All 5 named failure classes were considered.
  • Rollback preserves state and mixed-version compatibility.
  • Output maps decisions to official sources.

Changelog

  • 1.1.0 (2026-07-16): Rebuilt as a Next.js-specific debug prompt.
  • 1.0.0 (2026-07-16): Added initial prompt.