Postmortem to Game-Day Scenario Generator Prompt

You are a senior SRE who designs game-day exercises. Your job is to turn a real incident into a safe, runnable drill that verifies the fixes actually hold, without blaming anyone who responded to the original event.

I will paste the following:
[POSTMORTEM] — the completed incident writeup, including timeline and contributing factors.
[REMEDIATIONS] — the action items or fixes that were shipped or planned.
[ENVIRONMENT] — where the drill will run (staging, prod-with-guardrails, isolated cell) and any blast-radius limits.

Do this:

1. Write a one-paragraph SCENARIO BRIEF describing the failure to simulate, framed as a system condition, not a person's mistake.
2. List INJECTION STEPS: the concrete faults to introduce (latency, dependency outage, resource exhaustion) with the smallest injection that reproduces the original failure mode. Mark any step that touches shared state as DESTRUCTIVE and add a precondition and rollback.
3. List EXPECTED RESPONDER ACTIONS: what a well-prepared on-call should observe, decide, and do, tied to the runbooks or alerts that now exist.
4. Define SUCCESS CRITERIA: measurable signals proving each remediation worked (e.g., failover under X seconds, no customer error spike, alert fired within Y).
5. Define ABORT CRITERIA and a stop-the-drill owner.
6. List OPEN QUESTIONS the drill is designed to answer.

Output as Markdown with those exact sections. Mark anything you infer that is not stated in the inputs as [ESTIMATE]. Stay blameless throughout: describe systems failing, never individuals. A human game-day facilitator owns the go/no-go decision and every destructive step; you only propose the plan.

Why this prompt works

A postmortem tells you what broke and, ideally, what you changed so it won’t break the same way again. The dangerous gap is that most remediations are never actually exercised: the runbook gets written, the timeout gets tuned, the circuit breaker gets added, and everyone assumes those fixes work because they look correct in code review. A game-day is the only cheap way to falsify that assumption before the next real incident does it for you. This prompt exists to close the loop, forcing the abstract remediations from a postmortem into a concrete, runnable drill with measurable pass/fail criteria.

The design leans hard on separating the injection from the expectation. By making the model produce injection steps and expected responder actions as distinct sections, the exercise becomes a genuine test rather than a scripted walkthrough where responders already know the answer. Success criteria must be measurable, because “the team handled it well” is not a result you can trust; “failover completed in under thirty seconds and no customer-facing error rate exceeded baseline” is. The abort criteria and stop-the-drill owner are non-negotiable guardrails: a game-day that cannot be halted instantly is just an outage you scheduled.

The blameless framing matters even here, in an exercise that is fundamentally about testing systems. If the scenario brief or expected-actions language implies that the original responders were slow or wrong, participants get defensive and the drill turns into a performance review. Keeping every description at the level of system behavior preserves the psychological safety that makes people willing to be tested at all. The [ESTIMATE] markers guard against a subtler failure mode: the model confidently inventing thresholds, timings, or dependency behavior that were never in the postmortem, which would produce a drill that validates fiction.

Finally, the human-owns-decisions guardrail reflects the reality that fault injection is one of the highest-blast-radius things an SRE team does. LLMs routinely underestimate how far a fault can propagate through shared infrastructure. By requiring a facilitator to own the go/no-go and every destructive step, and by defaulting to staging or an isolated cell, the prompt keeps the exercise squarely in the category of controlled learning rather than self-inflicted incident.