postmortem-writing

postmortem-writing 技能總覽

postmortem-writing 的用途

postmortem-writing 技能可協助代理產出結構完整、以免責文化為核心的事故事後檢討報告，補上團隊在高壓情境下最常遺漏的部分：清楚的時間軸、根因分析、促成因素、影響範圍，以及可實際追蹤的後續行動。它適合用在服務中斷、效能劣化、險些釀禍事件、資料問題，或其他值得組織從中學習的事故之後，而不是只寫一份鬆散的摘要。

誰適合安裝 postmortem-writing

這個技能特別適合下列對象：

• SRE、DevOps、平台工程與事故應變團隊
• 需要一致化事故報告的工程經理
• 在停機事件後負責撰寫內部報告交付物的人員
• 想從責怪導向的檢討，轉向系統思維的團隊

如果你的核心工作是把凌亂的事故筆記整理成可用的事後檢討，postmortem-writing 會比一般通用寫作提示詞更聚焦。

真正要解決的工作需求

多數使用者並不是抽象地需要「幫我寫一份文件」。他們真正需要的是：把 log、聊天串、警示、零碎記憶整理成一份報告，而且這份報告要能：

• 用白話說清楚發生了什麼事
• 保留事件先後順序
• 區分根因與促成因素
• 避免責怪個人
• 最後收斂成可追蹤的行動項目

這就是 postmortem-writing 技能的實際價值。

這個技能和一般提示詞有何不同

它的主要差異不在花俏的自動化，而在編輯結構與事故檢討紀律。原始內容特別強調：

• 免責式表述
• 明確說明哪些事故情境值得寫 postmortem
• 先建立時間軸的工作流程
• 聚焦根因分析，而不是只停留在表面症狀
• 把行動項目視為最終產物，而非事後補充

因此，當你要的是一致性與較安全的表述，而不只是看起來更流暢的文字時，postmortem-writing skill 就特別有用。

採用前要先知道的事

這個技能是以文件指引為主。從 repository 內容來看，目前只有 SKILL.md，沒有輔助腳本、schema 或參考檔案。也就是說，postmortem-writing install 很簡單，但輸出品質會高度取決於你提供的事故素材。如果你期待它自動蒐證或建立 ticket，這個技能本身不會幫你完成。

如何使用 postmortem-writing 技能

postmortem-writing install 情境

請從上層技能 repository 安裝：

npx skills add https://github.com/wshobson/agents --skill postmortem-writing

由於此技能位於 plugins/incident-response/skills/postmortem-writing，你安裝的是一套寫作流程與指引層，而不是獨立的事故管理平台。

先讀這個檔案

請先從這裡開始：

• SKILL.md

這個技能沒有另外提供 resources/、rules/ 或腳本，因此最快的 repository 閱讀路徑，就是把 SKILL.md 從頭到尾讀完。這點很重要，因為它的價值主要來自流程指引與寫作框架，而不是程式碼。

最適合啟用 postmortem-writing 的時機

當你已經判斷某起事故需要正式 written postmortem 時，就很適合使用 postmortem-writing usage，尤其是以下情境：

• SEV1 或 SEV2 事故
• 對客戶可感知、且不只是短暫閃斷的服務中斷
• 資料遺失或安全事件
• 具高嚴重性潛力的 near-miss
• 首次出現的故障模式，或需要異常人工介入的事件

如果事件影響很小，也沒有明顯學習價值或修復需求，簡短的事故記錄可能就足夠了。

這個技能需要哪些輸入

如果你提供的是原始事故素材，而不只是「幫我寫一份 postmortem」，這個技能的效果會好很多。實用的輸入包括：

• 事故摘要
• 開始與結束時間
• 對客戶或系統的影響
• 關鍵事件時間軸
• 偵測方式
• 緩解步驟
• 推測中的根因
• 已知的促成因素
• 尚未解決的問題
• 已討論過的後續行動

你的時間序資料越精準，最後報告的品質通常就越高。

