postmortem

postmortem skill 概覽

postmortem skill 的用途

postmortem skill 是一套面向高階主管與導師式決策輔助的工作流程，可把產品上市失敗、目標未達、招募失誤、交易流失，或營運中斷等事件，轉化為不究責個人的根本原因分析。它會引導 agent 精準定義事件、用有紀律的 5-Whys 方式追問，並建立 change register，讓產出不只是「經驗教訓」，而是一組具體的系統性改善措施。

最適合領導團隊與 Quality Management 使用

這個 postmortem skill 特別適合創辦人、高階主管、營運負責人、產品主管、工程經理，以及需要理解實際結果為何偏離計畫的 Quality Management 團隊。它適用於目標是預防再發與流程改善，而不是追究責任的情境。若用於 postmortem for Quality Management，最大價值在於把失敗轉換成控制措施、負責人，以及可衡量的後續行動。

與一般 prompt 的差異

一般「分析哪裡出錯」的 prompt 往往會產出籠統評論。這個 skill 的範圍更窄，也更偏向實務操作：它會要求清楚定義事件、區分症狀與原因、避免把問題歸咎於特定個人，並追問哪些條件讓失敗更可能發生。它的核心差異在於 change register，能協助把洞察轉換成責任歸屬、期限，以及系統層級的修正。

採用前的重要注意事項

這個 repository 路徑中只有一個 SKILL.md，沒有輔助 scripts、references 或 metadata files。這讓 postmortem install 很輕量，但也代表 skill 的品質高度取決於你提供的脈絡。當你能分享足夠的事實紀錄，支撐一場嚴肅的事後檢討時，適合使用它；如果事件仍有高度政治風險、法律敏感性，或僅建立在傳聞之上，則應避免使用。

如何使用 postmortem skill

postmortem install 與應檢查的檔案

從 GitHub skill source 安裝：

npx skills add alirezarezvani/claude-skills --skill postmortem

來源位於：

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

請先閱讀 SKILL.md，因為完整的操作模型都在裡面。這裡沒有額外的 rules/、resources/、references/ 或 scripts/ 資料夾需要對齊，因此你的主要安裝判斷是：這個單一檔案的工作流程是否符合你的 retrospective 風格。

實務上如何呼叫這個 skill

這個 skill 採用 command pattern 設計：

/em:postmortem <event>

較弱的呼叫方式是：

/em:postmortem Q3 release slipped

較好的呼叫方式會提供 agent 足夠資料，讓它能區分事實、假設與原因：

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

能提升 postmortem 使用品質的輸入

若要讓 postmortem usage 更有效，請提供預期結果、實際結果、時間軸、最早的警訊、影響、關鍵決策、限制條件，以及當時已知的資訊。請同時包含量化證據與人的脈絡：營收缺口、缺陷數量、招募時程、錯過的里程碑、客戶影響、決策負責人、核准瓶頸，以及互相競爭的優先順序。

避免要求 skill「找出是誰造成的」。請改為要求它辨識系統條件：權責不清、升級通報路徑薄弱、不切實際的規劃假設、缺少品質關卡、誘因衝突，或風險可見性太晚。

產出有用結果的建議流程

先從一份以事實為主的事件簡報開始，接著請它產出第一版 postmortem 草稿。檢查 5-Whys 鏈條是否太早停止，或是否跳到一個方便但未必正確的解釋。然後用證據迭代：「Pressure-test the root cause against the timeline」、「Separate controllable causes from external shocks」，或「Convert these lessons into a change register suitable for the next exec review。」

最佳的最終文件通常包含：事件定義、影響摘要、促成因素、根本原因、非原因、在當時看起來合理的決策、建議的系統變更、負責人、期限，以及驗證指標。

postmortem skill 常見問題

postmortem 適合初學者嗎？

適合，前提是使用者能提供清楚的事件描述。這個 skill 的結構可降低事前熟悉正式 retrospective 方法的門檻。初學者在呼叫前應先準備簡短時間軸與結果落差；否則，模型可能會用看似合理但未經驗證的假設補足缺漏脈絡。

什麼時候不該使用這個 skill？

不要把它當成績效考核、懲處工具、法律調查，或未經人工審閱的公開事故聲明。若領導層只想要一份漂亮的敘事，而不是面對不舒服的因果分析，它也不適合。若組織無法根據發現採取行動，一場 postmortem 可能帶來挫折，而不是改善。

它和 incident review 有什麼不同？

incident review 通常聚焦於技術服務故障與營運復原。這個 postmortem skill 的範圍更廣：季度目標未達、上市失敗、招募失誤、交易流失、產品挫敗，以及領導決策都在適用範圍內。它可以支援 Quality Management，但除非經具備資格的審閱者調整，否則不能取代受規範的 CAPA、audit 或 compliance documentation。

這個 skill 需要特定生態系嗎？

不需要。這個 skill 是純 markdown，可用上述 command 安裝到相容的 skills workflow。因為沒有 scripts 或外部 assets，它可移植到商務、產品、工程與營運等情境。取捨在於：它不會自動擷取 dashboards、ticket systems 或 incident logs；你必須自行摘要或貼上相關證據。

如何改進 postmortem skill

提供更好的 postmortem 原始素材

改善 postmortem 結果最快的方法，是提供一份精簡的 evidence pack。內容包含：目標、實際結果、時間軸、決策點、錯過的訊號、限制條件、利害關係人、影響，以及既有假設。請清楚標示不確定的主張。例如：「Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope。」

留意常見失敗模式

最常見的失敗，是停留在過淺的根本原因，例如「溝通不良」或「缺乏 ownership」。請要求 agent 再往下一層追問：是什麼結構讓溝通失效？為什麼 ownership 會不清楚？為什麼規劃流程容許這種模糊存在？另一種失敗模式是過度修正，列出太多行動項目。應推動較少但有人負責、可觀察，且更可能防止再發的變更。

把發現轉成 change register

一份有力的 change register 應列出變更項目、它對應的根本原因、負責人、到期日、成功指標，以及檢視節奏。若用於 Quality Management，請加入 control type、verification method，以及 evidence required。這能讓 skill 的產出更容易落地到領導層檢討、季度規劃、release governance、招募流程調整，或持續改善計畫中。

在第一版回答後持續迭代

第一版草稿完成後，請提出有針對性的追問：「Which conclusions are evidence-backed versus inferred?」、「What would have prevented this without slowing the team unnecessarily?」、「What early warning metric should we add?」，或「Rewrite the change register for executive accountability。」postmortem skill 最適合被當成結構化調查夥伴，而不是一次性的報告產生器。