Generate an operational runbook for a service — covering deploy/rollback, common incidents, on-call escalation, SLOs, dashboards, and dependencies. Use when the user is launching a new service, onboarding to on-call, or being asked for "the runbook" by SRE or production-readiness review.
Pack sre-oncallTier standardJob Run and recover the servicev0.1.0
In Claude Code, with the sre-oncall plugin installed, invoke it as:
/sre-oncall:runbook-generator
Try it
A realistic prompt from the skill's acceptance evals:
Write the operational runbook for our new payments service — it deploys via Argo, pages the payments team, and depends on Stripe and Postgres.
What a good result looks like
Owner info is current. Use roles ("payments-platform team, primary on-call rotation") rather than individual names that go stale when people change teams.
Every alert listed has a response. A "what to do when this alert fires" section that doesn't cover all the alerts is worse than no section.
Rollback is one command, or three steps max. If rollback is complicated, write a script and link to it.
No "TBD" left in the doc when it's published. Move TBDs to a "known gaps" section so they're explicit, not hidden.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 94% of its checks, against 83% without it, and a blind judge preferred the agent without it. How skills are checked
19 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Ownership is expressed as roles and rotations rather than individual names that go stale
Every alert listed has a corresponding 'what to do when this fires' response — no alert is left without one
Rollback is one command or at most three steps
Dependencies are listed with what breaks when each is unavailable
Escalation names the path and the trigger for escalating, not just a team name
Facts not supplied (dashboard links, SLO values) are marked missing rather than invented
Rollback is done by redeploying the previous release tag with deploy.sh, which takes only a tag; it flags that the script has no --rollback option despite the notes
Warns that migration 0042 is forward-only, so the app cannot be rolled back to a version before 2.6.0 such as v2.5.4
The first action when the display data is more than 15 minutes old or missing is to tell pilots to use the printed tide tables, as the standing order requires, before any troubleshooting
Does not list the gauge hardware supplier as a working escalation route, and flags that the support contract lapsed in August
Leaves SLOs and dashboards as open gaps to be filled, rather than inventing targets or dashboard links
Does not invent commands, hostnames, phone numbers or contacts that are not in the files
The runbook is saved as runbook.md and fits on about three printed pages
Delivers a one-page sheet in plain language a non-technical volunteer can follow
Orders the checks from the simplest and most likely (is the studio PC playing, is the encoder box on and connected, is the internet up) before anything harder
Says to phone the station manager only after the stream has been down for more than 30 minutes
Does not invent phone numbers, passwords, equipment models or host settings; leaves clear blanks for the station to fill in
Tells volunteers how to confirm the stream is back and to note what happened for the manager
Delivers the sheet without stopping to ask questions first
When it should and shouldn't activate
Should activate:
Write an operational runbook for this service
We're launching a service — what does on-call need documented?
Document deploy, rollback, and incident response for this system
Generate the runbook covering escalation and common failures
Should leave to another skill:
Design our SLIs, SLOs, and burn-rate alerts
We're in an incident right now — draft the status page update
Write the postmortem for the outage
Sweep the full non-functional requirements catalog