postmortem-writing

postmortem-writing スキルの概要

postmortem-writing でできること

postmortem-writing スキルは、構造化された、非難に寄らないインシデントのポストモーテム作成を支援します。特に、障害対応の最中や直後は抜けやすい要素――明確なタイムライン、根本原因分析、寄与要因、影響範囲、そして具体的なフォローアップアクション――まで含めて整理できるのが特長です。対象は、障害、サービス劣化、ヒヤリハット、データ問題など、単なる要約ではなく組織的な学びにつながる報告書が必要なケースです。

postmortem-writing を導入すべき人

このスキルが特に合うのは、次のようなケースです。

• SRE、DevOps、プラットフォーム、インシデントレスポンスの各チーム
• 一貫性のあるインシデント報告書が必要なエンジニアリングマネージャー
• 障害後の社内報告書を作成する担当者
• 個人の責任追及型ふりかえりから、システム思考ベースのレビューへ移行したいチーム

雑多なインシデントメモを、実際に使えるポストモーテムへ落とし込むのが主目的なら、postmortem-writing は汎用的な文章生成プロンプトよりも的確です。

実際に解決したい仕事

多くのユーザーが必要としているのは、抽象的な意味での「文書作成支援」ではありません。必要なのは、ログ、チャットスレッド、アラート、断片的な記憶をもとに、次の条件を満たすレポートへまとめる支援です。

• 何が起きたかを平易な言葉で説明する
• 時系列を保つ
• 根本原因と寄与要因を分けて扱う
• 個人を責める書き方を避ける
• 最後に追跡可能なアクションで締める

これこそが postmortem-writing スキルの実務上の価値です。

普通のプロンプトと何が違うのか

このスキルの差別化ポイントは、高度な自動化ではありません。編集構成の型と、インシデントレビューの作法にあります。元の内容では、特に次の点が重視されています。

• 非難しない前提のフレーミング
• どのような事象でポストモーテムが必要になるかの明示
• タイムラインを起点に進めるワークフロー
• 表面的な症状ではなく根本原因分析を重視する姿勢
• アクションアイテムを「ついで」ではなく成果物の中心に置くこと

そのため postmortem-writing skill は、単に整った文章がほしいときよりも、表現の安全性と報告の一貫性を確保したい場面で役立ちます。

導入前に知っておきたいこと

このスキルはドキュメント中心です。リポジトリ上で確認できるのは SKILL.md のみで、補助スクリプト、スキーマ、参照ファイルは見当たりません。つまり postmortem-writing install 自体は簡単ですが、出力品質は、入力するインシデント情報の質に大きく左右されます。証跡の自動収集やチケット起票まで期待しているなら、このスキル単体では対応できません。

postmortem-writing スキルの使い方

postmortem-writing のインストール前提

親のスキルリポジトリからインストールします。

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

このスキルは plugins/incident-response/skills/postmortem-writing にあるため、導入されるのはスタンドアロンのインシデント管理基盤ではなく、執筆ワークフローとガイダンスのレイヤーです。

最初に読むべきファイル

まず確認するのは次です。

• SKILL.md

このスキルでは resources/、rules/、スクリプト類の補助ファイルは表に出ていません。したがって、リポジトリを読む最短ルートは SKILL.md を最初から最後まで通して読むことです。このスキルの価値はコードではなく、進め方の指針とフレーミングにあるので、ここは特に重要です。

postmortem-writing を呼び出すべきタイミング

postmortem-writing usage は、すでに「正式な振り返り文書が必要なインシデントだ」と判断できている場面で使うのが最適です。特に向いているのは次のケースです。

• SEV1 または SEV2 のインシデント
• 一瞬の瞬断では済まない、顧客影響のある障害
• データ消失やセキュリティ問題
• 深刻化していてもおかしくなかったヒヤリハット
• 新規性のある障害や、通常と異なるオペレーター介入が発生した事象

影響が軽微で、学びや是正対応が不要なイベントなら、短いインシデントメモだけで十分な場合もあります。

このスキルに必要な入力

このスキルは、「ポストモーテムを書いて」だけ渡すより、生のインシデント材料を与えたほうが機能します。特に有用なのは次の情報です。

• インシデント概要
• 開始時刻と終了時刻
• 顧客またはシステムへの影響
• 主要イベントのタイムライン
• 検知方法
• 緩和・復旧の手順
• 想定される根本原因
• 判明している寄与要因
• 未解決の疑問点
• すでに議論済みのフォローアップアクション

時系列が正確であるほど、最終レポートの質は上がります。

粗い依頼を強いプロンプトに変える

弱いプロンプト:

• “Write a postmortem for yesterday’s outage.”

強いプロンプト:

• “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.”

これが優れている理由:

• インシデントの対象範囲が明確
• 非難しない前提が指定されている
• 抜けやすいが重要なセクションを要求している
• 根拠のない断定ではなく、不確実性の明示を許容している

実用的なプロンプトテンプレート

次のような形で依頼すると使いやすくなります。

• 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-writing で良いタイムラインを作るコツ

タイムラインの質は、その文書が信頼できるかどうかを大きく左右します。次のように、時刻付きの箇条書きを渡してください。

• 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 でも因果関係を安定して再構成することはできません。

より良い根本原因分析を依頼する方法

単に “the root cause” だけを求めないでください。代わりに、次を明示して求めます。

• 直接的な原因
• その背後にある深いシステム要因
• なぜ安全策が機能しなかったのか
• なぜ検知やエスカレーションが遅れたのか
• なぜその障害が起き得る状態だったのか

こうすることで、出力が「悪いデプロイが起きた」で終わる浅い説明に崩れるのを防げます。

文書を非難しないトーンに保つ方法

