Use bundle-size-review

Find what makes a JavaScript bundle heavy and what can safely come out, from the bundler's stats file (webpack stats.json, an esbuild metafile, or the…

Find what makes a JavaScript bundle heavy and what can safely come out, from the bundler's stats file (webpack stats.json, an esbuild metafile, or the rollup-plugin-visualizer raw-data JSON that Vite builds use) read together with the repo around it (package.json, .browserslistrc, the lockfile, the bundler config and the source files that import the heavy modules). Gives each entry's first-load JavaScript in the exact bytes the stats record, kept apart from lazy chunks; finds whole-library imports, CommonJS packages that can't be tree-shaken, packages bundled twice and polyfills the browser targets don't need; names the import chain that pulls each module in before suggesting a removal; and, given before and after stats, says what grew, why, whether it lands in the first load and which per-entry budget would have caught it.

Reach for it when the user says "why is our bundle so big", "what can we cut from the bundle", "review this stats.json", "why is lodash or moment in our bundle", "the bundle grew in this PR", or "set a bundle size budget".

Install it

npx skilldrop-cli install bundle-size-review                 # Claude Code, your user folder
npx skilldrop-cli install bundle-size-review --project       # Claude Code, this repo
npx skilldrop-cli install bundle-size-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Frontend pack: --pack frontend installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "why is our webpack bundle so big? stats.json attached"
• "what can we cut from the Vite bundle, I've got the visualizer raw-data json"
• "this PR made main.js grow by 80 KB, here's the esbuild metafile from before and after, what grew?"
• "why is moment in our bundle when nothing imports it?"
• "we have two versions of date-fns in the bundle, which dependency pulls in the second one?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "here's our Lighthouse report, why is LCP 4.8 seconds on mobile?"
• "Dependabot wants to bump webpack from 5.88 to 5.94, is the PR safe to merge?"
• "review my PR that adds the CSV export button before I merge it"

If another skill answers instead, ask for this one by name: "use bundle-size-review".

Check what you get

A good result:

• The first line answers the question in the person's terms, with the exact byte figures from the stats.
• The repo was read: targets, versions and importing files are cited by file name; nothing is called absent without having been looked for.
• Each fix is an exact edit to a named file; files are changed only when the user asked for changes.
• The guard is real configuration for a tool that exists, with no invented flag, script or key.
• One unit system, bytes with kB = 1000, and the kind of size (module, emitted, post-bundle, compressed) is named once.
• Compressed figures are measured or absent, never estimated into the lead.
• Initial and lazy are kept apart, and a lazy chunk is never ranked above an initial-chunk fix.
• Every suggested removal names its import chain and is valid for the installed version; no downgrades, no APIs the installed major lacks.
• Duplicates name both paths, both versions and who asks for which range, and a major-version override is flagged as a change to test.
• A per-entry budget closes the reply, with a threshold that passes the good build and fails the bad one.

See a worked example

• larkspur sparkline

Use something else when

• Reading a Lighthouse report for what slows the page (LCP, INP, CLS, render-blocking requests): use web-performance-review
• Choosing SSR, static or client rendering per route to ship less JavaScript: use rendering-strategy
• Deciding whether a dependency bump PR is safe to merge: use dependency-upgrade-review
• Reviewing the application code in a PR for correctness: use pre-merge-review
• Server or API response time, database queries, or backend memory

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: dependency-upgrade-review, pre-merge-review, rendering-strategy, web-performance-review

Edit this page on GitHub · View source