Speed — does it scale?
Brief 88

Bundle & Asset Weight Audit

What the browser actually downloads — oversized bundles, unsplit code, heavy dependencies, and unoptimized assets that slow first paint.

BUNDLE.md4 phases7 lenses~2.5k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: weigh what a user's browser downloads before the product is usable, and find the payload that most delays first paint and interactivity.

Read-only pass. Read the build config and dependency tree; inspect a production build if you can; change nothing. Your only write is the report file.

What it looks for

7 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Bundle size & composition

total shipped, the biggest chunks, what dominates

2

Dead & duplicate code

unused exports, duplicate libraries, multiple versions of one dep

3

Code splitting

one monolithic chunk versus route- and feature-level lazy loading

4

Heavy dependencies

large libraries pulled in for one function; lighter or native alternatives

5

Asset weight

unoptimized images, uncompressed or unsubset fonts, missing modern formats

6

Loading strategy

render-blocking scripts and styles, missing preload/defer, request waterfalls

7

Delivery

missing gzip/brotli, weak cache headers, no CDN

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

BUNDLE.md
1
Weight budget
target vs actual for JS, CSS, images, fonts
2
Biggest wins
ranked by KB saved × effort, with the fix for each
3
Findings
each: lens · location · current cost · fix · savings
4
The budget to hold
the per-route ceiling and the check that enforces it
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Weigh the payload

Produce or read a production build.

2
Phase 2

Audit through 7 lenses

Bundle size & composition — total shipped, the biggest chunks, what dominates.

3
Phase 3

Curate

Rank by bytes saved × how early the asset loads.

4
Phase 4

Report

Create BUNDLE.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:bundle-asset-weight.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-bundle-asset-weight:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=88 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/88.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,522 characters)
# Goal: Bundle & Asset Weight Audit

You are working inside this repo. Mission: weigh what a user's browser downloads before the product is usable, and find the payload that most delays first paint and interactivity.

Read-only pass. Read the build config and dependency tree; inspect a production build if you can; change nothing. Your only write is the report file.

## Phase 1 — Weigh the payload
- Produce or read a production build; note total JS, CSS, image, and font bytes shipped.
- Identify the largest modules and which dependencies dominate the bundle.
- Note what loads on first paint versus what could wait.

## Phase 2 — Audit through 7 lenses
1. **Bundle size & composition** — total shipped, the biggest chunks, what dominates
2. **Dead & duplicate code** — unused exports, duplicate libraries, multiple versions of one dep
3. **Code splitting** — one monolithic chunk versus route- and feature-level lazy loading
4. **Heavy dependencies** — large libraries pulled in for one function; lighter or native alternatives
5. **Asset weight** — unoptimized images, uncompressed or unsubset fonts, missing modern formats
6. **Loading strategy** — render-blocking scripts and styles, missing `preload`/`defer`, request waterfalls
7. **Delivery** — missing gzip/brotli, weak cache headers, no CDN

## Phase 3 — Curate
- Rank by bytes saved × how early the asset loads: shrinking the critical path beats trimming a lazy chunk.
- For each, name the fix and roughly the weight it removes.
- Set a budget the team can hold, not just a one-time cleanup.

## Phase 4 — Report
Create `BUNDLE.md` at repo root:
1. **Weight budget** — target vs actual for JS, CSS, images, fonts
2. **Biggest wins** — ranked by KB saved × effort, with the fix for each
3. **Findings** — each: lens · location · current cost · fix · savings
4. **The budget to hold** — the per-route ceiling and the check that enforces it

Start the report with today's date. If `BUNDLE.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Bytes on the critical path cost more than bytes loaded lazily
- Measure against a budget; a cleanup with no ceiling drifts back
- No frontend bundle in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which weight to cut first

House rules for this Goal Prompt

  • Bytes on the critical path cost more than bytes loaded lazily
  • Measure against a budget; a cleanup with no ceiling drifts back
  • No frontend bundle in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which weight to cut first
Keep exploring

Pairs well with

Curated neighbors — briefs that answer the adjacent question, worth running in the same session.

More Speed briefs

Runs inside these playbooks — curated sequences you can launch with one paste: