Runbook Authoring

Turns a triggering event — an incident, an alert, a release, a scheduled ops task — into a rigorous runbook someone (or an agent) can execute under pressure. Sibling of /sop-authoring: same executable discipline, different domain.

SOP      = a BUSINESS process anyone non-technical can run; no code    (/sop-authoring)
Runbook  = a TECHNICAL/engineering-ops procedure — release, deploy,     (this skill)
           incident response — needing repo/infra context, written
           bus-factor-1

The dividing line is domain and context, not merely "process vs event". An SOP ("how Ops launches an event") needs no engineering context — its owner is operations. A runbook ("cutting a production release", "responding to a prod data leak in an incident") requires repo/infra knowledge and is written bus-factor-1: assume the reader operates the system alone with zero tribal context. Both can be repeatable and both can be triggered; the runbook is the one a software engineer must understand to execute.