incident-runbook-creator

Name: incident-runbook-creator
Author: girijashankarj

27stars3forks

How to install incident-runbook-creator?

girijashankarj/cursor-handbook/incident-runbook-creator

$npx -y skills add girijashankarj/cursor-handbook --skill incident-runbook-creator

Installs into the current project.

Summary

Generate operational runbooks for services covering common failure scenarios, diagnostics, and recovery steps. Use when the user asks to create a runbook, document incident response, or prepare on-call guides.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Incident Runbook Creator
2
3	Create structured operational runbooks for diagnosing and resolving production incidents.
4
5	## Trigger
6	When the user asks to create a runbook, document incident procedures, or prepare on-call documentation.
7
8	## Prerequisites
9	- [ ] Service or system to document identified
10	- [ ] Common failure scenarios known or discoverable
11	- [ ] Access to monitoring/alerting configuration
12
13	## Steps
14
15	### Step 1: Identify the Service
16	- [ ] Service name and purpose
17	- [ ] Dependencies (databases, caches, queues, external APIs)
18	- [ ] Deployment target (Kubernetes, Lambda, EC2, etc.)
19	- [ ] Health check endpoint
20	- [ ] Key metrics and dashboards
21
22	### Step 2: Catalog Failure Scenarios
23
24	\| Category \| Common Scenarios \|
25	\|----------\|-----------------\|
26	\| Availability \| Service down, health check failing, DNS issues \|
27	\| Performance \| High latency, timeout errors, memory leaks \|
28	\| Data \| Database connection failures, replication lag, disk full \|
29	\| Dependencies \| Upstream service down, API rate limited, cert expired \|
30	\| Capacity \| CPU saturation, OOM kills, connection pool exhausted \|
31	\| Security \| Auth failures spike, DDoS, certificate expiry \|
32	\| Deployment \| Bad deploy, config change, feature flag issue \|
33
34	### Step 3: Create Runbook Template
35
36	For each scenario:
37
38	```markdown
39	## [Scenario Name]
40
41	### Alert
42	- Alert name: [matching alert name from monitoring]
43	- Severity: P1 / P2 / P3
44	- SLA: Acknowledge in X min, resolve in Y min
45
46	### Symptoms
47	- [What the user/system experiences]
48	- [What alerts fire]
49	- [What metrics look abnormal]
50
51	### Diagnosis Steps
52	1. Check [dashboard/metric]: `[command or URL]`
53	2. Check [logs]: `[query or command]`
54	3. Check [dependency]: `[health check command]`
55	4. Verify [configuration]: `[command]`
56
57	### Resolution Steps
58	1. Quick mitigation: [immediate action to restore service]
59	2. Root cause fix: [steps to address underlying issue]
60	3. Verification: [how to confirm the fix worked]
61
62	### Rollback
63	- [Steps to rollback if resolution makes things worse]
64
65	### Escalation
66	- Team: [team name]
67	- Contact: [on-call rotation or channel]
68	- Escalation path: [who to contact if unresolved in N minutes]
69
70	### Post-Incident
71	- [ ] Create incident ticket
72	- [ ] Update this runbook if new information found
73	- [ ] Schedule post-mortem within 48 hours
74	```
75
76	### Step 4: Generate Common Runbook Entries
77
78	#### Service Down
79	```markdown
80	## Service Unresponsive
81
82	### Diagnosis
83	1. Health check: `curl -s [HEALTH_ENDPOINT] \| jq .`
84	2. Pod/container status: `kubectl get pods -l app=[SERVICE] -n [NAMESPACE]`
85	3. Recent deployments: `kubectl rollout history deployment/[SERVICE]`
86	4. Logs: `kubectl logs -l app=[SERVICE] --tail=100 --since=5m`
87
88	### Resolution
89	1. If recent deploy → rollback: `kubectl rollout undo deployment/[SERVICE]`
90	2. If OOM → increase memory limits and restart
91	3. If crash loop → check logs for startup errors
92	4. If dependency down → check dependency health, enable circuit breaker
93	```
94
95	#### High Latency
96	```markdown
97	## High Latency (p99 > 2s)
98
99	### Diagnosis
100	1. Check request rate for traffic spike
101	2. Check database query latency
102	3. Check connection pool utilization
103	4. Check external dependency latency
104	5. Check CPU/memory for resource saturation
105
106	### Resolution
107	1. If traffic spike → scale up: `kubectl scale deployment/[SERVICE] --replicas=N`
108	2. If slow queries → identify and optimize (check slow query log)
109	3. If dependency slow → enable/tighten circuit breaker timeouts
110	4. If resource saturation → increase limits, add nodes
111	```
112
113	### Step 5: Add Service-Specific Sections
114	- [ ] Custom commands for the specific tech stack
115	- [ ] Links to dashboards (use `[DASHBOARD_URL]` placeholders)
116	- [ ] Database-specific diagnostics (connection count, replication lag)
117	- [ ] Queue-specific diagnostics (depth, consumer lag)
118
119	### Step 6: Add Contact and Escalation Info
120	- [ ] On-call rotation schedule
121	- [ ] Escalation matrix by severity
122	- [ ] Communication channels (use placeholders, not real URLs)
123	- [ ] Status page update process
124
125	### Step 7: Validate and Output
126	- [ ] Verify all commands use placeholders for real values
127	- [ ] Verify runbook covers at least the top 5 failure scenarios
128	- [ ] Verify each entry has diagnosis, resolution, and rollback
129	- [ ] Save to `docs/runbooks/` or project-standard location
130
131	## Rules
132	- NEVER include real hostnames, IPs, or credentials — use placeholders
133	- ALWAYS include rollback steps for every resolution
134	- ALWAYS include escalation path and contacts
135	- ALWAYS include verification steps (how to confirm the fix)
136	- Write for someone unfamiliar with the service (on-call engineer at 3 AM)
137	- Keep commands copy-pasteable
138	- Link to dashboards and documentation
139
140	## Completion
141	Compreh

