메뉴
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.
