Enable Partial Prefetching and walk the app until every link reuses a shared App Shell. This skill sequences the work; per-insight recipes live in the dev overlay fix cards and their docs pages. The
Adopting Partial Prefetching guide
is the canonical reference for the concepts this skill applies.
The one thing that shapes everything below:
these insights surface only in
next dev
, in the dev overlay's Insights tab.
Nothing fails the build. There is no build-only fallback loop — confirming an insight is
cleared
means driving the running app in a browser. But a missing browser gates that verification, not the whole skill: the adoption work is static and runs from the guide, so do the static pass anyway and hand off the live shell check.
Talk to the user in terms of what they'll see — PRs, features, and how the app behaves after — never the insight slugs or step labels. Before you start, tell them briefly what Partial Prefetching changes: a
<Link>
loads a shared App Shell, and
prefetch={true}
no longer prefetches everything the old full prefetch did.
requires
Cache Components on (
cacheComponents: true
).
This is the only hard requirement;
partialPrefetching
depends on it. Full Cache Components adoption is the ideal starting point but not a gate. Nothing in this skill blocks the build, and neither do the prerender insights an unadopted route surfaces, like a leftover
unstable_noStore
or a
cookies()
read outside
they are non-blocking dev signals, expected on any fresh branch off
main
, not a reason to stop. They replace the URL-data insight only on their own route in the
step 3
sweep; the flag-off step 1 audit and its static adoption run regardless. The only thing that actually stops this skill is a build-blocking failure, and anything build-blocking would have been resolved before you reached here. Otherwise fix the prerender insights you hit as inline
next-cache-components-adoption
work, or hand them off, and keep going.
Next.js 16.3 or later.
partialPrefetching
, the
prefetch
route segment config, and the prefetch insights all land there.
A browser you can drive.
Install
next-dev-loop
before starting (
npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-dev-loop
). Install it without asking — it's a tool, not a product change — and don't assume it's blocked: verify a real blocker (no network, no npm, read-only filesystem) before falling back, and name it in your report. Link prefetches fire when a link renders and enters the viewport, and shell validation fires on navigation — neither is reachable from
curl
or the build. If the app is webpack-pinned, drive a browser directly (
agent-browser
, Playwright) — you lose the framework cross-checks, not the insights; they're still in the overlay and the dev log.
A runnable app.
Verification runs against
next dev
for the insight sweep and a production
next build
/
next start
for prefetching (prefetching is prod-only), so the app has to boot in both. If it reads a database or required env at import (e.g. an
env.ts
that throws on a missing
DATABASE_URL
), confirm it starts — with the real environment, or local data you stand up — before step 1. An app that won't run can't be swept or verified.
notes
Show more
Installs
835
Repository
vercel/next.js
GitHub Stars
141.2K
First Seen
Jul 14, 2026
Security Audits
Gen Agent Trust Hub
Pass
Socket
Pass
Snyk
Warn