runbook-authoring

Writes operational runbooks with verify-mitigate-diagnose-escalate procedures for on-call incident responders.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill runbook-authoring-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: runbook-authoring
Source: https://github.com/Nandansai08/skillz/tree/main/skills/sre-incident-response/runbook-authoring
Command: npx skills add https://github.com/Nandansai08/skillz --skill runbook-authoring-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Alerts fire without documented procedures, leaving 3am on-call responders to improvise fixes under stress. This Skill turns tribal knowledge and postmortem action items into executable runbooks that an engineer from another team can follow without hesitation. ## Core Features & Use Cases - Structured Procedure Authoring: Enforces a Verify → Mitigate → Diagnose → Escalate structure with explicit escalation tripwires and header blocks covering symptom, impact, severity, and last-verified date. - Observable Step Format: Every step pairs a copy-pasteable command with expected output and a what-if-not branch, and destructive actions get loud warnings with pre-checks. - Cold-Test Validation: Requires a non-author to execute the runbook in staging or a game day, treating every hesitation as a documentation defect. - Use Case: After a postmortem flags a 25-minute improvised Redis failover, write the runbook from the incident's actual commands, cold-test it with a non-expert, and cut the next failover to 6 minutes. ## Quick Start Write a runbook for the Redis failover procedure based on the commands from our last incident, including verification checks, mitigation steps, and an escalation tripwire.

Frequently Asked Questions about runbook-authoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a runbook for on-call incident response?▼

Structure the runbook as Verify, Mitigate, Diagnose, Escalate, opening with a header block covering symptom, impact, severity, escalation contact, and last-verified date. Write every step as a copy-pasteable command with expected output and a fallback branch, and add an explicit escalation tripwire such as a time limit.

What is the difference between a runbook and system documentation?▼

A runbook is an executable procedure for a specific alert or symptom, while system documentation explains how the architecture works. Runbooks should link to narrative docs rather than inline them, since a stressed responder needs actions, not explanations.

How do I test whether a runbook actually works?▼

Have someone who did not write it execute the runbook in staging or during a game day. Every place they hesitate, ask a question, or improvise is a defect in the document, because the author's own tribal knowledge invisibly fills gaps during self-testing.

When should a runbook be automated instead of documented?▼

A runbook executed monthly with zero decision points is a script with extra steps and should be automated. Leave a one-line runbook pointing at the automation button rather than maintaining manual steps nobody should be running.

Why do runbooks go stale and how do I prevent it?▼

Runbooks go stale after architecture changes, and a confidently wrong runbook is worse than none. Include a last-verified date in the header, re-verify quarterly or on any architecture change, and run a five-minute diff pass after every real execution.