把粗略需求改成高品質提示詞

弱提示詞：

• 「幫我寫昨天 outage 的 postmortem。」

強提示詞：

• 「Use the postmortem-writing skill to draft a blameless postmortem for a 47-minute API outage on 2025-02-10. Include a minute-by-minute timeline, impact summary, root cause, contributing factors, what detection missed, and action items grouped by prevention, detection, and response. Mark uncertainties clearly instead of inventing details.”

為什麼這樣更好：

• 它先界定了事故範圍
• 它明確要求免責式表述
• 它點出容易遺漏但很重要的段落
• 它允許保留不確定性，而不是編造看似確定的內容

一個實用的提示詞模板

你可以用這種 prompt 結構：

• Incident type: outage, degradation, security event, data incident, near-miss
• Severity: SEV level or equivalent
• Time window: start, detection, mitigation, resolution
• Impact: users, revenue, requests, data, internal operations
• Evidence: logs, alerts, chat notes, ticket excerpts
• Suspected cause: what failed and why
• Contributing factors: tooling, process, load, config, staffing, dependencies
• Desired output: executive summary, timeline, RCA, lessons learned, action items
• Tone constraint: blameless, factual, no named-person blame
• Unknowns: list them explicitly

這是最快改善 postmortem-writing for Report Writing 成果的方式。

真實事故可採用的工作流程

一個可行的流程如下：

1. 先從事故筆記與系統證據蒐集原始事實。
2. 請技能產出第一版結構化草稿。
3. 檢查時間軸是否有順序錯誤。
4. 重新收斂根因與促成因素的界線。
5. 移除帶有責怪意味的措辭。
6. 如有需要，在草稿之外補上負責人與到期日等行動項目資訊。
7. 在 postmortem 會議中使用最終報告。

這個順序符合團隊實際撰寫事故檢討的方式：先事實、再解讀、最後才是修復與改善。

如何讓時間軸寫得更可靠

時間軸品質通常直接決定這份文件是否值得信任。請提供帶時間戳記的條列，例如：

• 09:14 UTC: latency alert fired
• 09:16 UTC: on-call acknowledged
• 09:21 UTC: deploy rollback started
• 09:37 UTC: error rate returned to baseline

如果缺少這些內容，再好的 postmortem-writing guide 也很難可靠地重建因果關係。

如何要求更好的根因分析

不要只要求「找出 root cause」。你應該要求它一起分析：

• 直接原因
• 更深層的系統性因素
• 為什麼保護機制沒有發揮作用
• 為什麼偵測或升級通報太慢
• 是哪些條件讓這次失敗成為可能

這樣可以避免輸出收斂成「因為一次不良部署」，那通常太淺，實務上幫助不大。

如何讓報告維持免責文化

這個技能明確以 blameless culture 為核心。你可以在 prompt 中再次強化：

• 要求聚焦於系統條件，而不是個人過失
• 要求使用中性措辭
• 要求把人的行為，與組織與技術背景分開描述

例如，優先使用：

• “The deployment process allowed an unsafe config change to reach production”
  而不是：
• “An engineer pushed the wrong setting”

這個技能不提供什麼

從目前內容來看，postmortem-writing skill 不包含：

• 自動化資料蒐集
• 從工具中自動抽取事故時間軸
• ticket 同步
• 除了一般性指引外的嚴重度分類邏輯
• 可直接套用的組織專屬模板

因此你仍需要自行提供情境資料，並依照團隊的事故管理流程調整輸出。

postmortem-writing 技能 FAQ

postmortem-writing 真的比一般 LLM 提示詞更好嗎？

通常是，尤其當你的主要問題是結構與寫作紀律時。一般提示詞也能生出 postmortem，但常會漏掉事故觸發條件、免責式表述，或無法清楚區分根因與促成因素。postmortem-writing 提供的是更明確的操作框架。

初學者適合用嗎？

