The Next.js team introduced a bundle-optimizer skill alongside its bundle analyzer. The intended loop is to inspect route-level bundle output, identify expensive imports or client code that can be removed or deferred, and use an agent to help make a change. This combines structured tooling with repository-aware reasoning instead of asking a model to guess which dependency is large.

The analyzer can reveal what is included in a bundle, but it cannot establish by itself that a proposed edit improves user experience. A package may be large yet cached, used on a high-value route, or necessary for a core interaction. Conversely, a small dependency can trigger costly work or delay an important rendering boundary. Any agent suggestion should be tied back to the actual route, loading behavior, and production metrics.

A sound evaluation records a baseline before editing, reviews the dependency and client/server boundary changes, and compares the built output after each change. Then validate with real-user data such as LCP, INP, and JavaScript transfer/parse costs on representative devices. Treat the skill as an investigative assistant; the engineer still decides whether the tradeoff is acceptable.