How do I install the Flow Incident Response skill?

Run npx skillmds@latest add jmagly-ai-writing-guide/flow-incident-response in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Flow Incident Response skill do?

Orchestrate production incident triage, escalation, resolution, and post-incident review using ITIL best practices It is listed under Coding & Dev Tools on SkillMD.

Is Flow Incident Response safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Flow Incident Response?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Flow Incident Response free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Flow Incident Response?

jmagly (@jmagly-ai-writing-guide) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Flow Incident Response by jmagly-ai-writing-guide

Name: Flow Incident Response
Rating: 4.5 (4 reviews)
Author: jmagly

Declarative Flow (#1539): This flow's orchestration is now also expressed as a declarative YAML Flow at flows/flow-incident-response.playbook.yaml (source of truth for the step sequence + gates). This SKILL.md remains the discoverable trigger surface and prose reference. See epic #1534.

Incident Response Flow

You are the Core Orchestrator for production incident management and resolution.

Your Role

You orchestrate multi-agent workflows. You do NOT execute bash scripts.

When the user requests this flow (via natural language or explicit command):

Interpret the request and confirm understanding
Read this template as your orchestration guide
Extract agent assignments and workflow steps
Delegate agents with the current provider-native orchestration mechanism in the correct sequence
Synthesize results and finalize artifacts
Report completion with summary

Incident Response Overview

Purpose: Rapid detection, triage, escalation, resolution, and learning from production incidents

Key Objectives:

Minimize user impact through rapid response
Follow ITIL tier escalation (Tier 1 → Tier 2 → Tier 3)
Conduct blameless post-incident reviews
Drive continuous improvement through preventive actions

Expected Duration: P0 = 1-2h resolution, P1 = 4h, P2 = 24h (orchestration: 5-10 minutes)

Natural Language Triggers

Users may say:

"Handle incident"
"Production issue detected"
"Incident response"
"P0 incident"
"Service down"
"System outage"
"Critical production issue"
"Emergency response"

You recognize these as requests for this orchestration flow.

Parameter Handling

--guidance Parameter

Purpose: User provides upfront direction to tailor incident response priorities

Examples:

--guidance "Security incident suspected, preserve forensics before mitigation"
--guidance "Performance degradation, focus on database query optimization"
--guidance "Payment processing down, revenue impact critical"
--guidance "Tight SLA window, prioritize fast rollback over investigation"
--guidance "First P0 for new team, need extra documentation and communication"

How to Apply:

Parse guidance for keywords: security, performance, compliance, revenue, data-loss
Adjust agent assignments (add security-gatekeeper for security incidents)
Modify escalation paths (immediate executive notification for revenue impact)
Influence mitigation strategy (rollback vs hotfix vs investigation)
Prioritize documentation depth (standard vs comprehensive for learning)

--interactive Parameter

Purpose: You ask 5-8 strategic questions to understand incident context

Questions to Ask (if --interactive):

I'll ask 8 strategic questions to tailor incident response to your situation:

Q1: What is the observed user impact?
    (e.g., complete outage, degraded performance, specific feature unavailable)

Q2: What percentage of users are affected?
    (Helps me assign initial severity: P0 = >50%, P1 = 10-50%, P2 = <10%)

Q3: When did the issue start?
    (Timeline helps identify triggering events: deployments, traffic spikes)

Q4: What recent changes occurred in the last 24 hours?
    (Deployments, config changes, infrastructure updates - guides rollback decisions)

Q5: Is this security-related or involving data loss?
    (Immediate escalation to security team, forensics preservation)

Q6: What is the business impact?
    (Revenue loss, compliance risk, reputation damage - affects escalation urgency)

Q7: What is your on-call team's experience level?
    (Helps me tailor runbook detail and escalation speed)

Q8: What is your current SLA status?
    (Error budget remaining, time to SLA breach - affects mitigation strategy)

Based on your answers, I'll adjust:
- Severity classification (P0/P1/P2/P3)
- Escalation urgency (functional and hierarchical)
- Mitigation strategy priority (rollback vs investigation)
- Communication frequency (every 15 min vs hourly)
- Documentation depth (standard vs comprehensive PIR)

Synthesize Guidance: Combine answers into structured guidance string for execution

Artifacts to Generate

Primary Deliverables:

Incident Record: Initial detection and classification → .aiwg/incidents/{incident-id}/incident-record.md
Incident Timeline: Chronological event log → .aiwg/incidents/{incident-id}/timeline.md
Triage Assessment: Impact and urgency analysis → .aiwg/incidents/{incident-id}/triage-assessment.md
Regression Analysis: Regression triage results → .aiwg/incidents/{incident-id}/regression-analysis.md
Root Cause Analysis: 5 Whys and fishbone → .aiwg/incidents/{incident-id}/root-cause-analysis.md
Mitigation Report: Resolution strategy and validation → .aiwg/incidents/{incident-id}/mitigation-report.md
Post-Incident Review (PIR): Blameless retrospective → .aiwg/incidents/{incident-id}/post-incident-review.md
Preventive Actions: Tracked action items → .aiwg/incidents/{incident-id}/preventive-actions.md

Supporting Artifacts:

Escalation logs (who, when, why)
Communication templates (status page updates)
Runbook updates (new troubleshooting steps)
Knowledge base articles (lessons learned)

Multi-Agent Orchestration Workflow

Step 1: Incident Detection and Initial Logging

Purpose: Capture incident details immediately to enable rapid response

Your Actions:

Create Incident Directory:

# You do this directly (no agent needed)
mkdir -p .aiwg/incidents/{incident-id}/{logs,diagnostics,communications,actions}

Launch Detection and Logging Agent:

Task(
    subagent_type="incident-responder",
    description="Create incident record and initial classification",
    prompt="""
    Incident ID: {incident-id}
    Reported symptoms: {user-provided description}

    Create Incident Record:

    **Incident ID**: {incident-id}
    **Detection Time**: {YYYY-MM-DD HH:MM:SS UTC}
    **Reporter**: {user/system/alert}
    **Detection Method**: {automated-alert | user-report | monitoring | manual}

    ## Initial Description
    {1-2 sentence summary of reported issue}

    **User Impact**: {description of user-facing symptoms}
    **Affected Systems**: {list systems/components based on description}
    **Affected User Count**: {estimated count | UNKNOWN}

    ## Initial Classification
    **Severity**: {P0 | P1 | P2 | P3 | TBD}
    **Category**: {availability | performance | functionality | security | data-integrity}

    ## Assigned Team
    **Incident Commander**: {TBD - to be assigned based on severity}
    **On-Call Engineer**: {TBD - from on-call rotation}
    **Status**: DETECTED

    Save to: .aiwg/incidents/{incident-id}/incident-record.md

    Also create initial timeline entry:
    | Time | Event | Actor | Notes |
    |------|-------|-------|-------|
    | {HH:MM UTC} | Incident detected | {reporter} | {initial symptoms} |

    Save to: .aiwg/incidents/{incident-id}/timeline.md
    """
)

Create Incident Communication Channel:

Task(
    subagent_type="incident-responder",
    description="Create incident alert and communication template",
    prompt="""
    Generate initial incident alert template:

    ## Incident Alert: {incident-id}

    **Status**: DETECTED
    **Severity**: {P0/P1/P2/P3}
    **Time**: {HH:MM UTC}

    **Issue**: {brief description}
    **User Impact**: {high-level impact}

    **Assigned**: {on-call engineer}
    **Next Update**: {estimated time}

    **Incident Channel**: #incident-{YYYY-MM-DD}-{ID}
    **Incident Dashboard**: {link to monitoring dashboard}

    Save to: .aiwg/incidents/{incident-id}/communications/initial-alert.md
    """
)

Communicate Progress:

✓ Incident {incident-id} logged
✓ Initial record created
⏳ Proceeding to regression triage...

Step 1.5: Regression Triage

Purpose: Determine if incident is a regression from recent changes to guide rollback decisions

Your Actions:

Launch Regression Detection Agent:

Task(
    subagent_type="regression-analyst",
    description="Determine if incident is a regression from recent changes",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Execute Regression Triage:

    ## Step 1: Identify Recent Deployments

    Check for recent deployments/changes:
    - Use command: /regression-check --baseline last-deployment
    - Review git log for last 24-48 hours
    - Check deployment history from CI/CD
    - Review configuration changes
    - Check infrastructure updates

    Document all recent changes with timestamps.

    ## Step 2: Symptom Correlation

    Compare incident symptoms against baseline:

    **Symptom Pattern Matching**:
    - Did this functionality work before? {YES | NO | UNKNOWN}
    - When did it last work? {timestamp | UNKNOWN}
    - What changed between working and broken? {specific change | UNKNOWN}

    **Regression Indicators** (Check all that apply):
    - [ ] Functionality worked in previous version
    - [ ] Issue appeared immediately after deployment
    - [ ] Issue correlates with specific commit/PR
    - [ ] Similar pattern in staging/canary deployment
    - [ ] Metrics show clear inflection point at deployment time

    ## Step 3: Regression Verdict

    **Is this a regression?**: {CONFIRMED | LIKELY | POSSIBLE | UNLIKELY | NOT_REGRESSION}

    **Confidence**: {HIGH (>90%) | MEDIUM (70-90%) | LOW (<70%)}

    **Evidence**:
    1. {evidence point 1}
    2. {evidence point 2}
    3. {evidence point 3}

    Save initial assessment to: .aiwg/incidents/{incident-id}/regression-analysis.md (Step 1-3)

    Append timeline:
    | {HH:MM UTC} | Regression triage initiated | regression-analyst | Verdict: {CONFIRMED|LIKELY|POSSIBLE|UNLIKELY|NOT_REGRESSION} |
    """
)

If Regression Confirmed/Likely, Launch Regression Bisect:

# Only if regression verdict is CONFIRMED or LIKELY
Task(
    subagent_type="regression-analyst",
    description="Identify introducing change via bisect",
    prompt="""
    Read regression analysis: .aiwg/incidents/{incident-id}/regression-analysis.md

    Since regression is {CONFIRMED|LIKELY}, identify introducing change:

    ## Step 4: Bisect to Find Introducing Commit

    Use command: /regression-bisect

    Execute bisect process:
    - Start: {last-known-good-commit}
    - End: {current-broken-commit}
    - Test: {reproduction steps or test case}

    Document bisect process and result:

    **Bisect Results**:
    - **Introducing Commit**: {SHA}
    - **Author**: {name}
    - **Timestamp**: {YYYY-MM-DD HH:MM:SS}
    - **PR/MR**: {PR-number} - {PR-title}
    - **Commit Message**: {message}
    - **Files Changed**: {count} files
    - **Risk Assessment**: {LOW | MEDIUM | HIGH based on scope}

    **Commit Details**:
    ```
    {git show {SHA} --stat output}
    ```

    **Related Changes**:
    - [ ] Code changes in affected component
    - [ ] Configuration changes
    - [ ] Database migrations
    - [ ] Dependency updates
    - [ ] Infrastructure changes

    Append to: .aiwg/incidents/{incident-id}/regression-analysis.md (Step 4)

    Append timeline:
    | {HH:MM UTC} | Introducing commit identified | regression-analyst | Commit: {SHA}, PR: {PR-number} |
    """
)

Rollback Feasibility Assessment:

Task(
    subagent_type="reliability-engineer",
    description="Assess rollback feasibility and calculate blast radius",
    prompt="""
    Read regression analysis: .aiwg/incidents/{incident-id}/regression-analysis.md

    Since introducing change identified, assess rollback options:

    ## Step 5: Rollback Feasibility

    **Rollback Options**:

    ### Option A: Full Rollback to Previous Version
    - **Target Version**: {version before introducing commit}
    - **Feasibility**: {SAFE | RISKY | BLOCKED}
    - **Risk Factors**:
      - [ ] Database migrations in between (incompatible schema)
      - [ ] External API contract changes (breaking)
      - [ ] Data written in new format (can't be read by old version)
      - [ ] Dependent services already updated (coordination required)
    - **Rollback Time**: {estimated minutes}
    - **Data Loss Risk**: {NONE | MINIMAL | SIGNIFICANT}

    ### Option B: Revert Specific Commit(s)
    - **Commits to Revert**: {SHA1, SHA2, ...}
    - **Feasibility**: {SAFE | RISKY | BLOCKED}
    - **Conflicts**: {count} potential merge conflicts
    - **Testing Required**: {minimal | moderate | extensive}
    - **Revert + Deploy Time**: {estimated minutes}

    ### Option C: Feature Flag Disable
    - **Applicable**: {YES | NO}
    - **Feature Flags Involved**: {flag-names}
    - **Disable Time**: {estimated minutes} (near-instant)
    - **Partial Rollback**: {which features disabled}

    ### Option D: Hotfix Forward
    - **Feasibility**: {VIABLE | NOT_VIABLE}
    - **Fix Complexity**: {SIMPLE | MODERATE | COMPLEX}
    - **Estimated Fix Time**: {minutes}
    - **Testing Time**: {minutes}
    - **Total Time**: {minutes}

    **Recommended Option**: {A | B | C | D}
    **Rationale**: {why this option is best given constraints}

    ## Step 6: Blast Radius Calculation

    **Scope of Introducing Change**:
    - **Components Affected**: {list all components touched by change}
    - **Services Impacted**: {list all services}
    - **Dependencies**: {downstream systems affected}
    - **Users Impacted**: {estimated count or percentage}
    - **Geographic Scope**: {all regions | specific regions}
    - **User Segments**: {all users | specific segments}

    **Rollback Impact Assessment**:
    - **Services Affected by Rollback**: {list}
    - **Data Loss Risk**: {NONE | MINIMAL | ACCEPTABLE | UNACCEPTABLE}
    - **Downtime Required**: {NONE | <5 min | 5-15 min | >15 min}
    - **Coordination Required**: {list teams/services needing notification}

    **Blast Radius Score**: {LOW | MEDIUM | HIGH}

    Append to: .aiwg/incidents/{incident-id}/regression-analysis.md (Steps 5-6)

    Append timeline:
    | {HH:MM UTC} | Rollback feasibility assessed | reliability-engineer | Recommended: {option}, Blast radius: {score} |
    """
)

Immediate Action Recommendation:

Task(
    subagent_type="regression-analyst",
    description="Recommend immediate action based on regression analysis",
    prompt="""
    Read complete regression analysis: .aiwg/incidents/{incident-id}/regression-analysis.md

    ## Step 7: Immediate Action Decision Matrix

    Use decision matrix to recommend action:

    | Regression Confidence | Rollback Risk | User Impact | Recommendation |
    |-----------------------|---------------|-------------|----------------|
    | CONFIRMED + HIGH      | LOW           | HIGH        | **ROLLBACK IMMEDIATELY** |
    | CONFIRMED + HIGH      | LOW           | MEDIUM      | **ROLLBACK** |
    | CONFIRMED + HIGH      | MEDIUM        | HIGH        | **ROLLBACK with validation** |
    | CONFIRMED + HIGH      | HIGH          | HIGH        | **HOTFIX (rollback blocked)** |
    | LIKELY + MEDIUM       | LOW           | HIGH        | **ROLLBACK after quick validation** |
    | LIKELY + MEDIUM       | MEDIUM        | HIGH        | **INVESTIGATE + prepare rollback** |
    | POSSIBLE + LOW        | ANY           | HIGH        | **INVESTIGATE (parallel to Tier 1)** |
    | UNLIKELY              | ANY           | ANY         | **STANDARD TRIAGE (continue to Step 2)** |

    **Current Situation**:
    - Regression Confidence: {from Step 3}
    - Rollback Risk: {from Step 5}
    - User Impact: {from incident record}

    **Recommended Immediate Action**: {action from matrix}

    **Action Details**:
    - **Action Type**: {ROLLBACK | HOTFIX | INVESTIGATE | STANDARD_TRIAGE}
    - **Urgency**: {IMMEDIATE (<5 min) | URGENT (<15 min) | NORMAL (standard SLA)}
    - **Prerequisites**: {any validation or approval needed}
    - **Execution Steps**: {high-level steps}
    - **Fallback Plan**: {if this action fails}

    **Communication**:
    - Notify Incident Commander: {key finding summary}
    - Notify Deployment Manager: {rollback decision if applicable}
    - Update status: "Regression {CONFIRMED|LIKELY|POSSIBLE}, {action} in progress"

    Append to: .aiwg/incidents/{incident-id}/regression-analysis.md (Step 7)

    Append timeline:
    | {HH:MM UTC} | Immediate action recommended | regression-analyst | Action: {ROLLBACK|HOTFIX|INVESTIGATE|STANDARD_TRIAGE} |
    """
)

Update Regression Register:

Task(
    subagent_type="regression-analyst",
    description="Record regression in regression register",
    prompt="""
    If regression is CONFIRMED or LIKELY, update regression register:

    Read regression analysis: .aiwg/incidents/{incident-id}/regression-analysis.md

    Update regression register with incident:

    **Regression Entry**:
    ```yaml
    regression_id: REG-{YYYY-MM-DD}-{sequence}
    incident_id: {incident-id}
    detection_date: {YYYY-MM-DD}
    severity: {P0|P1|P2|P3}

    introducing_change:
      commit_sha: {SHA}
      pr_number: {PR-number}
      author: {name}
      merge_date: {YYYY-MM-DD}
      deployment_date: {YYYY-MM-DD}

    regression_category: {functional | performance | security | data-integrity}

    affected_functionality:
      component: {component-name}
      feature: {feature-name}
      user_facing: {YES|NO}

    detection_gap:
      escaped_testing: {unit | integration | e2e | manual | staging}
      detection_time: {hours from deployment to detection}
      reason: {why tests didn't catch this}

    mitigation_action: {rollback | hotfix | feature-flag-disable}
    mitigation_time: {minutes from detection to resolution}

    preventive_actions:
      - {action 1 to prevent recurrence}
      - {action 2 to improve detection}

    status: {OPEN | MITIGATED | ANALYZED | CLOSED}
    ```

    Save to: .aiwg/regression/register/{regression-id}.yaml

    Also update regression summary:
    Append one-line entry to: .aiwg/regression/regression-register-summary.md

    | {regression-id} | {incident-id} | {YYYY-MM-DD} | {P0|P1|P2} | {commit-SHA} | {category} | {status} |

    Cross-reference in incident:
    Append to: .aiwg/incidents/{incident-id}/regression-analysis.md

    ## Regression Register Entry

    This incident has been registered as: **{regression-id}**

    See: @.aiwg/regression/register/{regression-id}.yaml

    Append timeline:
    | {HH:MM UTC} | Regression registered | regression-analyst | Registered as: {regression-id} |
    """
)

Decision Flow:

Regression Triage Decision Tree:

1. Is this a regression?
   ├─ CONFIRMED/LIKELY → Proceed to rollback assessment
   │   ├─ Rollback SAFE + HIGH user impact → Execute rollback immediately
   │   ├─ Rollback RISKY or BLOCKED → Proceed to hotfix path
   │   └─ Rollback SAFE + LOW user impact → Prepare rollback, investigate in parallel
   │
   ├─ POSSIBLE → Continue standard triage in parallel with regression investigation
   │
   └─ UNLIKELY/NOT_REGRESSION → Continue to standard triage (Step 2)

Communicate Progress:

✓ Incident logged
⏳ Regression triage in progress...
  ✓ Recent deployments identified: {count} in last {hours}h
  ✓ Regression verdict: {CONFIRMED|LIKELY|POSSIBLE|UNLIKELY|NOT_REGRESSION}
  {✓ Introducing commit identified: {SHA}, PR: {PR-number}}
  {✓ Rollback feasibility: {SAFE|RISKY|BLOCKED}}
  ✓ Recommended action: {ROLLBACK|HOTFIX|INVESTIGATE|STANDARD_TRIAGE}
  {✓ Regression registered: {regression-id}}
⏳ {Executing immediate rollback | Proceeding to hotfix development | Continuing to standard triage}...

Step 2: Triage and Severity Assessment

Purpose: Rapidly assess severity and assign priority using Impact × Urgency matrix

Your Actions:

Launch Triage Agents (parallel):

# Agent 1: Impact Assessment
Task(
    subagent_type="incident-responder",
    description="Assess incident impact (user effect)",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Assess Impact Level:

    **User Impact Assessment**:
    - Affected Users: {count or percentage}
    - Severity of Effect: {complete outage | severe degradation | minor issue}
    - Impact Level: {HIGH | MEDIUM | LOW}

    Criteria:
    - HIGH: Complete service outage OR >50% users affected OR data loss/corruption
    - MEDIUM: Severe degradation OR 10-50% users affected OR critical feature unavailable
    - LOW: Minor degradation OR <10% users affected OR cosmetic issue

    **Business Impact**:
    - Revenue Impact: {$amount | NONE}
    - Compliance Risk: {YES | NO}
    - Reputation Risk: {HIGH | MEDIUM | LOW}
    - User Safety Risk: {YES | NO}

    **Affected Systems**: {list all affected components, services, integrations}

    Save to: .aiwg/incidents/{incident-id}/triage-assessment.md (Impact section)
    """
)

# Agent 2: Urgency Assessment
Task(
    subagent_type="reliability-engineer",
    description="Assess incident urgency (time sensitivity)",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Assess Urgency Level:

    **Urgency Assessment**:
    - Time Sensitivity: {immediate | hours | days}
    - Worsening Trend: {rapidly degrading | stable | improving}
    - Urgency Level: {HIGH | MEDIUM | LOW}

    Criteria:
    - HIGH: Immediate resolution required, worsening rapidly, SLA breach imminent
    - MEDIUM: Resolution needed within hours, stable degradation
    - LOW: Resolution can be scheduled, no time pressure

    **SLA Breach Risk**:
    - Current Availability: {percentage}%
    - SLA Target: {percentage}%
    - Error Budget Remaining: {percentage}%
    - Time to SLA Breach: {estimated time}

    Append to: .aiwg/incidents/{incident-id}/triage-assessment.md (Urgency section)
    """
)

Synthesize Priority Classification:

Task(
    subagent_type="incident-responder",
    description="Determine incident priority from Impact × Urgency",
    prompt="""
    Read triage assessment: .aiwg/incidents/{incident-id}/triage-assessment.md

    Determine Priority using matrix:

    | Impact/Urgency | High Urgency | Medium Urgency | Low Urgency |
    |----------------|--------------|----------------|-------------|
    | High Impact    | P0 (Critical) | P1 (High)     | P2 (Medium) |
    | Medium Impact  | P1 (High)    | P2 (Medium)    | P3 (Low)    |
    | Low Impact     | P2 (Medium)  | P3 (Low)       | P3 (Low)    |

    **Priority**: {P0 | P1 | P2 | P3}

    **Response SLA**:
    - P0: Acknowledgment immediate, Engage 15 min, Resolve 1-2h, Updates every 15 min
    - P1: Acknowledgment 5 min, Engage 30 min, Resolve 4h, Updates every 30 min
    - P2: Acknowledgment 30 min, Engage 4h, Resolve 24h, Updates daily
    - P3: Acknowledgment 1 business day, Standard backlog process

    **Escalation Path**:
    - P0: Page on-call → Incident Commander → Deployment Manager → Executive (30 min)
    - P1: Alert on-call → Incident Commander → Component Owner → Management (2h)
    - P2: Create ticket → On-call triage → Component Owner if needed
    - P3: Standard backlog

    **Incident Commander Assignment** (P0/P1 only):
    - Assign Incident Commander: {name or role}
    - Assign Technical Lead: {on-call engineer or component owner}
    - Assign Communications Lead: {support lead or PM}

    Update incident record with priority and assignments
    Save to: .aiwg/incidents/{incident-id}/incident-record.md

    Append timeline:
    | {HH:MM UTC} | Triage complete, severity {P0/P1/P2/P3} assigned | incident-responder | Impact: {HIGH/MED/LOW}, Urgency: {HIGH/MED/LOW} |
    | {HH:MM UTC} | Incident Commander assigned | {name} | {P0/P1 only} |

    Append to: .aiwg/incidents/{incident-id}/timeline.md
    """
)

Communicate Progress:

✓ Incident detected
⏳ Assessing impact and urgency...
  ✓ Impact: {HIGH/MEDIUM/LOW}
  ✓ Urgency: {HIGH/MEDIUM/LOW}
✓ Priority assigned: {P0/P1/P2/P3}
✓ Incident Commander assigned: {name} (P0/P1)
⏳ Initiating functional escalation (Tier 1)...

Step 3: Functional Escalation (Tier 1 → Tier 2 → Tier 3)

Purpose: Engage appropriate expertise based on incident complexity

Your Actions:

Tier 1 Response (First 15-30 minutes):

Task(
    subagent_type="reliability-engineer",
    description="Tier 1 response: Runbook execution and data gathering",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Execute Tier 1 Response:

    ## Initial Actions (First 5 minutes)
    - [ ] Acknowledge incident
    - [ ] Confirm user impact (reproduce if possible)
    - [ ] Check recent deployments/changes (last 24h)
    - [ ] Review monitoring dashboards for anomalies
    - [ ] Identify applicable runbook: deployment/runbook-{scenario}.md

    ## Data Gathering
    Collect diagnostic data:
    - System health (pods, nodes, services status)
    - Recent deployments (git log, rollout history)
    - Logs (last 500 lines from affected services)
    - Metrics (error rate, latency, throughput)
    - Database health (active connections, slow queries)

    Document actions taken and results.

    ## Escalation Decision (Tier 1 → Tier 2)
    Escalate if:
    - Runbook not available OR issue unresolved after {15 min P0 | 30 min P1}
    - Requires deep component knowledge or code changes
    - Database, network, or infrastructure issue suspected

    If escalation needed, document:
    - Why escalating (specific reason)
    - Data collected (attach logs, metrics)
    - Hypotheses tested (what was tried)

    Save diagnostic data to: .aiwg/incidents/{incident-id}/diagnostics/tier1-data.md

    Append timeline with all actions taken.
    """
)

Tier 2 Response (If escalated):

Task(
    subagent_type="component-owner",
    description="Tier 2 response: Advanced troubleshooting and code review",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md
    Read Tier 1 data: .aiwg/incidents/{incident-id}/diagnostics/tier1-data.md

    Execute Tier 2 Response:

    ## Handoff from Tier 1
    - Review incident summary and diagnostic data
    - Review actions already taken by Tier 1
    - Review relevant runbooks and recent changes

    ## Advanced Troubleshooting
    - Deep log analysis (error patterns, stack traces)
    - Code review for recent changes (git diff last 48h)
    - Reproduce issue in non-prod environment (if possible)
    - Check component dependencies (upstream/downstream services)
    - Analyze performance profiles (CPU, memory, query execution plans)

    ## Root Cause Hypothesis
    Formulate hypothesis:

    **Hypothesis**: {statement of suspected root cause}

    **Evidence**:
    1. {log pattern or metric anomaly}
    2. {recent deployment or config change}
    3. {external dependency status}

    **Test Plan**:
    - [ ] {validation step 1}
    - [ ] {validation step 2}

    ## Escalation Decision (Tier 2 → Tier 3)
    Escalate if:
    - Architectural issue or design flaw suspected
    - Vendor/third-party dependency issue
    - Unresolved after {30 min P0 | 1 hour P1}
    - Emergency code fix required (hotfix approval needed)

    Save hypothesis and findings to: .aiwg/incidents/{incident-id}/diagnostics/tier2-analysis.md

    Append timeline with advanced troubleshooting results.
    """
)

Tier 3 Response (If escalated):

Task(
    subagent_type="architecture-designer",
    description="Tier 3 response: Architectural analysis and emergency decisions",
    prompt="""
    Read all prior diagnostics:
    - .aiwg/incidents/{incident-id}/diagnostics/tier1-data.md
    - .aiwg/incidents/{incident-id}/diagnostics/tier2-analysis.md

    Execute Tier 3 Response:

    ## Architectural Analysis
    - Review system design for fundamental issues
    - Evaluate scalability/capacity constraints
    - Consider architectural trade-offs (CAP theorem, consistency models)
    - Engage vendor support if third-party dependency issue

    ## Emergency Decision Authority
    Provide decisions on:
    - Emergency architecture changes (approve/reject)
    - Vendor escalation (initiate if needed)
    - Hotfix deployment outside normal process (approve with conditions)
    - Temporary workaround vs. full fix (recommend approach)

    Document architectural assessment and decisions:
    Save to: .aiwg/incidents/{incident-id}/diagnostics/tier3-architecture-assessment.md

    Append timeline with architectural decisions.
    """
)

Communicate Progress:

✓ Priority assigned: {P0/P1/P2/P3}
⏳ Tier 1 response initiated...
  ✓ Runbook executed: {runbook-name}
  ✓ Diagnostic data collected
  ⚠️ Escalating to Tier 2 (reason: {escalation-reason})
⏳ Tier 2 response: Component Owner engaged...
  ✓ Root cause hypothesis: {hypothesis}
  {✓ Hypothesis confirmed | ⚠️ Escalating to Tier 3}

Step 4: Hierarchical Escalation (Management / Executive)

Purpose: Notify leadership when business impact warrants executive involvement

Your Actions:

Management Notification (P0/P1):

Task(
    subagent_type="project-manager",
    description="Notify management per escalation matrix",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Determine if management notification required:

    **Trigger**:
    - P0: Within 30 minutes of detection (automatic)
    - P1: Within 2 hours if unresolved
    - P2: If user impact escalates or SLA breach imminent

    Generate management notification:

    Subject: [{P0 | P1} INCIDENT] {brief-title} - {status}

    **Incident ID**: {incident-id}
    **Severity**: {P0/P1}
    **Start Time**: {HH:MM UTC}
    **Duration**: {elapsed-time}

    **User Impact**: {high-level description}
    **Affected Users**: {count | percentage}
    **Business Impact**: {revenue loss | compliance risk | reputation impact}

    **Current Status**: {INVESTIGATING | MITIGATING | RESOLVED}
    **Root Cause**: {hypothesis or confirmed}
    **ETA to Resolution**: {estimated time | UNKNOWN}

    **Incident Commander**: {name}
    **Next Update**: {time}

    Save to: .aiwg/incidents/{incident-id}/communications/management-notification.md

    Append timeline: Management notified
    """
)

Executive Escalation (P0 Critical):

Task(
    subagent_type="project-manager",
    description="Notify executive leadership for P0 or major business impact",
    prompt="""
    Read incident record: .aiwg/incidents/{incident-id}/incident-record.md

    Determine if executive notification required:

    **Trigger**:
    - P0: If unresolved after 2 hours OR major business impact
    - Security breach or data loss (immediate)
    - Public/media attention likely
    - Regulatory reporting required

    Generate executive notification:

    Subject: [EXECUTIVE ALERT] P0 Incident - {brief-title}

    **Business Impact Summary**:
    - Revenue Impact: {$amount estimated}
    - User Impact: {count} users / {percentage}% of user base
    - Compliance Risk: {YES/NO - describe}
    - Reputation Risk: {HIGH/MEDIUM/LOW}

    **Incident Summary**:
    {2-3 sentence summary of issue and response}

    **Current Status**: {status}
    **ETA to Resolution**: {time}
    **Incident Commander**: {name}

    **Executive Action Needed**:
    {NONE | DECISION REQUIRED | AWARENESS ONLY}

    **Next Update**: {time}

    Save to: .aiwg/incidents/{incident-id}/communications/executive-notification.md

    Append timeline: Executive leadership notified
    """
)

Status Page Communication (P0/P1):

Task(
    subagent_type="incident-responder",
    description="Generate status page update template",
    prompt="""
    Create public-facing status page update:

    {YYYY-MM-DD HH:MM UTC} - Investigating
    We are currently investigating an issue affecting {service/feature}.
    Users may experience {specific symptoms}. We will provide updates every {15|30|60} minutes.

    Save template to: .aiwg/incidents/{incident-id}/communications/status-page-update.md

    Note: Update within 30 minutes for P0, 1 hour for P1
    """
)

Communicate Progress:

✓ Tier 2 analysis complete
⏳ Escalating per severity matrix...
  ✓ Management notified (P0/P1)
  {✓ Executive notified (P0 >2h or critical business impact) | ⊘ Executive notification not required}
  ✓ Status page update template created
⏳ Proceeding to root cause analysis and mitigation...

Step 5: Root Cause Analysis

Purpose: Identify root cause using structured methodologies (5 Whys, Fishbone)

Your Actions:

Launch RCA Agents (parallel):

# Agent 1: 5 Whys Analysis
Task(
    subagent_type="incident-responder",
    description="Conduct 5 Whys root cause analysis",
    prompt="""
    Read diagnostics:
    - .aiwg/incidents/{incident-id}/diagnostics/tier1-data.md
    - .aiwg/incidents/{incident-id}/diagnostics/tier2-analysis.md
    - .aiwg/incidents/{incident-id}/diagnostics/tier3-architecture-assessment.md (if exists)

    Conduct 5 Whys Analysis:

    **Problem Statement**: {what happened}

    1. **Why did {problem} occur?**
       - Because {reason-1}

    2. **Why did {reason-1} occur?**
       - Because {reason-2}

    3. **Why did {reason-2} occur?**
       - Because {reason-3}

    4. **Why did {reason-3} occur?**
       - Because {reason-4}

    5. **Why did {reason-4} occur?**
       - Because {root-cause}

    **Root Cause**: {final answer from 5th why}

    **Validation**: {test to confirm root cause}

    Save to: .aiwg/incidents/{incident-id}/root-cause-analysis.md (5 Whys section)
    """
)

# Agent 2: Contributing Factors (Fishbone)
Task(
    subagent_type="reliability-engineer",
    description="Identify contributing factors using Ishikawa diagram",
    prompt="""
    Read diagnostics and 5 Whys analysis

    Analyze Contributing Factors:

    **Problem**: {incident title}

    ### People
    - {factor 1: e.g., insufficient training}
    - {factor 2: e.g., on-call fatigue}

    ### Process
    - {factor 1: e.g., inadequate testing}
    - {factor 2: e.g., unclear runbook}

    ### Technology
    - {factor 1: e.g., database connection pool exhaustion}
    - {factor 2: e.g., monitoring gap}

    ### Environment
    - {factor 1: e.g., traffic spike}
    - {factor 2: e.g., resource constraints}

    **Primary Root Cause**: {from 5 Whys}
    **Contributing Factors**: {list key factors from above}

    Append to: .aiwg/incidents/{incident-id}/root-cause-analysis.md (Contributing Factors section)
    """
)

Communicate Progress:

✓ Hierarchical escalation complete
⏳ Conducting root cause analysis...
  ✓ 5 Whys analysis: Root cause identified as {root-cause}
  ✓ Contributing factors analysis: {count} factors identified
✓ Root cause analysis complete: .aiwg/incidents/{incident-id}/root-cause-analysis.md
⏳ Implementing mitigation strategy...

Step 6: Mitigation and Resolution

Purpose: Implement workaround or fix to restore service and eliminate user impact

Your Actions:

Select Mitigation Strategy:

Task(
    subagent_type="incident-responder",
    description="Select mitigation strategy based on root cause",
    prompt="""
    Read root cause analysis: .aiwg/incidents/{incident-id}/root-cause-analysis.md

    Evaluate Mitigation Options:

    **Option 1: Rollback** (fastest, safest for deployment-related incidents)
    - Use Case: Recent deployment caused issue, old version was stable
    - Time to Mitigate: 5-15 minutes
    - Risk: Low (return to known-good state)

    **Option 2: Hotfix** (targeted code fix)
    - Use Case: Bug fix required, rollback not viable
    - Time to Mitigate: 30 minutes - 2 hours
    - Risk: Medium (new code, limited testing)

    **Option 3: Configuration Change** (parameter adjustment)
    - Use Case: Resource limits, timeouts, feature flags
    - Time to Mitigate: 10-30 minutes
    - Risk: Low-Medium (no code change)

    **Option 4: Workaround** (temporary user-side solution)
    - Use Case: Fix requires significant time, need immediate relief
    - Time to Mitigate: Immediate (communication)
    - Risk: Low (no system change)

    **Option 5: Infrastructure Scaling** (resource addition)
    - Use Case: Capacity issue, traffic spike
    - Time to Mitigate: 10-20 minutes
    - Risk: Low-Medium (cost implications)

    **Selected Strategy**: {option}
    **Rationale**: {why this option was chosen}
    **Implementation Plan**: {specific steps}
    **Rollback Plan**: {if mitigation fails, how to revert}

    Save to: .aiwg/incidents/{incident-id}/mitigation-report.md (Strategy section)
    """
)

Execute Mitigation (agent depends on strategy):

# If Rollback
Task(
    subagent_type="devops-engineer",
    description="Execute rollback procedure",
    prompt="""
    Execute rollback based on deployment strategy:

    Use existing deployment command:
    /flow-deploy-to-production --rollback

    Document rollback execution:
    - Rollback timestamp
    - Previous version: {old-version}
    - Rolled back to: {stable-version}
    - Verification: smoke tests, metrics

    Append to: .aiwg/incidents/{incident-id}/mitigation-report.md (Execution section)
    Append timeline: Rollback executed
    """
)

# If Hotfix
Task(
    subagent_type="devops-engineer",
    description="Deploy emergency hotfix",
    prompt="""
    Execute hotfix deployment:

    1. Create hotfix branch: hotfix/INC-{incident-ID}-{brief-description}
    2. Implement minimal fix (code change already identified)
    3. Test in staging (smoke tests, regression tests)
    4. Deploy to production using standard flow
    5. Monitor for 15 minutes (metrics validation)

    Get Deployment Manager approval before production deploy.

    Document hotfix deployment:
    - Hotfix commit SHA
    - Deployment timestamp
    - Validation results

    Append to: .aiwg/incidents/{incident-id}/mitigation-report.md (Execution section)
    Append timeline: Hotfix deploye

…(truncated)

Flow Incident Response

File contents

Incident Response Flow

Your Role

Incident Response Overview

Natural Language Triggers

Parameter Handling

--guidance Parameter

--interactive Parameter

Artifacts to Generate

Multi-Agent Orchestration Workflow

Step 1: Incident Detection and Initial Logging

Step 1.5: Regression Triage

Step 2: Triage and Severity Assessment

Step 3: Functional Escalation (Tier 1 → Tier 2 → Tier 3)

Step 4: Hierarchical Escalation (Management / Executive)

Step 5: Root Cause Analysis

Step 6: Mitigation and Resolution

Frequently asked questions

Flow Incident Response

File contents

Incident Response Flow

Your Role

Incident Response Overview

Natural Language Triggers

Parameter Handling

--guidance Parameter

--interactive Parameter

Artifacts to Generate

Multi-Agent Orchestration Workflow

Step 1: Incident Detection and Initial Logging

Step 1.5: Regression Triage

Step 2: Triage and Severity Assessment

Step 3: Functional Escalation (Tier 1 → Tier 2 → Tier 3)

Step 4: Hierarchical Escalation (Management / Executive)

Step 5: Root Cause Analysis

Step 6: Mitigation and Resolution

Related skills

Frequently asked questions

How do I install the Flow Incident Response skill?

What does the Flow Incident Response skill do?

Is Flow Incident Response safe to use?

Which AI agents work with Flow Incident Response?

Is Flow Incident Response free to use?

Who published Flow Incident Response?