# Build Incident Response Runbooks

Generic incident procedures slow triage and create inconsistent decisions during outages. This skill creates structured runbooks with checks, mitigation steps, escalation paths, and communication templates.

## Install

```bash
npx skillstore add sickn33/incident-runbook-templates
```

## Metadata

- Status: approved
- Slug: sickn33-incident-runbook-templates
- Skillstore revision: r2
- Version status: missing
- Tree hash: 67066e2a54d5638b388b6f7e1b19dd048e003a5623fc66f35d6a3fd770e7dc17
- Author: sickn33
- GitHub username: sickn33
- License: MIT
- Repository: https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/incident-runbook-templates
- Ref: 88a8e9a07f4c54ab105c1c41b6267c287146b07b
- Supported tools: Claude, Codex, Claude Code
- Audit status: complete
- Agent install advisory: allowed
- Manual install advisory: allowed
- Artifact signature: available
- Audit attestation: unavailable
- Human verification: not\_verified
- Risk factors: external\_commands, network, filesystem
- Quality score: 69
- Public page: https://skillstore.pages.dev/skills/sickn33-incident-runbook-templates
- Manifest: https://skillstore.pages.dev/api/skills/sickn33-incident-runbook-templates/manifest

## Capabilities

- Structures runbooks around detection, triage, mitigation, investigation, recovery, verification, rollback, communication, and escalation.
- Defines SEV1 through SEV4 classifications with impact examples and target response times.
- Provides a service outage template with Kubernetes, PostgreSQL, Prometheus, and dependency checks.
- Provides database incident procedures for connection exhaustion, replication lag, and critical disk usage.
- Drafts internal notifications, status updates, resolution notices, and escalation matrices.

## Use Cases

- Prepare a service outage runbook: Create a service-specific procedure with alerts, initial checks, mitigation options, rollback steps, and recovery verification.
- Standardize database incident response: Document safe investigation paths for connection pressure, replication lag, and storage exhaustion.
- Coordinate incident communication: Define escalation conditions and consistent internal updates for each stage of a serious incident.

## Prompt Templates

### Create a basic runbook

```
Create an incident runbook for [service]. Include impact, alerts, first checks, escalation contacts, mitigation, rollback, verification, and communication steps.
```

### Adapt an outage template

```
Adapt the service outage template for [service] running on [platform]. Use these dashboards, alerts, dependencies, owners, and approved operational commands: [details].
```

### Review runbook safety

```
Review this runbook for ambiguous actions, missing approvals, unsafe commands, weak verification, incomplete rollback, and unclear escalation. Suggest precise corrections: [runbook].
```

### Design a complex incident workflow

```
Design a SEV1 runbook for [failure mode] across [systems]. Add decision points, dependencies, evidence capture, approval gates, rollback criteria, and stakeholder updates.
```

## Limitations

- All service names, endpoints, thresholds, contacts, namespaces, and network ranges require environment-specific replacement.
- Commands are examples only and are not executed, authenticated, tested, or validated against live systems.
- The referenced implementation playbook is not included in the published file structure.
- Coverage focuses on service outages and database incidents, not every security, infrastructure, or compliance scenario.

## Best Practices

- Replace every placeholder and validate each command in a non-production environment before publishing the runbook.
- Require explicit approval, success criteria, rollback conditions, and verification for every production-changing action.
- Review the runbook after incidents, exercises, architecture changes, ownership changes, and monitoring updates.

## Anti Patterns

- Do not execute generic commands against production without confirming the environment, permissions, target, and expected impact.
- Do not rely on one dashboard, one responder, or one mitigation path during a serious incident.
- Do not declare resolution before customer impact, service health, data integrity, and rollback stability are verified.

## Security Audit

- Audited at: 2026-07-24T01:13:51.918\+00:00
- Summary: Most static alerts misread Markdown syntax, reference links, or read-only examples. Four network findings are confirmed because the templates prescribe state-changing requests and an applyable broad network policy. One semantic finding covers production-changing commands that lack immediate approval safeguards; no prompt injection or exfiltration was found.

## Stats

- Views: 96
- Downloads: 11
- Favorites: 0
- Popularity score: 0