bundle-analyzerlisted

Inspect a JavaScript/TypeScript production bundle and find where the bytes actually go. The skill builds a stats report, attributes weight to specific modules and packages, and hunts for the patterns that bloat bundles in practice — a 200KB date library imported for one helper, two copies of the same package at different versions, a route that ships eagerly instead of lazily, a polyfill set targeting browsers you dropped years ago, or server-only code that slipped past the client boundary. It returns a ranked list of concrete reductions with the estimated savings of each, so you fix the 80KB win before the 4KB one. ## When to use this skill - A production bundle (or a specific route/chunk) has grown past budget and you need to know exactly what to cut. - You suspect duplicate packages, a heavyweight dependency, or a barrel import dragging in a whole library. - A first-load or main chunk is too big and you want to know what should be code-split or deferred. - You want to confirm dev-only tooling, source maps, or server code is not leaking into the client bundle. > [!NOTE] > Always measure the **production** build, not dev. Dev bundles include HMR runtime, unminified source, and no tree-shaking, so their sizes are meaningless for this analysis. Compare **gzip/brotli** transfer sizes, not raw bytes — that is what users actually download. ## Instructions 1. **Locate the build and detect the bundler.** Identify the toolchain before doing anything — do not guess. Check `packag