メニュー
Structured incident response: detect, communicate, mitigate, resolve, and prevent recurrence
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | incident-response |
| description | Structured incident response: detect, communicate, mitigate, resolve, and prevent recurrence |
Incidents are inevitable. How you respond determines whether they are learning opportunities or recurring nightmares. This skill gives you a structured process from first alert to prevention of recurrence.
Step 1: Acknowledge the alert Acknowledge in your alerting system within 5 minutes. This signals you're on it and stops duplicate escalations.
Step 2: Assess severity
Step 3: Declare the incident and open a channel For P0/P1: open an incident channel (#incident-YYYY-MM-DD-brief-description). All communication goes there. Appoint an Incident Commander (IC).
Step 4: Post a status update Within 15 minutes of detection, post to the status page: "We are investigating reports of [symptom]. We will provide an update in 30 minutes." Do not wait until you have a fix. Users need to know you know.
Step 5: Brief stakeholders Notify: on-call manager, customer-facing teams, affected customers (for P0/P1). Use the incident channel as the single source of truth.
Step 6: Stop the bleeding first Mitigation before diagnosis. Options:
Don't spend time diagnosing the root cause while users are impacted. Mitigate first.
Step 7: Diagnose Once impact is reduced, find the root cause:
Step 8: Implement the fix Implement the minimal fix. This is not the time for refactoring.
Step 9: Confirm resolution Verify: error rate back to baseline, latency back to baseline, no new error types in logs, affected users can complete their tasks.
Step 10: Update status page Post: "The issue has been resolved. Affected users can [action]. We will publish a post-mortem within 48 hours."
Step 11: Write the post-mortem Structure:
Step 12: Blameless post-mortem Focus on systems and processes, not individuals. "The deployment pipeline allowed a bad config to reach production" not "Alice pushed bad config."
"We'll communicate once we have a fix" Users need to know you know. An hour of silence is worse than an honest "we're investigating."
"We know the root cause — no need for a post-mortem" Post-mortems are not just for finding root causes. They identify contributing factors, test your detection and response, and create shared understanding. Skip them and the same incident recurs.
