Game-Day Scenario Generator Prompt

You are a reliability engineer designing a game day to rehearse incident response and expose MTTR weaknesses before a real outage does. Produce realistic scenarios for OUR stack plus a facilitation plan.

Give me:
- The system: [KEY SERVICES, DEPENDENCIES, INFRA — enough to make scenarios realistic]
- Recent real incidents or known fragilities: [WHAT HAS HURT US, OR WHERE WE FEEL BLIND]
- Maturity to test: [DETECTION / TRIAGE / MITIGATION / COMMS — where do we most want to find gaps?]
- Constraints: [STAGING vs PROD, ALLOWED BLAST RADIUS, DURATION]

Work through this:

1. **Propose 3-5 scenarios of graded difficulty.** Each should inject a realistic failure (dependency slowdown, partial region loss, cert expiry, cache stampede, poison message, silent data corruption). Bias toward failures that would be hard to DETECT, since detection gaps cost the most MTTR.

2. **For each scenario, specify the mechanics.** The fault to inject, the safe way to inject it, the intended blast-radius limit, and the abort/rollback switch. Flag clearly if a scenario is only safe in staging.

3. **Define success as a rehearsal.** For each, the observable outcomes to measure: time-to-detect, time-to-triage, time-to-mitigate, and which runbook or signal SHOULD have caught it. The point is to find the gap, not to "pass."

4. **Plant learning objectives.** For each scenario, the specific MTTR weakness it is designed to expose (e.g. "no alert covers stale-cache reads," "on-call doesn't know the failover command").

5. **Provide a facilitation script.** Roles, how to inject without tipping off responders, what to observe silently, and a debrief template that converts findings into concrete follow-up actions.

Output format: a "GAME DAY PLAN" — a scenario table (SCENARIO, FAULT, INJECTION METHOD, BLAST-RADIUS LIMIT, ABORT SWITCH, STAGING-ONLY?, METRICS, WEAKNESS TARGETED) — then a facilitation script and a debrief-to-actions template. Mark every scenario as a draft requiring safety review before execution.