incident-responder

name	incident-responder
description	本番障害・インシデントの対応進行（タイムライン記録・影響評価・止血）とポストモーテム（根本原因分析・非難なき振り返り）を支援するスキル。「障害対応」「インシデント対応」「ポストモーテムを書いて」「障害報告書を作って」「根本原因を分析して」「なぜなぜ分析して」「RCAして」「再発防止策をまとめて」などで発動する。
metadata	{"version":"1.0.0","tier":"experimental","category":"operations","tags":["incident","postmortem","rca","sre","oncall"]}

incident-responder

本番インシデントの 対応進行 と、収束後の ポストモーテム（事後分析） を支援する。目的は犯人探しではなく、事実の時系列化・根本原因の特定・再発防止である（blameless）。

コード内のバグ調査は systematic-debugging。本スキルは「本番で何が起きているか／起きたか」の運用・組織プロセスを扱う。

原則

• 非難なき（blameless） — 個人ではなく仕組み・プロセスの欠陥に焦点を当てる
• 事実と推測を分ける — タイムラインは観測事実で構成し、仮説は仮説として明記する
• 影響を先に評価 — 何が・誰に・どれだけ影響しているか（範囲・深刻度）を最初に確定する
• 暫定と恒久を分離 — 止血（mitigation）と根本対応（remediation）を混同しない

ワークフロー

モード判定

依頼が「対応中（active）」か「事後分析（postmortem）」かをまず見分ける。

モードA: 対応進行（インシデント発生中）

1. 検知と宣言: 何が観測されたか・いつ・どこで。深刻度を references/postmortem-template.md の重大度基準で仮設定する
2. 影響評価: 影響範囲（ユーザー数・機能・データ）、ビジネス影響、進行中か収束したか
3. 役割の明確化: 指揮（IC）・実作業・記録・対外連絡の担当を確認する（小規模なら兼務）
4. 止血を優先: ロールバック・フィーチャーフラグ off・スケールアウト・トラフィック制御など、根本原因が未特定でも被害を止める手を検討する
5. タイムライン記録: 時刻つきで「観測した事実」「実施した対応」「結果」を逐次記録する（後のポストモーテムの一次資料）
6. 収束確認とコミュニケーション: 復旧の確認基準を決め、関係者・ユーザーへの告知文面を整える

モードB: ポストモーテム（収束後）

1. タイムライン再構成: 検知→対応→収束を時系列で確定（ログ・記録・関係者証言から）
2. 根本原因分析: 5 Whys や寄与要因分析で「なぜ起きたか」「なぜ防げなかったか」「なぜ検知が遅れたか」を多層で掘る。単一犯人で止めない
3. 検知・対応の評価: MTTD/MTTR、検知手段は適切だったか、対応はスムーズだったか
4. 再発防止策（アクションアイテム）: 恒久対応を担当・期限つきで。優先度を付け、検知改善（アラート）も含める
5. ポストモーテム文書化: テンプレートに従い出力。meeting-minutes のアクションアイテム形式と整合させ、redmine-use 等でのチケット化を提案する

ガードレール

制限	内容
非難の禁止	個人名を責める表現を避け、仕組み・プロセスの言葉に置き換える
事実性	タイムラインに推測を混ぜない。不明な時刻・原因は「不明/要調査」と明記
二次被害防止	対応中の破壊的操作（DB変更・削除）は影響を確認し、可逆性とバックアップを問う
越権しない	実際のロールバック/本番操作はユーザー承認のもとで。手順の提示に留める