next-partial-prefetching-adoption

next-partial-prefetching-adoption

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 <Suspense>: 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.