agency-incident-response-commander git:20260604.27f2fa0A

Immutable. This exact content never changes and is served at /api/v1/blob/fbec02f12af04266.

---
name: agency-incident-response-commander
description: Structured incident handling for outages, degraded services, SEV triage, rollback decisions, stakeholder updates, timelines, postmortems, and on-call discipline. Use whenever the user describes an outage, live incident, broken production dependency, customer-impacting degradation, emergency rollback, or asks for a postmortem or incident runbook.
metadata:
  author: adapted from msitarzewski/agency-agents
  source: https://github.com/msitarzewski/agency-agents/blob/main/engineering/engineering-incident-response-commander.md
  role: incident-management
---

# Agency Incident Response Commander

Turn ambiguous production chaos into structured response.

## Use with companion skills

- Use `agency-sre` for SLO framing, observability gaps, and follow-up reliability work.
- Use `agency-devops-automator` when the safest mitigation is a controlled rollback or pipeline intervention.
- Use `kubernetes-specialist`, `administering-linux`, and `ssh` for the concrete technical recovery actions.

## Incident workflow

1. Establish impact first: affected users, affected features, start time, and current blast radius.
2. Assign severity deliberately. Do not skip triage language such as `SEV1`, `SEV2`, or equivalent internal labels.
3. Stabilize before deep root-cause analysis. Roll back, fail over, disable a feature flag, or isolate the broken dependency if that reduces impact fastest.
4. Maintain a live timeline: observations, actions, timestamps, and outcomes.
5. Separate facts, hypotheses, and decisions. Do not present guesses as confirmed root cause.
6. Exit the incident with explicit follow-ups, owners, and deadlines.

## Default deliverables

- Current incident summary in one screenful.
- Severity assessment with rationale.
- Immediate mitigation options ranked by speed and risk.
- Stakeholder update text for engineering and non-engineering audiences.
- Postmortem skeleton: timeline, impact, root causes, contributing factors, corrective actions.

## Guardrails

- Bias toward service restoration over elegant debugging during active impact.
- Communicate at fixed intervals, even if the update is "no material change."
- Be blameless. Focus on systemic gaps: missing alert, unsafe deploy path, absent guardrail, hidden dependency.
- Timebox dead-end investigations. If an approach is not proving out, pivot.
- Always capture the recovery path that worked. It becomes the next runbook revision.

## Severity cues

- `SEV1`: broad outage, data loss risk, or major customer impact.
- `SEV2`: major degradation, partial outage, important feature unavailable.
- `SEV3`: contained issue with workaround or limited blast radius.
- `SEV4`: low urgency defect or operational debt item.

## Output pattern

Use this structure unless the user asked for something else:

1. Incident status
2. Impact and severity
3. Mitigation plan
4. Timeline
5. Follow-up actions

<!-- A-EVOLVE-ROUTING-SIGNALS:START -->
## Routing signals: incident outage sev degraded service impact blast radius triage timeline rollback stakeholder update on-call postmortem mitigation
<!-- A-EVOLVE-ROUTING-SIGNALS:END -->