agentleFS
Sign inStart free
LukeJMaddenLukeJMadden/Veltrix-skills/skills/operations/incident-response/SKILL.md

incident-response

Skill1 starsChanged 8 months agoMITView on GitHub

5-step incident response playbook. Use when a service is down, degraded, or experiencing errors.

83 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use dora-metrics, background-jobs and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • jholhewresSkill

    dora-metrics

    Calculate DORA metrics from git + deploy logs

    Also in 3 projects that use this

  • YepAPISkill

    background-jobs

    Queue workers with BullMQ/Inngest/Trigger.dev, job retries, dead letter queues, concurrency.

    Also in 4 projects that use this

  • MicrosoftSkill

    data-modeling

    Use when the app needs to store or read data — records, a database, entities, CRUD, lists, "save/remember X", or per-user data with row-level security. This app's data layer is Rayfin's: you declare entities as TypeScript classes with decorators in rayfin/data/, register them in the schema, and read/write them through the typed rayfin-client. Covers: defining an @entity, field decorators, registering it, per-entity access with @role, owner-only row-level security, and the client query/mutation API. Triggers: data, database, model, entity, schema, table, record, CRUD, create, read, update, delete, list, store, save, persist, per-user, row-level security, RLS, access control, ownership.

    Also in 7 projects that use this

  • YepAPISkill

    data-pipelines

    ETL patterns, cron scheduling, queue-based processing, and batch jobs with Inngest/BullMQ.

    Also in 4 projects that use this

  • mmondoraSkill

    infrastructure-as-code

    Infrastructure as Code with Terraform and Pulumi. State management, modularity, drift detection, secrets handling. Use when provisioning cloud resources, writing Terraform/Pulumi modules, or managing infrastructure configuration.

    Also in 5 projects that use this

  • csiddhant796-blipSkill

    threat-detection

    Use when hunting for threats in an environment, analyzing IOCs, or detecting behavioral anomalies in telemetry. Covers hypothesis-driven threat hunting, IOC sweep generation, z-score anomaly detection, and MITRE ATT&CK-mapped signal prioritization.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 12 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 70 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow this playbook for every incident.

    line 6
  2. Distinctive:

    Stop the bleeding. Prevent further damage.

    line 11
  3. Distinctive:

    Check logs: what changed? when did errors start?

    line 19
  4. Distinctive:

    Check deployments: was there a recent deploy?

    line 20
  5. Distinctive:

    Check external dependencies: is a third-party service down?

    line 21
  6. Distinctive:

    Check metrics: traffic spike?

    line 22
  7. Distinctive:

    Prefer reverting over forward-fixing

    line 27
  8. Distinctive:

    If forward-fixing: change one thing, verify, repeat

    line 28
  9. Distinctive:

    Do NOT refactor while fixing an incident

    line 29
  10. Distinctive:

    Do NOT add new features while fixing an incident

    line 30
  11. Distinctive:

    Run a smoke test on the critical path

    line 37
  12. Distinctive:

    Document what happened so it doesn't happen again.

    line 40

“Common” is measured: kept by at least 6 in 10 of the 70 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Follow this playbook for every incident. No shortcuts.

The 5 Steps

1. CONTAIN (first 5 minutes)

Stop the bleeding. Prevent further damage.

  • Can we rollback to the last working version?
  • Can we disable the broken feature without taking down everything?
  • Is customer data at risk?
  • Who needs to be notified right now?

2. DIAGNOSE (next 15 minutes)

Find the root cause using data, not guesses.

  • Check logs: what changed? when did errors start?
  • Check deployments: was there a recent deploy?
  • Check external dependencies: is a third-party service down?
  • Check metrics: traffic spike? memory leak? disk full?
  • Form a hypothesis and verify before acting

3. FIX (next 30 minutes)

Apply the minimum change needed.

  • Prefer reverting over forward-fixing
  • If forward-fixing: change one thing, verify, repeat
  • Do NOT refactor while fixing an incident
  • Do NOT add new features while fixing an incident

4. VERIFY (next 15 minutes)

Confirm the fix works and has no side effects.

  • Is the error gone from logs?
  • Are affected customers able to use the service?
  • Are metrics back to normal baselines?
  • Run a smoke test on the critical path

5. POSTMORTEM (within 24 hours)

Document what happened so it doesn't happen again.

  • Timeline — minute-by-minute of the incident
  • Root cause — what actually broke and why
  • Impact — who was affected, for how long, revenue impact
  • What went well — what worked in the response
  • What went poorly — where we lost time
  • Action items — specific preventive measures with owners and dates

Severity Classification

LevelDescriptionResponse timeEscalation
SEV1Service down, data breachImmediateHuman + all hands
SEV2Major feature brokenWithin 1 hourHuman notified
SEV3Minor degradationWithin 4 hoursAutomated
SEV4Cosmetic or non-blockingNext business dayTicket created

Communication Template

[STATUS: Investigating/Identified/Monitoring/Resolved]
Impact: [what's affected]
Started: [time]
Current action: [what we're doing right now]
Next update: [when]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free