このスキルは、非難しない文化を明確に重視しています。プロンプトでもその点を補強してください。

• 個人の過失ではなく、システム条件に焦点を当てるよう求める
• 中立的な表現を指定する
• 人の行動と、組織的・技術的な文脈を分けて書くよう求める

たとえば、次の表現が望ましいです。

• “The deployment process allowed an unsafe config change to reach production”
  次のような書き方より適切です。
• “An engineer pushed the wrong setting”

このスキルでは提供されないもの

postmortem-writing skill には、次の機能は含まれていないようです。

• データ収集の自動化
• ツールからのインシデントタイムライン抽出
• チケット同期
• 一般的な指針を超えた重大度分類ロジック
• そのまま使える組織専用テンプレート

必要な前提情報は自分で渡し、出力も自社のインシデント運用に合わせて調整する前提で考えるのが現実的です。

postmortem-writing スキル FAQ

postmortem-writing は普通の LLM プロンプトより良い？

多くの場合は Yes です。特に、課題が「構成」と「レビューの作法」にあるなら有利です。通常のプロンプトでもポストモーテムは作れますが、どの事象で作成対象にすべきか、非難しない前提、根本原因と寄与要因の区別といった点が抜けやすくなります。postmortem-writing は、エージェントにより明確な進め方を与えます。

初心者でも使えますか？

はい。ガイダンス中心で、専用ツールの準備も不要なので、初心者にも扱いやすいです。ただし、事実ベースのインシデント記録は自分で用意する必要があります。このスキルは文章品質とレビュー構造を改善するものであり、インシデント調査そのものを代替するものではありません。

postmortem-writing を使わないほうがいい場面は？

次のような場合は見送るほうが適切です。

• その事象がフルのポストモーテムに値しない
• 必要なのが執筆支援ではなく、リアルタイムの incident commander である
• 基本的な事実がまだ揃っておらず、なお調査・デバッグ中である
• 組織として厳格な独自テンプレートが必要で、このスキルでは大幅な調整なしに合わせられない

postmortem-writing はエンジニアリング障害専用ですか？

いいえ。技術インシデントとの相性がもっとも良いのは確かですが、タイムライン、影響、是正アクションを提供できるなら、セキュリティ事案、データ事故、運用障害、重大なヒヤリハットにも十分適用できます。

postmortem-writing をエグゼクティブサマリー作成に使えますか？

はい、使えます。ただし、それだけで終わらせないことが重要です。経営層には短い要約が必要でも、対応担当者には完全なタイムラインとアクションプランが必要です。簡潔な要約と完全版レポートの両方を出すよう依頼するとよいでしょう。

このスキルはアクションアイテム作成にも役立ちますか？

はい、直接ではなく間接的に役立ちます。元のガイダンスでは、実行可能なフォローアップ項目が重視されています。 prevention、detection、response、process improvement のようにカテゴリ分けしたアクションを求めると、結果はより良くなります。

postmortem-writing スキルを改善する方法

postmortem-writing には指示より証拠を渡す

品質を最も大きく左右するのは、入力の精度です。次のような情報を貼り込んでください。

• timestamps
• customer impact metrics
• alert names
• mitigation steps
• known unknowns

凝ったメタ指示より、情報量のある証拠のほうが効きます。

事実と解釈を分ける

よくある失敗は、タイムラインに推測が混ざることです。入力を次の2ブロックに分けて渡してください。

• confirmed facts
• hypotheses or open questions

これにより、postmortem-writing usage は正確さを保ちつつ、不確実性も適切に表に出しやすくなります。

足りないセクションは明示して追加させる

最初のドラフトが汎用的すぎるなら、不足しているセクション名をそのまま指定してください。

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

“make it better” のような曖昧な依頼より、具体的な修正指示のほうがはるかに効果的です。

浅いアクションアイテムを防ぐ

弱いポストモーテムは、最後が “improve monitoring” のような曖昧な対策で終わりがちです。各アクションについて、次の条件を満たすよう依頼してください。

• 具体的である
• 担当を割り当てられる
• 障害モードに結び付いている
• 測定またはテスト可能である

たとえば、

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  は、次より優れています。
• “Improve alerting”

blame が再び入り込んでいないか確認する

非難しない前提のスキルでも、元のチャットやメモに責任追及の強い表現が含まれていることがあります。個人に焦点が寄りすぎていないか、代わりにシステム条件、インセンティブ、ツール、レビュー不足、運用上の文脈がきちんと扱われているかを確認してください。

高品質な出力には二段階で回す

安定しやすいパターンは次の2段階です。

1. 1回目は事実構造の整理
2. 2回目は分析とアクションの深掘り

時系列が固まる前に、もっともらしい分析文をひねり出させないための進め方です。

チームの postmortem-writing 成熟度に合わせて出力を調整する

チームが立ち上がり期なら、postmortem-writing にはタイムライン、影響、原因、アクションを中心にしたシンプルな形式を求めるのが向いています。運用が成熟しているチームなら、検知の抜け、エスカレーションの有効性、復旧時のトレードオフ、システム全体の学びまで含めた深いセクションを求めるとよいでしょう。同じスキルで両方に対応できますが、期待する深さをこちらで明示することが前提です。

初稿後に report-writing の成果を高める

より良い postmortem-writing for Report Writing に仕上げるには、最後に次の4つの観点で見直してください。

• 新しく入ったチームメンバーでも、何が起きたか理解できるか
• タイムラインは監査できる程度に十分精密か
• 分析は、なぜ防御策が失敗したのかまで説明しているか
• アクションは、再発低減につながるほど具体的か

どれかが No なら、闇雲に再実行するのではなく、その不足点をプロンプトに反映して修正するのが近道です。