People who liked this also viewed

6 picks

Type

incident-runbook-creator

27stars3forks

View on GitHub

How to install incident-runbook-creator?

girijashankarj/cursor-handbook/incident-runbook-creator

$npx -y skills add girijashankarj/cursor-handbook --skill incident-runbook-creator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill: Incident Runbook Creator
2
3	Create structured operational runbooks for diagnosing and resolving production incidents.
4
5	## Trigger
6	When the user asks to create a runbook, document incident procedures, or prepare on-call documentation.
7
8	## Prerequisites
9	- [ ] Service or system to document identified
10	- [ ] Common failure scenarios known or discoverable
11	- [ ] Access to monitoring/alerting configuration
12
13	## Steps
14
15	### Step 1: Identify the Service
16	- [ ] Service name and purpose
17	- [ ] Dependencies (databases, caches, queues, external APIs)
18	- [ ] Deployment target (Kubernetes, Lambda, EC2, etc.)
19	- [ ] Health check endpoint
20	- [ ] Key metrics and dashboards
21
22	### Step 2: Catalog Failure Scenarios
23
24	\| Category \| Common Scenarios \|
25	\|----------\|-----------------\|
26	\| Availability \| Service down, health check failing, DNS issues \|
27	\| Performance \| High latency, timeout errors, memory leaks \|
28	\| Data \| Database connection failures, replication lag, disk full \|
29	\| Dependencies \| Upstream service down, API rate limited, cert expired \|
30	\| Capacity \| CPU saturation, OOM kills, connection pool exhausted \|
31	\| Security \| Auth failures spike, DDoS, certificate expiry \|
32	\| Deployment \| Bad deploy, config change, feature flag issue \|
33
34	### Step 3: Create Runbook Template
35
36	For each scenario:
37
38	```markdown
39	## [Scenario Name]
40
41	### Alert
42	- Alert name: [matching alert name from monitoring]
43	- Severity: P1 / P2 / P3
44	- SLA: Acknowledge in X min, resolve in Y min
45
46	### Symptoms
47	- [What the user/system experiences]
48	- [What alerts fire]
49	- [What metrics look abnormal]
50
51	### Diagnosis Steps
52	1. Check [dashboard/metric]: `[command or URL]`
53	2. Check [logs]: `[query or command]`
54	3. Check [dependency]: `[health check command]`
55	4. Verify [configuration]: `[command]`
56
57	### Resolution Steps
58	1. Quick mitigation: [immediate action to restore service]
59	2. Root cause fix: [steps to address underlying issue]
60	3. Verification: [how to confirm the fix worked]
61
62	### Rollback
63	- [Steps to rollback if resolution makes things worse]
64
65	### Escalation
66	- Team: [team name]
67	- Contact: [on-call rotation or channel]
68	- Escalation path: [who to contact if unresolved in N minutes]
69
70	### Post-Incident
71	- [ ] Create incident ticket
72	- [ ] Update this runbook if new information found
73	- [ ] Schedule post-mortem within 48 hours
74	```
75
76	### Step 4: Generate Common Runbook Entries
77
78	#### Service Down
79	```markdown
80	## Service Unresponsive
81
82	### Diagnosis
83	1. Health check: `curl -s [HEALTH_ENDPOINT] \| jq .`
84	2. Pod/container status: `kubectl get pods -l app=[SERVICE] -n [NAMESPACE]`
85	3. Recent deployments: `kubectl rollout history deployment/[SERVICE]`
86	4. Logs: `kubectl logs -l app=[SERVICE] --tail=100 --since=5m`
87
88	### Resolution
89	1. If recent deploy → rollback: `kubectl rollout undo deployment/[SERVICE]`
90	2. If OOM → increase memory limits and restart
91	3. If crash loop → check logs for startup errors
92	4. If dependency down → check dependency health, enable circuit breaker
93	```
94
95	#### High Latency
96	```markdown
97	## High Latency (p99 > 2s)
98
99	### Diagnosis
100	1. Check request rate for traffic spike
101	2. Check database query latency
102	3. Check connection pool utilization
103	4. Check external dependency latency
104	5. Check CPU/memory for resource saturation
105
106	### Resolution
107	1. If traffic spike → scale up: `kubectl scale deployment/[SERVICE] --replicas=N`
108	2. If slow queries → identify and optimize (check slow query log)
109	3. If dependency slow → enable/tighten circuit breaker timeouts
110	4. If resource saturation → increase limits, add nodes
111	```
112
113	### Step 5: Add Service-Specific Sections
114	- [ ] Custom commands for the specific tech stack
115	- [ ] Links to dashboards (use `[DASHBOARD_URL]` placeholders)
116	- [ ] Database-specific diagnostics (connection count, replication lag)
117	- [ ] Queue-specific diagnostics (depth, consumer lag)
118
119	### Step 6: Add Contact and Escalation Info
120	- [ ] On-call rotation schedule
121	- [ ] Escalation matrix by severity
122	- [ ] Communication channels (use placeholders, not real URLs)
123	- [ ] Status page update process
124
125	### Step 7: Validate and Output
126	- [ ] Verify all commands use placeholders for real values
127	- [ ] Verify runbook covers at least the top 5 failure scenarios
128	- [ ] Verify each entry has diagnosis, resolution, and rollback
129	- [ ] Save to `docs/runbooks/` or project-standard location
130
131	## Rules
132	- NEVER include real hostnames, IPs, or credentials — use placeholders
133	- ALWAYS include rollback steps for every resolution
134	- ALWAYS include escalation path and contacts
135	- ALWAYS include verification steps (how to confirm the fix)
136	- Write for someone unfamiliar with the service (on-call engineer at 3 AM)
137	- Keep commands copy-pasteable
138	- Link to dashboards and documentation
139
140	## Completion
141	Compreh

People who liked this also viewed

6 picks

Type