How to use the Incident Runbook Templates agent skill

What the skill makes the agent do

Once installed, the agent organises a runbook into sections such as overview and impact, detection and alerts, initial triage, mitigation, root cause investigation, resolution, verification and rollback, communication templates, and an escalation matrix. It writes steps meant to be followed under stress, so each step is short and specific.

The skill also includes a standard severity scale, SEV1 to SEV4, with impact, response time and example for each level. It suggests practical habits such as prerequisite checks for each command, a quick checklist at the top of the runbook, and clear rollback steps.

• SEV1: complete outage or data loss, 15 min response
• SEV2: major degradation, 30 min response
• SEV3: minor impact, 2 hours response
• SEV4: minimal impact, next business day response

Install the skill from the ZIP download

Download the ZIP for the skill from this page and unzip it. To make it available across your projects, unzip it into ~/.claude/skills/. To make it available only inside one project, unzip it into that project's .claude/skills/ folder.

If you use the Claude apps instead, open Settings, go to Capabilities, then Skills, and upload the skill there. The package contains SKILL.md and references/details.md.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project

Trigger the skill with natural requests

You do not need a special command. Ask for a runbook in ordinary words that match the skill's use cases, and the agent will load it when the request fits. The skill's description names four situations: a service outage runbook for a payment processing system, database incident procedures, step-by-step recovery guides for new on-call engineers, and standardised escalation matrices across teams.

Be specific about the system and the failure mode. A request that names the service, the alerts and the teams involved gives the agent more to work with than a general request for a runbook.

Example requests and what you get back

For a payments outage, you might ask the agent to write a service outage runbook for a payment processing system covering error rate and latency alerts. The output follows the runbook structure, with an impact checklist, detection section, triage steps and rollback actions.

For database work, ask for procedures covering connection pool exhaustion, replication lag and disk space alerts. The skill includes a pattern for database commands: a dry-run count query first, then the terminating command only after the count has been checked.

For onboarding, ask for a recovery guide written for a 3 AM reader, with short numbered steps and a quick checklist. For governance, ask for an escalation matrix that the teams involved can share.

What you need before you start

The skill lists no required tools, runs no scripts and makes no network calls. The agent writes documents from the skill's templates and your description.

The commands in the examples are illustrative. Before any runbook is used, check each command, cluster name, namespace, endpoint and dashboard link against your own environment. The skill's own troubleshooting notes recommend adding a prerequisite check and a what-to-do-if-this-fails note to every command.

• No required dependencies are listed in the skill
• No scripts are run by the skill
• No network access is used by the skill

Safety notes and limits

Do not use the skill to respond to a live outage in real time. It writes documents; it does not diagnose your systems. Example commands in the templates, such as kubectl and aws eks update-kubeconfig, and the SQL that terminates idle connections, must be verified before anyone runs them. The templates are generic examples and are not tied to any compliance standard, so they are not a certified incident management framework.

Review every destructive command yourself. The skill's database example warns that terminating connections can cause additional downtime.

• Do not treat generated commands as verified
• Check destructive SQL with a dry run first
• Add a compliance review if your organisation requires a certified framework

Tips for better runbooks

Keep runbooks current by reviewing them after every incident and recording a last-verified date and owner at the top. Test them regularly with game days. Assign a separate incident communicator so that status updates continue while engineers are working the problem, and keep a standing update agenda in the communication template.

If you need a postmortem after the incident, the related postmortem-writing skill covers root cause and preventive actions. The on-call-handoff-patterns skill helps structure shift handoffs.

• Write for a tired reader and avoid assumed knowledge
• Confirm each step worked before moving on
• Escalate early rather than working alone