The 3am table — for each failure scenario: how you'd detect it, how you'd respond, and the gap in between.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: for every plausible failure, answer three questions — how would you know, what would you do, how bad does it get — and close the gap between today's answers and good ones.
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.
timeouts set? retries with backoff? or infinite hangs and instant cascades
when a dependency dies, does one feature die or does the whole app?
for each scenario: would an alert fire, or would a user report it first? Estimate time-to-know
for the top 5 likely incidents: does written guidance exist, or does response depend on one person's memory?
backups untested are hopes; trace the restore path and its expected duration
operations only one person can perform; access only one person holds
can one bad deploy, one poisoned job, or one heavy tenant take everything down?
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.
List external dependencies (database, third-party APIs, queues, storage, email) and critical internal services.
Failure handling — timeouts set? retries with backoff? or infinite hangs and instant cascades.
Rank scenarios by likelihood × impact × current unreadiness.
Create RELIABILITY.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:incident-readiness.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-incident-readiness:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=25 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/25.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Incident Readiness Review You are working inside this repo. Mission: for every plausible failure, answer three questions — how would you know, what would you do, how bad does it get — and close the gap between today's answers and good ones. Read-only pass. Your only write is the report file. ## Phase 1 — Enumerate what can fail - List external dependencies (database, third-party APIs, queues, storage, email) and critical internal services. - For each: what does the code do today when it's down, slow, or returning garbage? Trace the actual handling. - Find the backups: do they exist, and has a restore ever been tested? ## Phase 2 — Audit through 7 lenses 1. **Failure handling** — timeouts set? retries with backoff? or infinite hangs and instant cascades 2. **Degradation** — when a dependency dies, does one feature die or does the whole app? 3. **Detection** — for each scenario: would an alert fire, or would a user report it first? Estimate time-to-know 4. **Runbooks** — for the top 5 likely incidents: does written guidance exist, or does response depend on one person's memory? 5. **Restore reality** — backups untested are hopes; trace the restore path and its expected duration 6. **Human single points** — operations only one person can perform; access only one person holds 7. **Blast radius** — can one bad deploy, one poisoned job, or one heavy tenant take everything down? ## Phase 3 — Curate - Rank scenarios by likelihood × impact × current unreadiness - Every gap names its cheapest meaningful mitigation ## Phase 4 — Report Create `RELIABILITY.md` at repo root: 1. **The 3am table** — scenario · detection today · response today · gap · fix 2. **Backup/restore verdict** — with the untested-assumption list 3. **Top 5 runbooks to write** — with a skeleton outline for each 4. **Cheapest resilience wins** — timeouts, alerts, and kill switches shippable this week 5. **The nightmare scenario** — the worst plausible day, narrated, and what changes it Start the report with today's date. If `RELIABILITY.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - An untested backup is a hypothesis; label it as one - Detection before prevention: knowing fast beats never failing - No production deployment 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 gaps to close
reports/ directory exists at the repo root, write the report there instead of the root.Map merged-PR to production; every manual step is a finding. Includes the rollback-readiness verdict.
Expensive queries, chatty API loops, unbounded storage, oversized resources — savings ranked by effort.
Every knob, var, and magic value — where config sprawls, where environments drift, what explodes at boot versus at 3am, and which secrets hide in plain sight.
The positive side of observability — whether metrics, traces, and SLOs let you answer any question about the running system, not just whether it crashed.
Runs inside these playbooks — curated sequences you can launch with one paste: