Simulate 10x users, data, and traffic on paper — find what breaks first, at what threshold, and the cheapest mitigation.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: put tomorrow's load on today's architecture — 10x the users, 10x the data, 10x the traffic — and find what breaks first, in what order, and what each fix costs.
This is a thought experiment on tomorrow's load, the whole product included — cost, ops, third parties. For today's configured ceilings, measured from config, run 123.
Read-only pass, thinking on paper. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
unpaginated queries, full scans, unbounded UI lists, tables with no archival story
connection pools, session storage, rate limits, lock contention, auth bottlenecks
one-instance assumptions, local file state, in-memory queues/caches that don't survive restarts or replicas
backlog behavior under load, retry storms, poison messages, no dead-letter path
API quotas and rate limits you'll hit at 10x
what scales linearly vs what explodes (per-request third-party calls, storage egress)
manual steps that become 10x painful (deploys, support lookups, data fixes)
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.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Infer current scale from code and config.
For each, name the breaking mechanism and estimate the threshold.
Order findings by which breaks first as load grows.
Create SCALE.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:stress-review-10x.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-stress-review-10x:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=05 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/05.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: 10x Stress Review You are working inside this repo. Mission: put tomorrow's load on today's architecture — 10x the users, 10x the data, 10x the traffic — and find what breaks first, in what order, and what each fix costs. This is a thought experiment on tomorrow's load, the whole product included — cost, ops, third parties. For today's configured ceilings, measured from config, run 123. Read-only pass, thinking on paper. Your only write is the report file. ## Phase 1 — Establish today's scale - Infer current scale from code and config: pool sizes, rate limits, page sizes, batch sizes, timeouts. - Which growth axis matters most for this product: users, data volume, traffic spikes, or tenant count? - Which tables, queues, and stores grow without bound? ## Phase 2 — Stress through 7 lenses For each, name the breaking mechanism and estimate the threshold. 1. **10x data** — unpaginated queries, full scans, unbounded UI lists, tables with no archival story 2. **10x users** — connection pools, session storage, rate limits, lock contention, auth bottlenecks 3. **Single points of failure** — one-instance assumptions, local file state, in-memory queues/caches that don't survive restarts or replicas 4. **Jobs & queues** — backlog behavior under load, retry storms, poison messages, no dead-letter path 5. **Third-party ceilings** — API quotas and rate limits you'll hit at 10x 6. **Cost curve** — what scales linearly vs what explodes (per-request third-party calls, storage egress) 7. **Operational load** — manual steps that become 10x painful (deploys, support lookups, data fixes) ## Phase 3 — Curate - Order findings by which breaks first as load grows - For each: cheap patch vs real fix — name both - Explicitly list what NOT to fix yet (premature scaling is also a bug) ## Phase 4 — Report Create `SCALE.md` at repo root: 1. **Today's scale snapshot** — the numbers and assumptions 2. **First-to-break ranking** — each: bottleneck · breaking mechanism · estimated threshold · symptom users would see 3. **Mitigations** — cheap patch and real fix per bottleneck, with effort 4. **Do-not-fix-yet list** — premature optimizations to consciously skip 5. **The one change** — biggest headroom per unit of effort Start the report with today's date. If `SCALE.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Every bottleneck needs a mechanism — "might be slow" doesn't count - Respect today's simplicity: recommend the least architecture that survives 10x - No load-bearing system 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 mitigations to build
reports/ directory exists at the repo root, write the report there instead of the root.Curated neighbors — briefs that answer the adjacent question, worth running in the same session.
The broad latency pass — wasted renders, main-thread stalls, startup waterfalls — ranked by what the user actually feels on common paths.
Where the seconds go. Decomposes p50 and p95 of the runs users feel into stages — queue, retrieval, first token, tools — and names the stage worth attacking.
The database access patterns that fall over as data and traffic grow — N+1s, missing indexes, unbounded reads, and lock contention.
What the browser actually downloads — oversized bundles, unsplit code, heavy dependencies, and unoptimized assets that slow first paint.