runbook-authorlisted

# Runbook Author ## Purpose Turn an alert definition (a Prometheus rule, a Datadog monitor, a PagerDuty service config) OR a postmortem into a runbook entry the on-call engineer can follow at 3am. Used by the `sre` agent. The output is a single-page runbook stub the on-call edits as needed — not a final doc, but a structured starting point that prevents the "blank page at 3am" problem. ## Scope - Reads ONE of: - an alert definition file (Prometheus `*.rules.yaml`, Datadog monitor JSON export, generic YAML with `name` + `query`) - a postmortem markdown (`postmortems/YYYY-MM-DD-*.md`) - Produces a runbook entry at `--out` (default `runbooks/<alert-name>.md`). - Does NOT auto-publish to a wiki; the operator commits or pastes the file themselves. - Does NOT execute any of the actions it suggests — the runbook is text, not a script. ## When to use - A new alert was added — runbook entry should land in the same PR. - A postmortem identified a missing runbook (action item: "write runbook for the disk-full alert"). - During on-call rotation handoff, to fill in stub runbooks for alerts that exist but lack docs. ## When NOT to use - For an alert whose root cause is genuinely unknown. "Investigate" is not a first action. If the team doesn't know the symptom-to- cause mapping yet, run a game-day or shadow an incident first. - For automation / auto-remediation. Runbooks are human-targeted; if every step is a script, the work belongs in code, not docs. - As