incident-response

Guides production incident triage, mitigation, resolution, and post-mortem analysis.

3|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/Fabric-Pro/fabric-oss --skill incident-response-fabric-pro
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: incident-response
Source: https://github.com/Fabric-Pro/fabric-oss/tree/main/.cursor/skills/incident-response
Command: npx skills add https://github.com/Fabric-Pro/fabric-oss --skill incident-response-fabric-pro

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Production outages and critical bugs demand fast, coordinated action, but without a structured process teams lose time on ad-hoc decisions, inconsistent severity assessments, and poor communication. This Skill provides a repeatable incident response workflow covering detection, triage, mitigation, resolution, and post-mortem analysis. ## Core Features & Use Cases - Structured Response Process: Follows a five-phase workflow (Detect, Triage, Mitigate, Resolve, Postmortem) with concrete actions at each stage. - Severity Classification: Defines P0-P4 severity levels to standardize prioritization and escalation decisions. - Runbooks and Templates: Includes an example runbook for high CPU usage and a status communication template for stakeholder updates. - Use Case: When a production database bottleneck degrades service for 20% of users, use this Skill to triage the incident as P1, coordinate the on-call response, communicate status updates, and document a post-mortem with root cause and action items. ## Quick Start Help me triage and respond to a production outage where users are experiencing slow load times, including a status update and post-mortem outline.

Frequently Asked Questions about incident-response

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I respond to a production outage step by step?▼

Follow the five-phase process: detect the issue via monitoring or user reports, triage by assigning a severity level and paging on-call, mitigate with rollback or hotfix, resolve by verifying the fix and monitoring metrics, then conduct a post-mortem documenting timeline and root cause.

How do I classify incident severity levels?▼

Use the P0-P4 scale: P0 for complete outages or data loss, P1 for major broken features with revenue impact, P2 for degraded performance with workarounds, P3 for minor bugs, and P4 for informational or enhancement requests.

What should an incident post-mortem include?▼

A post-mortem should include a timeline of events, root cause analysis, action items, and follow-up tasks. The goal is preventing recurrence, not assigning blame, and templates from resources like dastergon/postmortem-templates can structure the document.

How do I write a status update during an incident?▼

Include the current status, user impact percentage, estimated time to resolution, and a chronological list of updates with timestamps. State when the next update will arrive so stakeholders know when to expect new information.

When should I create a runbook for an incident?▼

Create runbooks for recurring or predictable issues like high CPU usage or memory leaks. Document symptoms, investigation commands, mitigation steps, and resolution criteria so any on-call engineer can respond without deep system knowledge.