適合。它對初學者算友善，因為指引很多，也不需要額外工具。不過初學者仍然必須提供基本的事故事實紀錄。這個技能能改善的是寫作品質與檢討結構，不能取代事故調查本身。

什麼情況不該使用 postmortem-writing？

以下情況建議跳過：

• 事件本身不值得寫完整 postmortem
• 你需要的是即時事故指揮，而不是寫作者
• 你連基本事實都還沒有，仍在持續除錯中
• 你的組織要求非常嚴格的專有模板，而這個技能若不大幅改寫就無法貼合

postmortem-writing 只能用在工程停機事故嗎？

不是。它最貼近技術事故場景，但同樣的框架也可用於安全事件、資料事故、營運失誤，以及嚴重的 near-miss，只要你能提供時間軸、影響與修正行動即可。

我可以用 postmortem-writing 只產出高層摘要嗎？

可以，但不建議只停在那裡。主管通常需要精簡摘要，而應變人員需要完整時間軸與行動計畫。較好的做法是要求技能同時產出簡短摘要與完整報告。

這個技能會幫忙整理行動項目嗎？

會，但屬於間接幫助。原始指引很強調可執行的後續項目。如果你希望成果更好，建議明確要求依類別整理行動，例如 prevention、detection、response、process improvement。

如何提升 postmortem-writing 技能的效果

給 postmortem-writing 更好的證據，而不只是更好的指令

影響品質最大的槓桿，是輸入資料的真實度與完整度。建議直接貼上：

• 時間戳記
• 客戶影響指標
• alert 名稱
• 緩解步驟
• 已知但尚未釐清的問題

證據夠紮實，通常比一長串花俏的 meta-instructions 更有效。

把事實與解讀分開

常見失敗模式之一，是把推測混進時間軸。建議你分成兩塊提供：

• 已確認事實
• 假設或未解問題

這能幫助 postmortem-writing usage 在保留不確定性的同時，維持內容準確。

明確要求補上缺漏段落

如果第一版太空泛，就直接點名缺的段落：

• “Add a ‘What went well’ section”
• “Separate contributing factors from root cause”
• “Rewrite action items so each is specific and testable”

比起籠統地說「再寫好一點」，這種具體修訂要求更快帶來改善。

避免產出過度空泛的行動項目

品質不佳的 postmortem 常以模糊結論收尾，例如「加強監控」。你應要求技能讓每個 action 都具備：

• 明確性
• 可指派性
• 對應某個失敗模式
• 可衡量或可驗證

例如：

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  就比：
• “Improve alerting”
  更有效。

注意責怪語氣是否又滲回來

即使技能本身強調免責文化，原始聊天紀錄或筆記仍可能帶有責怪色彩。請在審稿時留意：內容是否過度聚焦某個人，而忽略了系統條件、誘因、工具限制、審查缺口或營運脈絡。

分兩輪迭代，通常能拿到更高品質輸出

一個可靠做法是：

1. 第一輪先整理事實結構
2. 第二輪再補分析與行動

這樣可以避免模型在時間序還不穩定時，就被迫生成看似完整但其實靠猜測撐起來的分析。

依團隊的 postmortem 成熟度調整輸出深度

如果你的團隊還在早期階段，可以要求 postmortem-writing 先用簡單格式輸出：時間軸、影響、原因、行動。若團隊已較成熟，則可要求更深入的段落，例如偵測缺口、升級流程是否有效、復原過程中的取捨，以及系統性教訓。這個技能兩種情境都能支援，但前提是你先定義清楚期待的深度。

第一版草稿之後，如何進一步提升 Report Writing 成果

若要取得更好的 postmortem-writing for Report Writing 成果，最後請用這四個問題做一次審查：

• 新加入的團隊成員看完後，是否能理解發生了什麼？
• 時間軸是否精準到足以回頭稽核？
• 分析是否說明了為什麼既有防線會失效？
• 行動項目是否具體到能降低再次發生的機率？

只要其中任何一題答案是否定的，就應該根據那個缺口修正 prompt，而不是盲目重跑一次。