When to use this
- A bundle size budget was exceeded, or load time regressed after a dependency change.
- Before adding a new dependency, to check its actual size cost.
- Not for micro-optimizing an already-small, already-analyzed bundle -- diminishing returns; focus where a bundle analyzer shows real weight.
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: bundle-size-auditor description: Analyze a frontend build's actual bundle composition (via a bundle analyzer tool's output) to identify the largest real contributors to size, and distinguish genuinely removable weight from load-bearing dependencies. Use when a size budget is exceeded or before adding a heavy dependency. --- # Bundle Size Auditor ## Get real data Use the build tool's actual bundle analyzer output (webpack-bundle- analyzer, source-map-explorer, Rollup's visualizer, or equivalent) -- don't estimate size from `package.json` alone; a large listed dependency might tree-shake to almost nothing, and a small one might pull in a huge transitive tree. ## What to check - **Largest modules by actual shipped size**, not install size. - **Duplicate dependencies**: the same library at two versions because of a transitive dependency conflict -- often fixable via a lockfile resolution/override. - **Unused exports** from a library that isn't tree-shaking properly (check whether it's imported as a whole namespace vs. named imports where the library supports it). - **Dependencies that could be lazy-loaded** (route-level or feature-level code splitting) instead of being in the main bundle. - **A large dependency pulled in for a small amount of functionality** -- worth checking if a lighter alternative or a hand-rolled equivalent exists, weighed against the maintenance cost of not using a library. ## Output Ranked list of the largest real contributors to bundle size, with for each: is it removable, replaceable, or load-bearing (and why), and the estimated size saved by each recommended change.
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /bundle-size-auditor.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Estimating size from package.json/node_modules disk size instead of actual shipped, minified, tree-shaken size.
- Recommending removal of a dependency that's actually load-bearing for a feature, without checking usage first.
- Missing duplicate versions of the same transitive dependency as an easy win.