Every cache from CDN headers to that module-level dict — keys, TTLs, who invalidates what — the stale read, the stampede, and the key that leaks between users.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: find every cache this system runs — declared or accidental — and audit the three questions each must answer: what is the key, when does it die, and who kills it early. A cache with no answer to the third question is a staleness bug on a timer.
Read-only pass. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
user-, tenant-, or locale-scoped data under a key missing that scope: the cache that serves one user's data to another; audit every key's composition against what it stores
for each write path that changes cached data: trace to the invalidation call, or record "expiry only" and compute the staleness window users actually see
every TTL justified by how stale is acceptable, or a folklore constant copied between configs; no TTL at all means forever
a hot key expires under load: single-flight lock, jitter, stale-while-revalidate, or a thundering herd onto the database
the same data cached at CDN, app, and query layers with different lifetimes: compute the worst-case disagreement a user can observe
errors and empty results: cached so failures hammer nothing, or uncached so every miss retries; a cached 500 with a long TTL is an outage extender
the memo dicts and key-per-user caches with no eviction: today's optimization, next quarter's memory leak
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.
Inventory every layer.
Every finding cites the cache, its key, and the code path.
Rank correctness above speed.
Create CACHES.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:caching-strategy.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-caching-strategy:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=140 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/140.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Caching Strategy Audit You are working inside this repo. Mission: find every cache this system runs — declared or accidental — and audit the three questions each must answer: what is the key, when does it die, and who kills it early. A cache with no answer to the third question is a staleness bug on a timer. Read-only pass. Your only write is the report file. ## Phase 1 — Census the caches - Inventory every layer: CDN and HTTP cache headers, reverse proxies, Redis/memcached, ORM and query caches, memoization decorators, and the module-level dicts and lazy globals that are caches without admitting it. - For each: the key composition, the TTL (or its absence), the eviction policy, and every code path that invalidates it — file:line. - Mark what each cache fronts: whose data, how hot, how expensive to recompute. ## Phase 2 — Audit through 7 lenses Every finding cites the cache, its key, and the code path. 1. **Key hygiene** — user-, tenant-, or locale-scoped data under a key missing that scope: the cache that serves one user's data to another; audit every key's composition against what it stores 2. **Invalidation reality** — for each write path that changes cached data: trace to the invalidation call, or record "expiry only" and compute the staleness window users actually see 3. **TTL rationale** — every TTL justified by how stale is acceptable, or a folklore constant copied between configs; no TTL at all means forever 4. **Stampede paths** — a hot key expires under load: single-flight lock, jitter, stale-while-revalidate, or a thundering herd onto the database 5. **Layer coherence** — the same data cached at CDN, app, and query layers with different lifetimes: compute the worst-case disagreement a user can observe 6. **Negative & error caching** — errors and empty results: cached so failures hammer nothing, or uncached so every miss retries; a cached 500 with a long TTL is an outage extender 7. **Unbounded growth** — the memo dicts and key-per-user caches with no eviction: today's optimization, next quarter's memory leak ## Phase 3 — Curate - Rank correctness above speed: a cross-user leak or unkillable stale read outranks any hit-rate win. - For each, name the mechanism: a scoped key, an invalidation hook, single-flight, stale-while-revalidate, an LRU bound. - Note what isn't cached but should be — repeated identical reads on the hot path are the flip side of the same audit. ## Phase 4 — Report Create `CACHES.md` at repo root: 1. **Cache ledger** — cache · key composition · TTL · invalidation path (file:line) or "expiry only" · stampede guard · bound 2. **The staleness story** — the worst user-visible stale read possible today, narrated: the write, the windows, what the user sees 3. **Findings** — each: lens · cache · risk · the mechanism to fix it · effort 4. **Missing caches** — the hot, repeated, identical reads with no cache in front of them Start the report with today's date. If `CACHES.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Every cache answers three questions — key, death, early death; "expiry only" is an answer and a finding - A cache is a correctness feature that happens to be fast; audit it like one - No caching layers — declared or accidental — 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 caches to fix first
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.
The database access patterns that fall over as data and traffic grow — N+1s, missing indexes, unbounded reads, and lock contention.
The broad latency pass — wasted renders, main-thread stalls, startup waterfalls — ranked by what the user actually feels on common paths.
Simulate 10x users, data, and traffic on paper — find what breaks first, at what threshold, and the cheapest mitigation.
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.