Runbook writing
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill runbook-writingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write runbooks with executable steps, decision points, and per-step verification that a stressed responder can follow. Use when documenting operational procedures or reducing 3am guesswork.
SKILL.md
3.2 KB, as published. Nobody here has run it
Runbook writing
A runbook is written for the worst version of your reader: half-awake, paged, under pressure, possibly not the person who wrote it. It succeeds when they can execute it without understanding the whole system, and it is honest about where judgment is still required.
Method
- Open with trigger, impact, and severity. When this runbook applies (the alert or symptom that led here), what is affected, and how urgent: so a responder confirms they are in the right place in ten seconds (see alerting-design: the alert links here). A runbook you have to read fully to know if it applies is a document, not a runbook.
- Write steps as copy-pasteable actions. Exact commands (not "restart the service" but the command, with placeholders clearly marked), expected output, and what each does; link to dashboards and consoles directly. Prose that describes what to do forces translation the stressed reader gets wrong; executable steps do not.
- Verify after every consequential step. "Run X; confirm Y shows Z before continuing": so a wrong turn is caught immediately, not three steps later (see script-idempotency's check-then-act ethic, human edition). Steps without verification let small errors compound into a second incident.
- Make decision points explicit branches. "If the queue depth is still rising, go to section B; if it is draining, monitor and stop": name the observable that decides, not "use judgment". Where judgment truly is required, say so and give the factors (see incident-commander-role for escalation decisions): false certainty is worse than honest ambiguity.
- Flag the dangerous and the irreversible. Destructive steps (data deletion, traffic cutover) get a warning, the blast radius, and a confirmation gate (see automation-guardrails); include the rollback for each risky action (see rollback-strategy). The runbook that walks someone off a cliff at step 7 is worse than none.
- Keep runbooks alive. Test them (in game-days, and the first time on the real incident, fix what was wrong: see chaos-gameday); date them and assign an owner; every incident postmortem checks whether the runbook helped and updates it (see incident-postmortem). A stale runbook confidently gives wrong instructions, which is the most dangerous failure mode of all.
Boundaries
- Runbooks encode known, repeatable responses; novel incidents need the runbook's diagnostic starting points plus human reasoning (see production-debugging, scientific-debugging): do not pretend a runbook covers the unforeseen.
- A frequently-run runbook is a candidate for automation (auto-remediation): but automate only what is safe and well-understood, keeping the manual runbook as the fallback (see automation-guardrails).
- Runbooks live where they are reachable during an incident (not only in a wiki that might be down); linked from alerts and mirrored somewhere resilient (see cloud-disaster-recovery's reachability rule).