Writing a runbook

Write a runbook for: {{task_description}}

Context (system involved, who typically handles this, how often it comes
up): {{context}}

Structure:
1. "When to use this runbook" - the specific symptoms or trigger that
   means this is the right procedure, and what it is NOT for (so someone
   doesn't apply it to a similar-looking but different problem).
2. Prerequisites - access, tools, or information needed before starting.
3. Numbered steps, each one a single concrete action with the exact
   command or click-path, not a vague instruction like "restart the
   service" without saying how.
4. After each risky step, what to check before proceeding, and what it
   means if that check fails.
5. "If this doesn't work" - the escalation path (who to page, what
   information to have ready) if the runbook doesn't resolve it.

Write for someone who has general technical skill but has never done this
specific task before and may be doing it under time pressure - don't
assume tribal knowledge that isn't written down here.

When to use

Documenting an operational task that currently lives only in one person’s head (or in a Slack thread from the last time it happened). Most valuable for anything rare enough that muscle memory won’t cover it, but important enough that getting it wrong under pressure is costly.

Why it works

A runbook’s whole value is being followable by someone who doesn’t already know how to do the task - which means every implicit step the person who usually does this takes for granted needs to be made explicit. Structuring around “what to check after each risky step” builds in the verification a tired or panicked on-call engineer might otherwise skip, and the explicit escalation path prevents someone from getting stuck silently.

Variations

• Add “This will likely be run under incident pressure - keep each step to one action, no paragraphs” for a runbook meant for active incidents.
• For a task with several valid approaches depending on the situation, ask for a short decision tree at the top (“if X, go to step 4; if Y, go to step 7”) instead of one linear procedure.
• Ask the model to also write 2-3 questions a reviewer should ask before trusting this runbook (has it been tested? by whom? when?).