Speed — does it scale?
Brief 04

Performance Audit

The broad latency pass — wasted renders, main-thread stalls, startup waterfalls — ranked by what the user actually feels on common paths.

PERF.md4 phases7 lenses~2.7k 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: find where this product wastes time and bytes, and rank the wins by latency the user actually feels on common paths.

This is the broad pass across every layer. When the database is the suspect, go deep with 87; when the payload is, 88; when caching is, 140.

Read-only pass: build, measure, profile — but 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

Payload

bundle size, missing code-splitting, unoptimized images/fonts, oversized JSON responses

2

Render waste

unnecessary re-renders, unmemoized expensive work, layout thrash, long lists without virtualization

3

Query cost

N+1 patterns, over-fetching, queries in loops, missing indexes implied by access patterns

4

Missing caches

repeated identical fetches/computations with no memo or cache layer

5

Main-thread blockers

heavy synchronous work where users are waiting

6

Startup cost

cold-start waterfalls, sequential awaits that could be parallel, eager work that could be lazy

7

Memory growth

unbounded caches, retained references, growing arrays

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.

PERF.md
1
Current numbers
everything measured in Phase 1
2
Findings
each: Name · Location · Cost today (estimate) · Fix · Expected gain · Effort S/M/L
3
Quick wins vs deep work
the split, with the top quick win spelled out
4
Measurement plan
how to verify each gain after fixing
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

Measure what's measurable

Build the app.

2
Phase 2

Audit through 7 lenses

Cite location and estimated cost for every finding.

3
Phase 3

Curate

Rank by user-felt impact on common paths — not micro-benchmarks.

4
Phase 4

Report

Create PERF.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:performance-audit.

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

Or install only this Goal Prompt as /goal-performance-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=04 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/04.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,660 characters)
# Goal: Performance Audit

You are working inside this repo. Mission: find where this product wastes time and bytes, and rank the wins by latency the user actually feels on common paths.

This is the broad pass across every layer. When the database is the suspect, go deep with 87; when the payload is, 88; when caching is, 140.

Read-only pass: build, measure, profile — but change nothing. Your only write is the report file.

## Phase 1 — Measure what's measurable
- Build the app; record bundle sizes and build time.
- Time the test suite and any measurable startup path.
- Identify the 3 heaviest pages/endpoints by code inspection: most data fetched, most rendered, most computed.

## Phase 2 — Audit through 7 lenses
Cite location and estimated cost for every finding.
1. **Payload** — bundle size, missing code-splitting, unoptimized images/fonts, oversized JSON responses
2. **Render waste** — unnecessary re-renders, unmemoized expensive work, layout thrash, long lists without virtualization
3. **Query cost** — N+1 patterns, over-fetching, queries in loops, missing indexes implied by access patterns
4. **Missing caches** — repeated identical fetches/computations with no memo or cache layer
5. **Main-thread blockers** — heavy synchronous work where users are waiting
6. **Startup cost** — cold-start waterfalls, sequential awaits that could be parallel, eager work that could be lazy
7. **Memory growth** — unbounded caches, retained references, growing arrays

## Phase 3 — Curate
- Rank by user-felt impact on common paths — not micro-benchmarks
- For each finding, estimate the gain: order of magnitude is fine (ms saved, kb removed)
- Kill anything that trades meaningful complexity for negligible gain

## Phase 4 — Report
Create `PERF.md` at repo root:
1. **Current numbers** — everything measured in Phase 1
2. **Findings** — each: Name · Location · Cost today (estimate) · Fix · Expected gain · Effort S/M/L
3. **Quick wins vs deep work** — the split, with the top quick win spelled out
4. **Measurement plan** — how to verify each gain after fixing

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

## Rules
- A perf claim needs a number or a mechanism — no vibes
- Optimize the common path before the edge case
- No runtime hot paths 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 wins to take

House rules for this Goal Prompt

  • A perf claim needs a number or a mechanism — no vibes
  • Optimize the common path before the edge case
  • No runtime hot paths 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 wins to take
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: