Incident Response
Stabilize first, learn second. Do not let diagnosis delay a safe reversible
mitigation.
Establish control
Record start time, incident commander, responders, severity, affected users and
regions, known symptoms, recent changes, communication channel, and next update
time. Use incident-record.md as the live log.
Separate confirmed facts from hypotheses.
Contain and recover
- Protect people, data integrity, credentials, and irreversible state.
- Reduce blast radius with a kill switch, traffic shift, dependency isolation,
rollback, rate limit, or safe degradation when authorized.
- Preserve timestamps, deploy identifiers, logs, metrics, traces, and commands
before ephemeral evidence disappears.
- Test ranked hypotheses without making several uncontrolled production
changes at once.
- Verify recovery from user-facing behavior and service-level signals, not one
green dashboard.
Use release-engineering for a failed rollout, security-and-hardening for an
active security boundary, and root-cause-debugging for deeper diagnosis after
the service is stable. Production mutations require the repository's normal
authority and approval; this skill does not grant it.
Communicate and close
Publish concise updates with verified impact, current mitigation, user action if
any, and next update time. Avoid speculative root causes. Close the incident
only after critical paths, backlog recovery, data reconciliation, and alert
state are checked.
Create a blameless timeline and a small set of owned, dated actions: regression
proof, detection gap, recovery improvement, and prevention at the correct owner
boundary. Track them outside the incident document.
Completion condition
Impact has ended, recovery is independently verified, data and queued work are
reconciled or explicitly owned, communications are complete, and follow-up
actions have owners and due dates.
1---2name: incident-response3description: Coordinates an active production incident by establishing command, reducing blast radius, preserving evidence, communicating verified impact, restoring service, validating recovery, and creating owned follow-up actions. Use for outages, severe degradation, security or data-integrity events, failed releases, and urgent operational triage. Not for a normal local bug, routine alert tuning, or a postmortem after the incident is already closed.4---56# Incident Response78Stabilize first, learn second. Do not let diagnosis delay a safe reversible9mitigation.1011## Establish control1213Record start time, incident commander, responders, severity, affected users and14regions, known symptoms, recent changes, communication channel, and next update15time. Use [incident-record.md](references/incident-record.md) as the live log.16Separate confirmed facts from hypotheses.1718## Contain and recover19201. Protect people, data integrity, credentials, and irreversible state.212. Reduce blast radius with a kill switch, traffic shift, dependency isolation,22 rollback, rate limit, or safe degradation when authorized.233. Preserve timestamps, deploy identifiers, logs, metrics, traces, and commands24 before ephemeral evidence disappears.254. Test ranked hypotheses without making several uncontrolled production26 changes at once.275. Verify recovery from user-facing behavior and service-level signals, not one28 green dashboard.2930Use `release-engineering` for a failed rollout, `security-and-hardening` for an31active security boundary, and `root-cause-debugging` for deeper diagnosis after32the service is stable. Production mutations require the repository's normal33authority and approval; this skill does not grant it.3435## Communicate and close3637Publish concise updates with verified impact, current mitigation, user action if38any, and next update time. Avoid speculative root causes. Close the incident39only after critical paths, backlog recovery, data reconciliation, and alert40state are checked.4142Create a blameless timeline and a small set of owned, dated actions: regression43proof, detection gap, recovery improvement, and prevention at the correct owner44boundary. Track them outside the incident document.4546## Completion condition4748Impact has ended, recovery is independently verified, data and queued work are49reconciled or explicitly owned, communications are complete, and follow-up50actions have owners and due dates.
thiientv