| name | postmortem |
| description | 事故記錄。收集資訊、分析 root cause、記錄修復步驟、防止再發。當服務出事故後使用。 |
| argument-hint | [事故簡述,如 '網站掛了兩小時' / 'deploy 後 API 500'] |
| allowed-tools | Bash(git*), Read, Write, Grep, Glob |
| author | Maki |
| version | 1.0.0 |
| tags | ["devops","incident","debugging","documentation"] |
| required_env | [] |
事故記錄(Postmortem)
目標
快速記錄事故,結構化分析 root cause,防止重複犯錯。
流程
Step 1: 收集資訊
詢問用戶(或從上下文取得):
- 什麼壞了?
- 什麼時候發現的?
- 影響範圍?(用戶數、持續時間、資料損失?)
Step 2: 分析 root cause
- 觸發的命令或操作
- 錯誤訊息
- 為什麼會走到這一步(5 Whys)
若有 repo,自動檢查:
git log --oneline -10 看最近改動
- 搜尋相關錯誤訊息
Step 3: 記錄修復步驟
- 怎麼修好的
- 花了多久
- 是否有 workaround 還是根本修復
Step 4: 寫入檔案
追加到當前專案的 logs/errors.md(沒有就建立),格式:
## YYYY-MM-DD: [簡述問題]
**影響**:[影響範圍和持續時間]
**觸發**:[什麼操作觸發的]
**錯誤**:[錯誤訊息]
**Root Cause**:[根本原因]
**修復**:[修復步驟]
**防止再發**:[應該怎麼避免]
**Timeline**:
- HH:MM 發現問題
- HH:MM 開始修復
- HH:MM 恢復正常
Step 5: 提出預防建議
- 如果這類問題之前發生過,指出來
- 建議加入自動化防護(CI check、monitoring、alert)
- 建議更新文件(CLAUDE.md、README、runbook)
Quality Gates
Heuristics
- 事故後 24 小時內記錄,記憶最清楚
- Root cause 用 5 Whys:問五次「為什麼」才算到底
- 防止再發優先考慮自動化(人的注意力不可靠)
- Blameless:記錄事實和流程,不指責個人