skilldrop-cli 0.16.36 → 0.16.38

package/packs/frontend/pack.json

@@ -1,5 +1,5 @@
 {
-  "description": "For frontend engineers and the people who review their pages: read a Lighthouse report for what actually slows the page for real users, and choose how each route is rendered from what it needs.",
+  "description": "For frontend engineers and the people who review their pages: read a Lighthouse report for what actually slows the page, find what makes a JavaScript bundle heavy, and choose how each route is rendered from what it needs.",
   "display_name": "Frontend",
   "keywords": [
     "frontend",
@@ -28,9 +28,10 @@
     "recovery": "If the reply leads with the lab score or a generic checklist, ask for it by name (\"use web-performance-review\") and include the PageSpeed Insights JSON, which carries the field data."
   },
   "journey": {
-    "when": "A page is slow, or you're deciding how a new app's routes should be rendered.",
+    "when": "A page is slow, a bundle grew, or you're deciding how a new app's routes should be rendered.",
     "you_bring": [
       "a Lighthouse or PageSpeed Insights JSON, with field data if you have it",
+      "the bundler's stats file (webpack stats.json, an esbuild metafile or the Vite visualizer JSON)",
       "the app's routes, how fresh each one's data must be, and the framework"
     ],
     "steps": [
@@ -40,6 +41,11 @@
         "you_get": "A route table: how each page is rendered and cached, what invalidates it, and what it shows when its data source is slow.",
         "decide": "Which routes change rendering mode first."
       },
+      {
+        "skill": "bundle-size-review",
+        "you_do": "Hand over the stats file, and the one before the change if a PR made it grow.",
+        "you_get": "The compressed JavaScript each entry loads before first render, what pulls in each heavy module, duplicates, and what can safely come out."
+      },
       {
         "skill": "web-performance-review",
         "you_do": "Hand over the Lighthouse or PageSpeed Insights JSON, with field data.",
@@ -47,7 +53,7 @@
         "decide": "Which fix ships first, and how you'll measure it in the field."
       }
     ],
-    "you_end_with": "Pages rendered the way their data needs, and fixes chosen by what real users feel."
+    "you_end_with": "Pages rendered the way their data needs, a bundle with nothing heavy in the first load that doesn't need to be, and fixes chosen by what real users feel."
   },
   "requires": [
     "core"

package/packs/frontend/skills/bundle-size-review/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: bundle-size-review
+description: 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. Use 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".
+---
+
+# bundle-size-review
+
+Reads the bundler's own record of what it built, and the repo files that decide what it should have built, and answers two questions: what does the browser download before the first screen, and which of it can come out without breaking something. The stats file and the repo are the evidence; an analyzer treemap and `du -sh node_modules` are not. Page-load performance from a Lighthouse report (LCP, INP, CLS) is `web-performance-review`; choosing how a route is rendered is `rendering-strategy`. Whether to merge a dependency bump is `dependency-upgrade-review`; reviewing the code change itself is `pre-merge-review`.
+
+## How to respond
+
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** The repo outranks the stats file on what the build is for, and nothing is called missing without having been looked for. Browser targets, installed versions and how a module is imported live in the files next to the stats; read them, cite them, and rank every fix by what the first screen waits for.
+
+1. **Get the stats file, asking once.** One of: webpack `stats.json`, an esbuild metafile, or rollup-plugin-visualizer output with `template: "raw-data"` (Vite). A treemap screenshot is not enough. Ask for the file with the command that makes it:
+   ```bash
+   npx --no webpack --mode production --json=stats.json
+   npx --no esbuild src/main.tsx --bundle --minify --splitting --format=esm --outdir=dist --metafile=meta.json
+   ```
+   For Vite, the visualizer config is in [`reference.md`](reference.md).
+
+2. **Run the script before reading anything by hand.** It sizes every entry's initial JavaScript and each lazy chunk, lists the largest modules and packages, finds packages installed at more than one path, flags whole-library CommonJS imports, locales and polyfills, prints the chain for each `--why`, and reads the project around the stats file (the stats folder, its parent or grandparent, or `--root`):
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/bundle_stats.py" stats.json --why lodash --budget main=320kB
+   # Other IDEs (from the skill folder)
+   python3 scripts/bundle_stats.py stats.json --why lodash --budget main=320kB
+   ```
+   `--compare before.json after.json` diffs two builds; `--dist dist/` gzips the built files so compressed sizes are measured; `--json` for machine output; `-` reads stdin. Exit 1 means a budget failed, 2 bad input. With no script runtime, follow the field-by-field method in [`reference.md`](reference.md) and show the arithmetic.
+
+3. **Read the repo before concluding anything about it.** The script's "Project files" block lists what it found and what is absent: `package.json` (ranges, `browserslist`), `.browserslistrc`, the lockfile, `webpack.config.*` / `vite.config.*` / `build.mjs` (`target`, existing budgets), `tsconfig.json` (`target`), and the source files that import each bundled package. Open the source files named in the chains and the configs it lists, and cite them by name in the reply. A claim that a file does not exist comes only after listing the folder (`ls -a`, a glob), and is worded as what was looked for.
+   - ✅ *"`.browserslistrc` targets Safari 15 and Chrome 100, and `vite.config.ts` builds for `safari15`, so four of the five polyfills in `src/setup/polyfills.ts` are dead."*
+   - ❌ *"There is no browserslist, so the polyfills can't be judged."* (said without looking; the file was there)
+
+4. **Lead with the exact sizes the stats give, and say which size it is.** Copy the bytes from the stats, never round them into a new figure first. One unit system for the whole reply: bytes, with kB = 1000 bytes for readability (*"288,640 bytes (288.6 kB)"*); no KiB, KB or MB mixed in. Say once what the number is: webpack module `size` is before minification; a webpack asset size is the emitted file, minified and uncompressed; esbuild `bytes` and `bytesInOutput` are post-bundle (minified when `--minify` is on), uncompressed; the visualizer gives rendered length, plus gzip and brotli when enabled. Leave `.map` outputs out of every count.
+   - **Compressed sizes are secondary and never invented.** Quote them only when measured (the built files under `--dist`, or the visualizer's gzip/brotli). Otherwise give the command that measures them after a build, in plain words: gzip the entry's files with `gzip -9c` and count the bytes with `wc -c`.
+   - ✅ *"The `app` entry is 288,640 bytes of minified JavaScript before compression (esbuild output bytes)."* ❌ *"app is about 92 KB gzipped"* (no built files were given: that number is a guess).
+
+5. **Separate initial from lazy, then rank.** Order: (a) what can come out of or shrink in the initial chunks, (b) duplicates in the initial chunks, (c) lazy chunks last, each named with the route that loads it. ✅ *"monaco-editor is the biggest library (2,104,300 bytes), but only `routes/Editor.tsx`, loaded with `import()`, pulls it in, so it does not delay the first screen."* ❌ *"Replace monaco-editor first, it is the biggest dependency."*
+
+6. **Name why a module is there before suggesting it go.** Give the chain from the entry and whether the app imports it directly or a dependency does. A transitive module does not leave when its line leaves `package.json`. Read the importing source file when it is on disk: `import * as Flags from "worldflags"` read as `Flags[code]` keeps every export, and the fix is explicit imports or a code-to-component map of the ones in use (found with a search for `<Flag code=` when the callers aren't given).
+
+7. **Find what tree-shaking failed to remove.** Patterns, replacements and what to check are in [`reference.md`](reference.md): whole-library CommonJS imports (`import _ from "lodash"`), barrel files and namespace imports, CommonJS packages in initial chunks (a prebuilt `react-dom.production.min.js` is not a finding), side-effectful modules, locale bundles.
+   - **Polyfills against the targets:** the script checks each bundled core-js module against the browser targets it found and lists the files that use a still-needed feature. Drop the polyfills every target has natively; keep any feature a target lacks that the code uses, and name the file. ✅ *"Keep `es.array.find-last`: Safari 15 lacks `Array.prototype.findLast` (it arrived in 15.4) and `src/lib/history.ts` calls it; the other four can go (4,210 bytes)."* With no targets in any file, this goes under To confirm.
+
+8. **Make every fix safe for the installed versions.** Read the installed version (lockfile) and declared range (`package.json`) before naming an API, an import path or a version. Never suggest a downgrade, an option or an export the installed major doesn't have, or a flag the tool doesn't take. For a duplicate, name both install paths, each version and who asks for which range (the script reads them from the lockfile; without one, give `npm ls <package>`). Forcing one copy with `overrides` across a major version is a change to test, not a free removal; whether a newer dependent accepts the newer major is checked with network access, never asserted:
+   ```bash
+   npm view @harbor/calendar versions
+   npm view @harbor/calendar@latest dependencies
+   ```
+   ✅ *"@harbor/calendar 2.3.0 asks for date-fns ^2.29.0 while the app uses 3.6.0, so two copies ship (18,400 + 5,200 bytes). An override to 3.x is a major jump for the calendar; check with `npm view` whether a calendar release accepts date-fns 3 first."* ❌ *"Upgrade the calendar to 3, which uses date-fns 3"* (not in the input) or *"pin date-fns to 2.x"* (downgrades the app).
+
+9. **For before and after, attribute the growth.** Run `--compare`. Lead with the change in each entry's initial JavaScript, then the lazy chunks; name the modules that moved and the chain that brought them; call out anything that moved from lazy to initial. When someone compared totals, show both numbers side by side: the total barely moved because bytes changed place.
+
+10. **Set or check a budget per entry.** The guard is a limit on each entry's initial JavaScript, not on the total. Pick a threshold between the good build and the bad one (the current figure plus about 5%, or the team's target), in the same unit as the tool that enforces it: webpack `performance` with `hints: "error"` and `maxEntrypointSize` counts emitted bytes, minified and uncompressed; size-limit measures compressed size from the built files itself. When the stats carry pre-minification module sizes, say the emitted figure comes from one build before fixing the number. State that a total-size limit misses a lazy-to-initial move and fails on harmless lazy growth.
+
+11. **Reply short, in one message, in this order.**
+    - **First line answers the question in the person's words.** ✅ *"Yes, the reviewer is right: echarts moved from the lazy reports chunk into vendors, so the first load grew from 311,282 to 803,674 bytes (+492,392) while the total fell 1,949."* ❌ *"This confirms it."* / *"Let me break this down."*
+    - **Then the fixes, numbered by first-load impact:** what it is, the chain, the change, what to check after. Two to four lines each.
+    - **One line on lazy chunks** when they matter to the question.
+    - **Then the guard:** the per-entry budget that would have caught it, with its threshold.
+    - **"To confirm"** for what only the user can answer; omit it when empty. No module tables, no full package lists, no tool output pasted in, no flags or options that don't exist. About 250 words.
+
+**Non-interactive runs** (subagent, CI, headless): with no stats file, emit `BLOCKED: need the bundler stats file (webpack --json, esbuild --metafile, or rollup-plugin-visualizer raw-data)`. With only built files or a treemap screenshot, report the per-file sizes and emit `BLOCKED: need the stats file to say what is inside each chunk`. Browser targets absent from every project file (after looking) become `[assumption] browser targets unknown; polyfill findings unconfirmed`; a missing budget becomes `[assumption] budget set at the current initial size plus 5%`.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md): producing stats for each bundler, what each format's sizes mean, the project files read and how, replacements for the usual heavy packages with what to check, duplicates and versions, budgets in CI
+- [`scripts/bundle_stats.py`](scripts/bundle_stats.py): stdlib reader for webpack, esbuild and visualizer stats plus the project around them; bytes throughout, chains, duplicates with lockfile versions, polyfills against targets, `--compare`, `--budget` (exit 1 over budget, 2 bad input)
+- [`examples/larkspur-sparkline.md`](examples/larkspur-sparkline.md): worked example, a PR that moved a chart library from a lazy chunk into the first load while the total stayed flat
+
+## Quality bar
+
+- **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.
+- **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.
+
+## When to use this skill
+
+- ✅ "Why is our bundle so big?" with a webpack, esbuild or Vite stats file
+- ✅ A PR made the bundle grow and someone wants to know what and why, from before and after stats
+- ✅ "Why is lodash / moment / core-js in our bundle?" or "can we drop this package?"
+- ✅ Two versions of a package in the bundle, or one module in several chunks
+- ✅ Setting or checking a bundle size budget per entry in CI
+
+## When NOT to use this skill
+
+- ❌ 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
+
+## Anti-patterns to avoid
+
+- ❌ **"There is no browserslist" without listing the folder.** `.browserslistrc`, `package.json` and the build config's `target` all name targets.
+- ❌ **Leading with estimated gzip numbers.** The stats give exact bytes; lead with those.
+- ❌ **Mixing KB, KiB and MB.** Pick bytes and kB = 1000 and keep them.
+- ❌ **Leading with the biggest package.** The biggest is often behind a route nobody opens on the first screen.
+- ❌ **Adding up every chunk, or counting `.map` files.** The first load is the entry's initial chunks.
+- ❌ **"Remove X" without the chain,** or a fix the installed version can't take.
+- ❌ **Forcing a nested copy to the app's major and calling it safe.**
+- ❌ **A total-size budget as the only guard.** It misses a lazy-to-initial move.
+- ❌ **Openers and leftovers:** "This confirms it", pasted tool output, flags that don't exist.

package/packs/frontend/skills/bundle-size-review/evals/eval_queries.json

@@ -0,0 +1,12 @@
+[
+  { "query": "why is our webpack bundle so big? stats.json attached", "should_trigger": true },
+  { "query": "what can we cut from the Vite bundle, I've got the visualizer raw-data json", "should_trigger": true },
+  { "query": "this PR made main.js grow by 80 KB, here's the esbuild metafile from before and after, what grew?", "should_trigger": true },
+  { "query": "why is moment in our bundle when nothing imports it?", "should_trigger": true },
+  { "query": "we have two versions of date-fns in the bundle, which dependency pulls in the second one?", "should_trigger": true },
+  { "query": "set a bundle size budget per entry that CI can check", "should_trigger": true },
+  { "query": "here's our Lighthouse report, why is LCP 4.8 seconds on mobile?", "should_trigger": false },
+  { "query": "Dependabot wants to bump webpack from 5.88 to 5.94, is the PR safe to merge?", "should_trigger": false },
+  { "query": "review my PR that adds the CSV export button before I merge it", "should_trigger": false },
+  { "query": "should the product pages be server-rendered or statically generated?", "should_trigger": false }
+]

package/packs/frontend/skills/bundle-size-review/evals/evals.json

@@ -0,0 +1,108 @@
+{
+  "skill_name": "bundle-size-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "The dispatch dashboard is slow to open on our technicians' phones, and the bundle analyzer treemap shows echarts as the giant block. I ran webpack with --json and attached stats.json, plus package.json and src/utils/format.js. What's making the bundle heavy, and what should we cut first?",
+      "assertions": [
+        "Opens with the first-load fix, not echarts: lodash is imported whole (import _ from \"lodash\", the CommonJS lodash/lodash.js, 544,098 bytes of webpack module size, before minification) into the initial vendors chunk through src/utils/format.js",
+        "Says echarts and zrender sit in the lazy reports chunk that src/routes.js loads with import(), so they do not delay the first screen, and ranks them below the initial-chunk fixes",
+        "Measures the main entry's initial JavaScript as the vendors and main chunks, 311,282 bytes of emitted JavaScript (301,412 + 9,870, minified, before compression), in one unit system, and does not present the sum of all chunks as what the first load downloads. It gives no compressed figure as measured: any gzip number is labelled an estimate or replaced by a way to measure it after a build",
+        "Finds date-fns installed twice, naming node_modules/date-fns (pulled in by src/utils/format.js) and node_modules/@tidal/daterange-picker/node_modules/date-fns (pulled in by the picker, a CommonJS copy), and proposes aligning the versions so one copy is installed rather than removing date-fns from the app",
+        "Gives the lodash fix from the functions format.js actually uses (groupBy, sortBy, round) as per-method imports, lodash-es named imports or native code, and notes from the stats that format.js is the only importer",
+        "Does not promise the pre-minification module size as the download saving, and says the saving is confirmed by rebuilding and comparing",
+        "Proposes a per-entry budget on the main entry's initial JavaScript, with a threshold in the unit of the tool that enforces it",
+        "Does not invent the version of the nested date-fns copy or the picker's required range, which are not in the input, and says how to read them (for example npm ls date-fns)",
+        "Keeps the reply lean: the answer first, a short numbered list of fixes, no full module or package table"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "PR #318 on our order console failed the bundle-size check; PR.md has the CI output and the author's comment. meta-before.json and meta-after.json are the esbuild metafiles from main and from the PR branch. Should we raise the limit like the author suggests? What actually grew?",
+      "assertions": [
+        "Answers first that raising the total limit is the wrong fix, because the change that slows the first load is in the main entry, not the lazy Analytics route",
+        "Attributes the first-load growth to papaparse (19,480 bytes) and file-saver (2,690 bytes) imported statically by src/components/ExportButton.tsx through src/components/Toolbar.tsx, 23,344 bytes added to the main entry's initial JavaScript (159,050 to 182,394)",
+        "Attributes the larger growth, 195,230 bytes, to @tidal/heatmap in the Analytics chunk that src/App.tsx loads with import(), and says it does not land in the first load",
+        "Recommends loading papaparse and file-saver with a dynamic import when the export button is clicked, and says what to check after (the export still downloads a correct CSV)",
+        "Proposes a per-entry budget on the main entry's initial JavaScript (plus, optionally, a separate figure for the Analytics route) and says that budget would have caught this PR's first-load growth while a total-size limit only flagged the lazy growth",
+        "Gives no invented compressed sizes: the metafile bytes are minified and uncompressed, and with no built files any gzip figure is labelled an estimate or replaced by a way to measure it",
+        "Does not invent load times, Lighthouse scores, user counts or sizes that cannot be computed from the metafiles and PR.md",
+        "Keeps the reply short and answer-first, without a table of every chunk and module"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're on Vite. stats.json is the rollup-plugin-visualizer raw-data output (gzip and brotli sizes on), and package.json is attached. moment is by far the biggest thing in our bundle. Can we just remove it? And what else is making the first load heavy? We'd like the first load under 60 KB gzipped.",
+      "assertions": [
+        "Answers first that moment cannot just be removed: the app does not import it; @tidal/react-dates does, through src/pages/BookingCalendar.tsx, so deleting it from package.json would not change the bundle",
+        "Says moment (moment-with-locales, 488,140 bytes rendered) is in the lazy BookingCalendar chunk loaded by import() from src/routes.tsx, so it is not part of the first load",
+        "Names the way to shrink it (replace the date picker with one built on a smaller date library or a native input, or keep the picker and drop the bundled locales) and what to check (formats, locales and time zones the calendar uses)",
+        "Identifies the core-js polyfills from import of core-js/stable in src/main.tsx (58,250 bytes rendered, 21,454 bytes gzipped per the visualizer) in the initial index chunk, and checks them against the browserslist in package.json (Chrome and Edge 111, Firefox 115, Safari 16.4), which have these features natively",
+        "Measures the first load as 75,974 bytes gzipped across the index and vendor chunks, from the visualizer's figures, says it is over the 60 KB target and that removing core-js brings it to about 54,500 bytes",
+        "Does not present react-dom as something to remove",
+        "Does not invent which locales the app needs, the picker's internals, or a moment version beyond what package.json says",
+        "Keeps the reply short and answer-first"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-20",
+      "prompt": "Our size bot flagged PR #482 on the support portal (it adds a Reply box under each ticket on the Home page, src/components/CommentBox.jsx) and says main grew a lot. But I diffed the dist folder totals and it's only about +3 KB, so I think the bot is comparing the wrong thing. Before and after webpack stats are in stats/before.json and stats/after.json. Is the bot wrong? And what should we have had set up to catch this properly?",
+      "assertions": [
+        "Answers the question directly up front: the bot is right. The initial `main` chunk grew from 163,000 to 342,900 bytes (+179,900, roughly 176-180 KB), while the all-chunks total grew only 3,400 bytes (347,100 to 350,500), which is the +3 KB the user saw.",
+        "Explains why the total barely moved: the editor code (src/components/RichText.jsx 3,900 + @inkwell/editor 141,200 + inkwell-model 31,400 = 176,500 bytes) moved out of the lazy `compose` chunk (184,100 down to 7,600) into the initial `main` chunk. The bytes went from lazy-loaded to first load; little new code was added.",
+        "Names the import chain from the `reasons` in after.json: src/routes/Home.jsx -> src/components/CommentBox.jsx -> src/components/RichText.jsx -> @inkwell/editor -> inkwell-model. Notes that src/routes/Compose.jsx is still loaded through import(), so the static import from CommentBox is what drags the editor in.",
+        "Recommends a fix that keeps the editor out of the first load: load RichText (or the editor) lazily from CommentBox with dynamic import()/React.lazy, for example when Reply is clicked, which CommentBox.jsx's `open` state already gates. Does not suggest removing the editor, and does not suggest lazy-loading the Compose route, which is already lazy.",
+        "Proposes a per-entry budget on the `main` entry's initial JavaScript (for example webpack `performance.maxEntrypointSize` with `hints: 'error'`, or a size-limit style CI check on main), not a budget on total dist size. The threshold it gives passes 163,000 and fails 342,900, and it says explicitly that a total-size budget would have missed this PR.",
+        "Is accurate about what the numbers are: the stats `size` values are webpack module sizes, not gzip or brotli bytes. Any compressed figure is either labelled an estimate or comes with a command to measure it from the built files (e.g. `gzip -c dist/main.*.js | wc -c`). It does not present invented compressed numbers as measured.",
+        "Invents nothing that isn't in the input: no modules, packages, asset sizes, config files or CI tools described as already present beyond what stats/before.json, stats/after.json and CommentBox.jsx show. For example, it does not claim react-dom or client.js changed.",
+        "Stays proportionate to a 'was the bot wrong, how do we guard this' question. It stays on this regression and the budget and does not turn into a full bundle audit (e.g. recommending replacing react or react-dom)."
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-20",
+      "prompt": "ops dashboard is really slow to open on the warehouse tablets and someone said the bundle is huge. what can we actually cut without breaking anything? esbuild metafile is build/meta.json, rest of the repo is here",
+      "assertions": [
+        "Answers the question directly with a ranked list of what can come out of the first load. It treats first-load JS as the entry output dist/assets/main-7QX2KD.js (421,400 bytes), leaves the .js.map outputs out of the count, and keeps the lazily loaded dist/assets/Exports-M4PZ1A.js (215,500 bytes) separate.",
+        "Ranks glyphset as the biggest first-load cut (198,400 bytesInOutput, about 47% of main) and traces it to src/components/Icon.jsx, where `import * as Icons from 'glyphset'` plus the `Icons[name]` dynamic lookup stops tree-shaking. The fix it gives is explicit imports (or an explicit name-to-component map) of only the icons actually used, plus a way to list the names in use (e.g. grep for `<Icon name=`), since the route sources aren't provided.",
+        "Finds tempora bundled twice: v3.1.0 at node_modules/tempora (ESM, 6,900 bytes in main) and v2.9.1 at node_modules/plotline/node_modules/tempora (CJS, 23,800 bytes, not tree-shaken). It gives the chain src/routes/Overview.jsx -> plotline -> plotline's nested tempora, and notes from package-lock.json that plotline 4.2.0 requires tempora ^2.4.0.",
+        "Treats the tempora dedupe with care: forcing v3 on plotline (npm overrides/resolutions) is a major-version jump and not a safe removal without checking. The response gives a command to run with network access (e.g. `npm view plotline versions` / `npm view plotline@latest dependencies`) and does not claim that a plotline version supporting tempora 3 exists.",
+        "Checks polyfills against .browserslistrc (chrome >= 110, edge >= 110): es.promise, es.array.flat, es.object.from-entries, es.string.replace-all and es.array.at can come out of src/polyfills.js (about 5,950 bytes). es.object.group-by (610 bytes) must stay, because Object.groupBy only shipped in Chrome/Edge 117 and src/utils/groupRows.js uses it. The alternative is to rewrite groupRows and then drop it.",
+        "Does not present sheetsmith (214,300 bytes, the biggest single library) as a first-load cut, because it is only reached through the dynamic import of src/routes/Exports.jsx and sits in the lazy Exports chunk. If it mentions sheetsmith, it says it doesn't affect opening the dashboard.",
+        "Is accurate that the metafile bytes are minified, uncompressed sizes, not gzip or brotli. Any compressed figure is labelled an estimate or comes with a command to measure it after a build. It does not suggest cutting code needed at runtime (react, react-dom, plotline itself).",
+        "Invents nothing that isn't in the input: no package versions, icon names, sizes, files or browser targets beyond what meta.json, package.json, package-lock.json, .browserslistrc and the src files contain. It delivers the cut list instead of stopping to ask clarifying questions first."
+      ]
+    },
+    {
+      "id": 6,
+      "held_out": "2026-10-20",
+      "prompt": "lighthouse keeps dinging our landing page for unused JS. we moved the charts onto a lazy /reports route back in march so i dont get why index-*.js is still ~460k. someone on the team reckons its the echarts locale files? vite build w/ the visualizer plugin, raw data is in stats.json. what can we cut - the german charts have to keep working tho",
+      "assertions": [
+        "Names the import chain that keeps ECharts in the entry chunk assets/index-C7qK2mPa.js despite the lazy route: src/main.tsx -> src/i18n/index.ts -> src/i18n/chartLocales.ts -> echarts/core (imported for registerLocale) -> echarts/lib/core/echarts.js and zrender.",
+        "Corrects the team's guess with numbers: the six registered locale files (DE, FR, ES, JA, PT-br, KO) are only about 8.2 KB gzip (8,244 B), while ECharts core + zrender + tslib in the entry total about 67.6 KB gzip (67,604 B), close to half the entry's ~147.4 KB gzip (147,431 B, the sum of per-module gzipLength).",
+        "Explains that the ~460k figure is the uncompressed size (the entry's renderedLength sums to 465,132 B), gives first-load JavaScript in compressed terms (~147 KB gzip), and keeps the lazy Reports chunk (assets/Reports-Bf41xQ9e.js, ~40.4 KB gzip / 40,414 B) separate from that figure.",
+        "Recommends moving the chartLocales import / registerLocale call off the entry path, into src/pages/Reports.tsx or a module only Reports imports, so echarts/core moves into the lazy chunk. Does not recommend dropping ECharts or undoing the lazy route.",
+        "Keeps German working by keeping the DE registration (EN ships with ECharts core via langEN). Says FR, ES, JA, PT-br and KO can be dropped because SUPPORTED_LANGUAGES is only ['en', 'de'], and puts that at about 6.9 KB gzip (6,892 B), a minor saving next to the core move.",
+        "Gives the expected outcome as an estimate (entry roughly 80 KB gzip after the move: 147,431 - 67,604 = 79,827 B, with React/react-dom/router at ~73 KB as the remaining floor) and says to confirm it by rebuilding (e.g. `npm run build` / `vite build`) and re-reading stats.json, since per-module gzip sums only approximate the gzip of the whole chunk.",
+        "Invents nothing that is not in the input: no module sizes, files, chunk names, ECharts APIs or Lighthouse scores beyond what stats.json and the source files contain.",
+        "Answers the actual question directly and at a size that fits a casual ask: leads with what is really heavy and the specific cut(s) to make, rather than a module-by-module audit of the whole bundle."
+      ]
+    },
+    {
+      "id": 7,
+      "held_out": "2026-10-20",
+      "prompt": "I lead frontend platform at Quillmark. Both of our apps in the monorepo (apps/storefront and apps/backoffice, webpack 5) consume our shared component library @quillmark/ui from packages/ui. Storefront only uses Button, PriceTag and Modal, yet its main bundle is enormous. I've committed production stats for both: apps/storefront/stats.json and apps/backoffice/stats.json. I need three things: (1) what @quillmark/ui is costing each app on first load and why, (2) the change to packages/ui that fixes it, plus anything that change could break, and (3) per-entry size budgets we can enforce in CI for both apps so this doesn't creep back.",
+      "assertions": [
+        "Traces the import chain from stats reasons/issuers, e.g. ./src/index.tsx -> ./src/App.tsx -> ./src/pages/Home.tsx -> @quillmark/ui (../../packages/ui/dist/index.js) -> ./Chart -> chart.js/auto -> chart.js/dist/chart.cjs. Names the root cause: packages/ui is compiled to CommonJS (tsconfig \"module\": \"commonjs\", only a \"main\" field, no ESM entry and no \"sideEffects\"), so the barrel's require() calls pull in every component (the stats show the 'Module is not an ECMAScript module' bailout).",
+        "For storefront, gives first-load cost from the CompressionPlugin output: main.8c41d2e7.js is 141,206 B gzip (437,914 B raw). Names the unused weight in it: the DataGrid/DatePicker/Chart wrappers and their dependencies @tanstack/table-core, dayjs, chart.js (with helpers.segment.cjs and @kurkle/color).",
+        "Treats webpack module `size` values as pre-minification source bytes, not emitted or gzip bytes. For example, it does not claim the chart.js-related modules' 522,298 B (or the 665,654 B of unused modules) are part of a 437,914-byte asset. Any per-dependency compressed saving is labelled an estimate or comes with a way to measure it after a rebuild. It also notes that backoffice's stats contain no gzip sizes (no CompressionPlugin there).",
+        "For backoffice, sees that DataGrid/DatePicker (table-core, dayjs) are really used by Users/Orders in main, but Chart/chart.js is used only by the lazy Analytics route. analytics.e71b4d08.js is just 1,206 B because chart.js already sits in main. Says chart.js will move into the analytics chunk only once main's imports stop going through the CommonJS barrel.",
+        "The packages/ui fix ships an ES module build (e.g. ESM output via a \"module\" field or an \"exports\" import condition, optionally per-component entry points) and declares side effects while keeping CSS as one (e.g. \"sideEffects\": [\"**/*.css\"]), because dist/Button.js does require(\"./Button.css\"). It warns that a blanket \"sideEffects\": false would silently drop the Button styles.",
+        "Budgets are set per entry for each app separately with an explicit unit (gzip vs raw). Notes that webpack's performance.maxEntrypointSize counts uncompressed emitted bytes, that storefront has performance.hints set to false, and that backoffice's 512,000-byte limit did not fire at 451,088 B. Proposes deriving the final numbers from post-fix stats plus headroom, without stating post-fix sizes as measured fact.",
+        "Invents nothing that is not in the input: no component names, package versions, file paths, chunk or asset sizes, or webpack/plugin options beyond what the stats and repo files contain. Any tool that would need installing from the network is given as a command, not presented as already run.",
+        "Answers all three numbered questions directly, per app, in the order asked."
+      ]
+    }
+  ]
+}

package/packs/frontend/skills/bundle-size-review/evals/files/1/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "larkspur-dispatch-web",
+  "version": "2.8.0",
+  "private": true,
+  "scripts": {
+    "build": "webpack --mode production",
+    "stats": "webpack --mode production --json=stats.json"
+  },
+  "dependencies": {
+    "@tidal/daterange-picker": "^3.4.0",
+    "date-fns": "^2.30.0",
+    "echarts": "^5.4.3",
+    "lodash": "^4.17.21",
+    "react": "^18.2.0",
+    "react-dom": "^18.2.0"
+  },
+  "devDependencies": {
+    "@babel/core": "^7.24.0",
+    "@babel/preset-env": "^7.24.0",
+    "@babel/preset-react": "^7.24.0",
+    "babel-loader": "^9.1.3",
+    "css-loader": "^6.10.0",
+    "mini-css-extract-plugin": "^2.8.1",
+    "webpack": "^5.91.0",
+    "webpack-cli": "^5.1.4"
+  },
+  "browserslist": ["defaults"]
+}

package/packs/frontend/skills/bundle-size-review/evals/files/1/src/utils/format.js

@@ -0,0 +1,26 @@
+import _ from "lodash";
+import { format, parseISO, isValid } from "date-fns";
+
+// Shared formatting helpers for the dispatch board, the header and the report pages.
+
+export function formatDay(iso) {
+  const d = parseISO(iso);
+  return isValid(d) ? format(d, "EEE d MMM") : "—";
+}
+
+export function formatTime(iso) {
+  const d = parseISO(iso);
+  return isValid(d) ? format(d, "HH:mm") : "";
+}
+
+export function byTechnician(jobs) {
+  return _.groupBy(jobs, "technicianId");
+}
+
+export function sortJobs(jobs) {
+  return _.sortBy(jobs, ["priority", "dueAt"]);
+}
+
+export function money(amount) {
+  return _.round(amount, 2).toFixed(2);
+}