メニュー
When something breaks in production: triage the severity, gather evidence, identify root cause, deploy a fix or mitigation, and write a post-mortem. Provides a calm, structured process for high-stress moments.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | incident-response |
| description | When something breaks in production: triage the severity, gather evidence, identify root cause, deploy a fix or mitigation, and write a post-mortem. Provides a calm, structured process for high-stress moments. |
First: breathe. Then classify.
| Severity | Definition | Response Time |
|---|---|---|
| P1 — Critical | Full outage, data loss, security breach | Immediate |
| P2 — High | Major feature broken, significant users affected | < 30 min |
| P3 — Medium | Partial degradation, workaround exists | < 2 hours |
| P4 — Low | Minor bug, cosmetic issue | Next sprint |
Open .agent/incidents/INC-<YYYY-MM-DD>-<slug>.md and write:
# Incident: <short title>
**Date:** <YYYY-MM-DD HH:MM UTC>
**Severity:** P<N>
**Status:** Investigating
**Incident Commander:** <name>
Don't guess. Collect data first.
Checklist:
Commands to run immediately:
# Recent deploys
git log --oneline -20
# Check running process / container health
# (adjust for your stack)
docker ps
systemctl status <service>
# Tail live logs
docker logs -f <container> --tail 100
journalctl -u <service> -n 100 -f
Add findings to the incident file under ## Evidence.
Before fixing, limit the damage:
git revert HEAD
# or redeploy previous known-good version
Document every action taken in the incident file with timestamps.
Once contained, find the real cause — not just the symptom.
Use the 5 Whys technique:
Why did users see a 500 error?
→ Because the database query timed out.
Why did the query time out?
→ Because a new index was missing after the migration.
Why was the index missing?
→ Because the migration script didn't include CREATE INDEX.
Why didn't the migration script include it?
→ Because we don't have a convention for checking query plans before deploy.
→ Root cause: Missing pre-deploy query plan review process.
The root cause is almost never the immediate technical failure — it's the process gap that allowed it.
Write the fix:
Deploy:
Within 24h of resolution, write a post-mortem in .agent/incidents/INC-<date>-<slug>.md:
# Post-Mortem: <title>
## Summary
<2-3 sentences: what happened, how long, how many users affected>
## Timeline
| Time (UTC) | Event |
|------------|-------|
| HH:MM | Issue first occurred (inferred from logs) |
| HH:MM | First alert / user report |
| HH:MM | Incident declared |
| HH:MM | Mitigation applied |
| HH:MM | Root cause identified |
| HH:MM | Fix deployed |
| HH:MM | Incident resolved |
## Root Cause
<The actual root cause — not just the symptom>
## What Went Well
- <something that helped — good monitoring, fast rollback, etc.>
## What Went Poorly
- <something that made it worse — slow detection, unclear runbook, etc.>
## Action Items
| Action | Owner | Due Date |
|--------|-------|----------|
| Add missing index to migration convention | <name> | <date> |
| Add test for query performance | <name> | <date> |
| Set up alert for DB query p99 latency | <name> | <date> |
After the post-mortem, use the knowledge-base-update skill to create a gotcha entry for the root cause so future agents and developers know about it.
Systematic code review skill covering both requesting a review (pre-commit checklist) and receiving and responding to review feedback. Checks code quality, security, test coverage, architectural alignment, and documentation before any code is committed.
Before committing to an implementation plan, run this skill to stress-test the proposed architecture. Catches over-engineering, circular dependencies, missing failure modes, security gaps, and scalability cliffs — before any code is written. Acts as a "second eye" on the plan.
Periodically scan project dependencies for security vulnerabilities, outdated packages, and unused dependencies. Produces a prioritized action report. Run before every major release and at least once per month.
After any significant code change — new feature, API modification, config change, or architectural refactor — run this skill to identify which documentation files are now stale and update them. Keeps docs and code from drifting apart.
Manages all git operations (commit, push, branch management, PR creation) in a standardized, safe, and consistent way. Automatically runs the code-review skill before any commit. Enforces Conventional Commits standard. Handles the full lifecycle: branch → review → commit → push → PR.
Use this skill whenever you learn something important during a conversation: a key architectural decision, a project-specific convention, a bug root-cause, a 3rd-party API quirk, or any fact that would help a future agent avoid re-doing the same research. Writes structured entries to the project's knowledge base so that context persists across conversations and agents.