| name | incident-response |
| description | Use to coordinate a live production incident or outage — triage severity, decide which guards to dispatch in what order, keep one timeline. Produces the dispatch plan only; the caller invokes each guard. |
| allowed-tools | Read, Grep, Glob |
| when_to_use | Use automatically on live-incident language — "prod is down," "P1," "outage," "5xx spike" — not for routine bug reports with no urgency signal. |
| effort | high |
| argument-hint | [what's down / what the user reported] |
incident-response
Coordinate, don't firefight solo. This is a triage/dispatch skill (no Agent tool) — it routes to the same guard agents agents/ROUTING.md already defines, in parallel where safe, and keeps one timeline; the calling agent/orchestrator invokes each guard.
- TRIAGE first: what's broken (endpoint/service), since when, blast radius (all users / one tenant / one flow), and is it getting worse. State this in one line before anything else.
- Stop the bleeding beats root-cause: if a recent deploy/migration/config change correlates with the start time, ask about rollback before deep debugging — rollback is faster and safer than a live fix under pressure. A migration/deploy rollback is itself a guarded action (routes through db-guard/devops-guard, same as any other schema or CI/CD change) — urgency shortens the approval wait, it doesn't skip the guard.
- State the dispatch plan by signal, same as ROUTING.md Step 3: auth/session broken → security-guard; DB/query errors → db-guard; deploy/infra/CI signal → devops-guard; slow/timeout without errors → performance-guard; anything else with a stack trace → bug-hunter. Mark which of these are independent so the calling agent can invoke them in parallel rather than sequentially.
- Guard agents stay read-only planners even during an incident — urgency compresses the time between plan and approval, it doesn't skip the plan-then-approve step for a guarded area.
- Keep one running timeline (detected → triaged → root cause found → fix applied → verified) — this becomes the postmortem input; don't let it live only in scrollback.
- After mitigation: write the postmortem from the timeline (
docs-update skill), and flag any missing metric/alert that would have caught this sooner as OBS: (per rules/700-observability.md).
