Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

Back to skills

Incident Response

ASecurity

Incident management lifecycle — triage, communicate, mitigate, postmortem. Three modes — new (start incident), update (status update), postmortem (blameless RCA report).

40 stars
0 votes
0 copies
0 views
Added 9/22/2026
developmentgobashrailsgitsecurityperformance

Works with

mcp

Security Analysis

A100/100

Scanned 9/22/2026

Install to Claude Code

$npx -y skills add drafthq/draft --skill incident-response --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Incident Response?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Incident Response
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/drafthq-incident-response/badge)](https://www.skillsdirectory.com/skills/drafthq-incident-response)

More formats (shields.io, HTML) on the badges page.

Download Zip
Files
SKILL.md
---
name: incident-response
description: Incident management lifecycle — triage, communicate, mitigate, postmortem. Three modes — new (start incident), update (status update), postmortem (blameless RCA report).
---

# Incident Response

You are managing an incident through its full lifecycle using structured incident management practices.

## Red Flags — STOP if you're

- Fixing before communicating (stakeholders must know first)
- Skipping severity classification
- Writing a postmortem with blame (blameless only)
- Closing an incident without prevention items
- Ignoring rollback as a mitigation option

**Communicate first. Fix second. Learn always.**

---

## Pre-Check

1. Check for Draft context:

```bash
ls draft/ 2>/dev/null
```

This skill works standalone — incidents don't wait for project setup.

2. If available, follow the base procedure in `core/shared/draft-context-loading.md`.

## Step 1: Parse Arguments

- `/draft:incident-response new <description>` — Start new incident
- `/draft:incident-response update <status>` — Post status update
- `/draft:incident-response postmortem` — Generate postmortem report
- `/draft:incident-response` (no args) — Interactive: ask which mode

---

## NEW Mode — Start Incident

### Step 2: Triage

Classify severity:

| Level | Response Time | Who | Examples |
|-------|--------------|-----|---------|
| **SEV1** | Immediate, all-hands | Entire team | Data loss, complete outage, security breach |
| **SEV2** | 15 minutes | On-call + team lead | Major feature broken, significant degradation |
| **SEV3** | 1 hour | On-call | Minor feature broken, workaround exists |
| **SEV4** | Next business day | Assigned engineer | Cosmetic issue, minor inconvenience |

Assess:

1. **What is broken?** (from description or Jira ticket)
2. **Who is affected?** (from `draft/product.md` user types if available)
3. **What is the blast radius?** (from `draft/.ai-context.md` service topology if available)
4. **Is data at risk?** (escalate to SEV1 if yes)

### Step 3: Communicate

Generate initial status update:

```yaml
INCIDENT: {description}
Severity: SEV{1-4}
Impact: {who/what is affected}
Status: Investigating
Commander: {name or "unassigned"}
Next update: {time — SEV1: 15min, SEV2: 30min, SEV3: 1hr}
```

### Step 4: Gather Evidence

- If Jira ticket linked: pull details via MCP (`get_issue`, `get_issue_description`, `get_issue_comments`)
- Extract URLs and log paths from ticket
- Use `curl`/`wget` to fetch dashboards or error pages mentioned
- Use `ssh` to access remote log paths if mentioned
- If GitHub MCP available: check recent deployments (`last 24h`)
- Record all evidence in incident timeline

### Step 5: Mitigate

Following `core/agents/ops.md` production-safety mindset:

1. **Can we rollback?** If yes and severity ≥ SEV2: recommend rollback first, investigate after
2. **Can we hotfix?** If rollback not possible: identify minimal fix
3. **Can we mitigate?** Feature flag, config change, traffic routing
4. **Need to escalate?** If none of above work, escalate severity

Document all actions taken with timestamps.

### Step 6: Save Incident File

Save to: `draft/incidents/incident-<timestamp>.md` or `draft/tracks/<id>/incident.md`

```markdown
# Incident: {description}

| Field | Value |
|-------|-------|
| **Severity** | SEV{N} |
| **Status** | {Investigating/Mitigating/Resolved} |
| **Started** | {timestamp} |
| **Commander** | {name} |

## Timeline
| Time | Action |
|------|--------|
| {time} | Incident detected |
| {time} | Triage: classified as SEV{N} |
| {time} | {mitigation action} |

## Evidence
| Source | Finding |
|--------|---------|
| {source} | {finding} |

## Status Updates
{chronological updates}
```

---

## UPDATE Mode

1. Read existing incident file
2. Add new timeline entry with timestamp
3. Update status field if changed
4. Update severity if changed (with justification)
5. Generate formatted status update for stakeholders

---

## POSTMORTEM Mode

### Step 2: Gather Timeline

- Read incident file for timeline and evidence
- `git log` for related commits during incident window
- If Jira MCP: pull ticket history and transitions
- If GitHub MCP: pull changes submitted during/after incident

### Step 3: Root Cause Analysis

Reference `core/agents/rca.md` methodology:

1. **5 Whys Analysis:**
   - Why did {symptom} happen? → Because {cause 1}
   - Why {cause 1}? → Because {cause 2}
   - Continue until root cause reached (typically 3-5 levels)

2. **Root Cause Classification:**
   - Logic error | Race condition | Data corruption | Configuration error
   - Dependency failure | Capacity exceeded | Security exploit | Human error

3. **Detection Lag:** When was the bug introduced vs when was it detected?

4. **SLO Impact:** Which SLOs were affected and by how much?

5. **HLD Claims vs Reality ():** If the affected service has a `hld.md` (search `draft/tracks/*/hld.md` for §Detailed Design components matching the failing module), compare incident behavior against HLD claims:
   - Did §Resiliency claims (graceful degradation, circuit breakers, timeout handling) actually hold during the incident?
   - Did §Multi-tenancy claims (tenant isolation, predictable performance) hold? Did one tenant impact another?
   - Did §Upgrade claims (backward compat, dependent service order) hold? Did an upgrade trigger this?
   - Did §Scale claims hold under the load that triggered the incident?
   - Did §Observability claims hold — were the listed key metrics sufficient for detection?
   - Cite the specific HLD §section using section text (`draft/tracks/<id>/hld.md §Resiliency`) for each gap — avoid markdown anchor slugs since renderers (GitHub, mkdocs, Hugo) generate different slugs for nested headings. These citations feed the §Action Items as "amend HLD §X — claim was {claim} but reality showed {reality}."

### Step 4: Generate Postmortem

**MANDATORY: Include YAML frontmatter with git metadata.** Follow `core/shared/git-report-metadata.md`.

Save to: `draft/incidents/postmortem-<timestamp>.md` with symlink `postmortem-latest.md`
Or track-scoped: `draft/tracks/<id>/postmortem.md`

```markdown
# Postmortem: {incident title}

## Summary
{2-3 sentences: what happened, impact, duration}

## Impact
- **Duration:** {start} to {end} ({total time})
- **Users affected:** {count or percentage}
- **SLO impact:** {which SLOs, by how much}
- **Data impact:** {any data loss or corruption}

## Timeline
| Time | Event |
|------|-------|
| {time} | {event} |

## Root Cause
{1-2 sentence root cause statement}

### 5 Whys
1. Why? → {answer}
2. Why? → {answer}
...

### Classification
- **Type:** {classification}
- **Detection Lag:** {introduced} → {detected} = {gap}

## What Went Well
- {positive observations}

## What Went Wrong
- {things that made the incident worse}

## Design Claims vs Reality
{populated when an HLD was available — list each HLD claim that did not hold, citing the specific §section}

| HLD Section | Claim | Reality During Incident | Recommended HLD Amendment |
|-------------|-------|-------------------------|---------------------------|
| §Resiliency | {what was claimed} | {what actually happened} | {how to update HLD} |

## Action Items
| # | Action | Owner | Deadline | Status |
|---|--------|-------|----------|--------|
| 1 | {detection improvement} | {name} | {date} | [ ] |
| 2 | {process improvement} | {name} | {date} | [ ] |
| 3 | {code improvement} | {name} | {date} | [ ] |
| 4 | Amend `draft/tracks/<id>/hld.md` §{section} (if claim drift identified) | {design owner} | {date} | [ ] |
```

### Step 5: Jira Sync

Follow `core/shared/jira-sync.md`:

- Attach postmortem to Jira ticket
- Post comment: "[draft] Postmortem complete. Root cause: {1-line summary}. {N} action items."

⚠️ **Test Writing Guardrail:** If postmortem identifies missing tests, ASK: "Want me to create regression test tasks? [Y/n]"

## Cross-Skill Dispatch

- **Triggered by:** `/draft:new-track` when incident keywords detected in description
- **Postmortem feeds into:** `/draft:regression` (find the breaking commit), `/draft:learn` (update guardrails)
- **Can create:** Bug track via `/draft:new-track` for the fix

## Error Handling

**If no incident file found (update/postmortem mode):** List available incidents, ask which one
**If no Jira ticket:** Proceed without sync, note: "Link a Jira ticket for automatic sync"

Attribution

drafthqdrafthq
View sourceMore from drafthq →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Browser Extension Developer

Use this skill when developing or maintaining browser extension code in the `browser/` directory, including Chrome/Firefox/Edge compatibility, content scripts, background scripts, or i18n updates.

284072 votes

Seo Optimizer

SEO optimization with keyword analysis, readability assessment, technical validation, content quality. Use for search rankings, blog posts, content audits, or encountering keyword density, readability scores, meta tags, schema markup errors.

2192 votes

Google Official Seo Guide

Official Google SEO guide covering search optimization, best practices, Search Console, crawling, indexing, and improving website search visibility based on official Google documentation

1862 votes

Tanstack Start

Build a full-stack TanStack Start app on Cloudflare Workers from scratch — SSR, file-based routing, server functions, D1+Drizzle, better-auth, Tailwind v4+shadcn/ui. Use whenever the user mentions TanStack Start, asks to scaffold a full-stack Cloudflare app with SSR, wants an SSR dashboard, or asks for a React 19 + Cloudflare Workers app with file-based routing and server functions — even if they don't name TanStack Start specifically. No template repo — Claude generates every file fresh per ...

9881 votes

Pentest

PTES-aligned adversarial security audit for backend, frontend, and mobile applications. Produces a CVSS-scored Hacker Report with verified PoCs and phased remediation.

5491 votes
View all in development →