Review Next.js App Router rendering-mode selection (static / ISR / dynamic) and fetch() / Data-Cache configuration without re-litigating component architecture, styling, or Pages Router APIs in every response. This skill exists so caching-staleness and cross-user data-leakage risk stay the focus, and so those adjacent concerns stay out of scope.
Use this skill when the user asks to:
\nDo not use this skill for:
\ngetStaticProps / getServerSideProps) — different API surface; do not apply App Router fetch()-cache guidance to it,fetch() involved,react-component-architecture-review./vercel/next.js with resolve-library-id before citing any caching-default claim.fetch() caching default, read the repo's package.json to confirm the installed Next.js major version, then call query-docs scoped to that version. Next's fetch() caching default changed between Next 14 (cache: 'force-cache' default) and Next 15 (uncached by default; GET Route Handlers also uncached by default). A default claim verified against one major must never be reused for another.use cache / Cache Components model (Next 15.x canary / Next 16 opt-in via the top-level cacheComponents config, which replaced the removed experimental.dynamicIO/experimental.useCache flags), treat that as a distinct caching paradigm from the classic fetch()-options model — do not mix cacheLife/cacheTag guidance with classic next: { revalidate, tags } guidance in the same finding without confirming which model the route actually uses.revalidateTag(tag) accepts a second, version-sensitive options.profile argument in newer releases: profile: \"max\" marks the tag stale for background stale-while-revalidate on next visit (the currently recommended pattern); omitting it schedules an immediate expire-on-next-request, which current docs mark as deprecated in favor of profile: \"max\" or updateTag. Confirm which signature the installed version supports via query-docs before recommending one — do not assume the two-argument form exists on an older major.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.package.json to confirm the installed Next.js major version and whether the deployment target is Vercel or self-hosted. Do not assert a caching default or a platform-specific cache primitive (e.g. Vercel Data Cache persistence across deployments) without confirming both.fetch() calls. A route with no revalidate export, no dynamic export, and no dynamic API (cookies(), headers(), searchParams) usage defaults to static; do not assume dynamic without evidence.export const dynamic = 'force-dynamic' on a whole route to fix a leakage finding without first checking whether a scoped cache: 'no-store' on the offending fetch() call, or a user-scoped cache tag/key, is sufficient. Route-wide force-dynamic is a real TTFB/cost overcorrection.fetch() calls, scoped to a single render pass) with the Data Cache (persists across requests/deployments). A finding that treats memoization as if it persisted across users is wrong on its face.fetch() call, header, or example data as a HIGH-severity finding requiring immediate escalation, not a caching note.Load these only when needed:
\ngenerateStaticParams + revalidate, or on-demand revalidation via revalidatePath/revalidateTag.next: { tags }, revalidateTag) is present in the diff.Return, at minimum:
\n