agentsclimarketplace

Incident readiness

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/devops/incident-readiness

Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill incident-readiness

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use to prepare for production incidents — on-call and escalation, severity levels, runbooks for likely failures, alert-to-response wiring, communication paths, and blameless postmortems that feed regression tests. Preparation before incidents, not response during one.

SKILL.md

5.4 KB, as published. Nobody here has run it

Incident Readiness

Purpose

Be ready to respond to production incidents calmly and fast: known on-call and escalation, severity definitions, runbooks for the likely failures, and a learning loop that turns incidents into regression tests — set up before the incident, not improvised during it.

When to Use

  • Before production launch and as the system grows in criticality.
  • Not for the deploy-reversal mechanism (rollback-planning) or metric/alert setup (monitoring-logging) — this wires those into human response.

Inputs

  • Monitoring/alerting (monitoring-logging), rollback plan (rollback-planning).
  • Team/on-call structure, critical flows, business impact tolerances.

Discovery Questions

  • Who is on-call, how are they paged, and what's the escalation path if they don't respond?
  • What are the severity levels, and what response/comms does each trigger?
  • What are the most likely failures, and is there a runbook for each?
  • How are incidents reviewed so the same one doesn't recur?

Responsibilities

  • On-call + escalation: defined rotation, paging path (from monitoring-logging alerts), and escalation when the first responder is unavailable — no "hope someone notices."
  • Severity levels: clear definitions (e.g. SEV1 total outage/data loss → SEV3 minor degradation) each mapping to expected response time, who's involved, and comms.
  • Runbooks for likely incidents (database down, deploy gone bad → rollback-planning, integration outage → ../../backend/third-party-integrations, queue backlog, secret compromise → ../../security/secrets-audit): symptoms, diagnosis steps, mitigation, and links to the relevant tools.
  • Alert-to-response wiring: each critical alert leads to a runbook and an owner — closing the loop monitoring-logging opens.
  • Communication: internal coordination channel + external status/comms path for user-facing incidents; who speaks for the incident.
  • Blameless postmortems: after significant incidents, a factual timeline + root cause + action items — and feed the fix into a regression test (../../testing/regression-testing, ../../security/security-regression-testing) so it can't silently recur; track action items to done.

Required Workflow

  1. Define on-call rotation + escalation + paging.
  2. Define severity levels → response/comms per level.
  3. Write runbooks for the likely failures; link tools.
  4. Wire critical alerts → runbook + owner.
  5. Set up incident comms (internal + external).
  6. Establish blameless postmortems that produce regression tests + tracked actions.

Decision Rules

  • Preparation over improvisation — decisions made calm beforehand beat decisions made at 3 a.m. mid-outage.
  • Every critical alert maps to a runbook and an owner, or it's noise.
  • Postmortems are blameless and produce a regression test — an incident that leaves no test invites its own sequel.
  • Severity drives response — not everything is a SEV1, and a real SEV1 shouldn't wait behind triage debate.

Rules

  • On-call, escalation, and severities are defined before launch.
  • Likely failures have runbooks; critical alerts route to them.
  • Significant incidents get blameless postmortems with tracked, test-backed actions.

Anti-Patterns

  • No on-call — incidents found by users tweeting.
  • Alerts with no runbook, response improvised each time.
  • Blameful postmortems that suppress honesty and learning.
  • Postmortems with action items nobody tracks or tests.
  • Everything treated as maximum severity (or nothing is).

Validation Checklist

  • On-call rotation + escalation + paging defined.
  • Severity levels → response/comms mapped.
  • Runbooks for likely failures; tools linked.
  • Critical alerts wired to runbook + owner.
  • Incident comms (internal + external) set.
  • Blameless postmortem process feeding regression tests + tracked actions.

Definition of Done

A recorded incident-readiness setup — on-call and escalation, severity levels, runbooks for likely failures wired from alerts, communication paths, and a blameless postmortem process that produces regression tests and tracked actions — all in place before production.

Related Skills

monitoring-logging, rollback-planning, production-readiness, ../../backend/backend-observability, ../../backend/third-party-integrations, ../../security/secrets-audit, ../../testing/regression-testing, ../../security/security-regression-testing, ../../release-planning.

Related Knowledge

../../../knowledge/ (on-call structure, likely failures, impact tolerances).

Related References

../../../references/devops/ (runbooks, postmortem template, when populated).

Context Loading Guidance

  • Requires: monitoring/alerting, rollback plan, on-call structure, critical flows.
  • Does not require: metric-emission internals, app feature code.
  • May load: rollback-planning, monitoring-logging.
  • Stop when: on-call, severities, runbooks, comms, and postmortem loop are recorded.

Token Efficiency Guidance

The runbook set + severity table + on-call/escalation map are the artifacts; keep each runbook executable and short.

Gives 0 of the 12 instructions most incident response skills give

Counted across 224 of the 224 authors here whose files we hold, read 2026-08-06

  • Conduct a blameless postmortem within 48 hoursin 24 of 224, across 14 files
  • perform root cause analysis using five whysin 24 of 224, across 20 files
  • write a blameless postmortemin 22 of 224, across 19 files
  • Update stakeholders every 15 to 30 minutesin 19 of 224, across 9 files
  • assign an owner and due date to every action itemin 18 of 224
  • Classify incident severity within 5 minutesin 17 of 224, across 7 files
  • Create a post-mortem documentin 17 of 224, across 14 files
  • Assign all action items with deadlinesin 14 of 224, across 6 files
  • Implement immediate mitigation prioritizing user restorationin 13 of 224, across 3 files
  • assign one incident commanderin 12 of 224
  • Stop and ask for clarification if inputs are missingin 10 of 224, across 2 files
  • Escalate earlyin 10 of 224, across 2 files

Said here and by no other author read

  • write runbooks for likely system failures
  • wire every critical alert to a runbook and owner
  • set up internal and external communication channels
  • establish blameless postmortems for significant incidents
  • convert postmortem findings into regression tests
  • keep each runbook executable and short

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.