/incident-response

description: "Orchestrate multi-agent incident response with modern SRE practices for rapid resolution and learning"
argument-hint: "<incident description> [--severity P0|P1|P2|P3]"

Incident Response Orchestrator

CRITICAL BEHAVIORAL RULES

You MUST follow these rules exactly. Violating any of them is a failure.

1. **Execute steps in order.** Do NOT skip ahead, reorder, or merge steps. 2. **Write output files.** Each step MUST produce its output file in `.incident-response/` before the next step begins. Read from prior step files — do NOT rely on context window memory. 3. **Stop at checkpoints.** When you reach a `PHASE CHECKPOINT`, you MUST stop and wait for explicit user approval before continuing. Use the AskUserQuestion tool with clear options. 4. **Halt on failure.** If any step fails (agent error, test failure, missing dependency), STOP immediately. Present the error and ask the user how to proceed. Do NOT silently continue. 5. **Use only local agents.** All `subagent_type` references use agents bundled with this plugin or `general-purpose`. No cross-plugin dependencies. 6. **Never enter plan mode autonomously.** Do NOT use EnterPlanMode. This command IS the plan — execute it.

Pre-flight Checks

Before starting, perform these checks:

1. Check for existing session

Check if `.incident-response/state.json` exists:

• If it exists and `status` is `"in_progress"`: Read it, display the current step, and ask the user:

  Found an in-progress incident response session:
  Incident: [incident from state]
  Severity: [severity from state]
  Current step: [step from state]

  1. Resume from where we left off
  2. Start fresh (archives existing session)

• If it exists and `status` is `"complete"`: Ask whether to archive and start fresh.

2. Initialize state

Create `.incident-response/` directory and `state.json`:

{
  "incident": "$ARGUMENTS",
  "status": "in_progress",
  "severity": "P1",
  "current_step": 1,
  "current_phase": 1,
  "completed_steps": [],
  "files_created": [],
  "started_at": "ISO_TIMESTAMP",
  "last_updated": "ISO_TIMESTAMP"
}

Parse `$ARGUMENTS` for `--severity` flag. Default to P1 if not specified.

3. Parse incident description

Extract the incident description from `$ARGUMENTS` (everything before the flags). This is referenced as `$INCIDENT` in prompts below.

---

Phase 1: Detection & Triage (Steps 1-3)

Step 1: Incident Detection and Classification

Use the Task tool to launch the incident responder agent:

Task:
  subagent_type: "incident-responder"
  description: "URGENT: Classify incident: $INCIDENT"
  prompt: |
    URGENT: Detect and classify incident: $INCIDENT

    Determine:
    1. Incident severity (P0-P3) based on impact assessment
    2. Affected services and their dependencies
    3. User impact and business risk
    4. Initial incident command structure needed
    5. SLO violation status and error budget impact

    Check: error budgets, recent deployments, configuration changes, and monitoring alerts.

    Provide structured output with: SEVERITY, AFFECTED_SERVICES, USER_IMPACT,
    BUSINESS_RISK, INCIDENT_COMMAND, SLO_STATUS.

Save output to `.incident-response/01-classification.md`.

Update `state.json`: set `current_step` to 2, update severity from classification, add step 1 to `completed_steps`.

Step 2: Observability Analysis

Read `.incident-response/01-classification.md`.

Task:
  subagent_type: "general-purpose"
  description: "Observability sweep for incident: $INCIDENT"
  prompt: |
    You are an observability engineer. Perform rapid observability sweep for this incident.

    Context: [Insert contents of .incident-response/01-classification.md]

    Query and analyze:
    1. Distributed tracing (OpenTelemetry/Jaeger) for request flow
    2. Metrics correlation (Prometheus/Grafana/DataDog) for anomalies
    3. Log aggregation (ELK/Splunk) for error patterns
    4. APM data for performance degradation points
    5. Real User Monitoring for user experience impact

    Identify anomalies, error patterns, and service degradation points.

    Provide structured output with: TRACE_ANALYSIS, METRICS_ANOMALIES, LOG_PATTERNS,
    APM_FINDINGS, RUM_IMPACT, SERVICE_HEALTH_MATRIX.

Save output to `.incident-response/02-observability.md`.

Update `state.json`: set `current_step` to 3, add step 2 to `completed_steps`.

Step 3: Initial Mitigation

Read `.incident-response/01-classification.md` and `.incident-response/02-observability.md`.

Task:
  subagent_type: "incident-responder"
  description: "Immediate mitigation for: $INCIDENT"
  prompt: |
    Implement immediate mitigation for this incident.

    Classification: [Insert contents of .incident-response/01-classification.md]
    Observability: [Insert contents of .incident-response/02-observability.md]

    Actions to evaluate and implement:
    1. Traffic throttling/rerouting if needed
    2. Feature flag disabling for affected features
    3. Circuit breaker activation
    4. Rollback assessment for recent deployments
    5. Scale resources if capacity-related

    Prioritize user experience restoration.

    Provide structured output with: MITIGATION_ACTIONS, TEMPORARY_FIXES,
    ROLLBACK_DECISIONS, SERVICE_STATUS_AFTER, USER_IMPACT_REDUCTION.

Save output to `.incident-response/03-mitigation.md`.

Update `state.json`: set `current_step` to "checkpoint-1", add step 3 to `completed_steps`.

---

PHASE CHECKPOINT 1 — User Approval Required

You MUST stop here and present the triage results.

Display a summary from `.incident-response/01-classification.md` and `.incident-response/03-mitigation.md` and ask:

Triage and initial mitigation complete.

Severity: [from classification]
Affected services: [from classification]
Mitigation status: [from mitigation]
User impact reduction: [from mitigation]

1. Approve — proceed to investigation and root cause analysis
2. Request changes — adjust mitigation or seve