pre-mortem

id	pre-mortem
name	Pre-mortem 失敗シナリオ分析
description	変更が将来インシデントや技術的負債を引き起こすと仮定し、その原因と経路を逆算して設計の盲点を可視化する
version	0.1.0
category	upstream
phase	upstream
applyTo	["docs/**/*design*.md","docs/**/*architecture*.md","docs/adr/**/*","pages/**/*design*.md","**/*.adr"]
tags	["adversarial","pre-mortem","risk","design","upstream","cognitive-bias"]
severity	major
inputContext	["diff","fullFile","adr","commitMessage"]
outputKind	["findings","questions","actions"]
modelHint	high-accuracy
dependencies	["repo_metadata","code_search"]

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 失敗シナリオ分析はチェックリスト型評価が主だが、設計判断を含まない変更では実行を止めるゲートが必要

Goal / 目的

• 変更が「6ヶ月後にインシデントを引き起こした」と仮定し、その根本原因を逆算することで、生存バイアスや楽観バイアスを排除し、設計の致命的欠陥を事前に発見する。
• 通常のリスク分析では浮上しない「見落としがちな失敗経路」をあぶり出す。
• 既定 CI レビューでは自動発火しない（/challenge 等の明示呼び出し向け）。

Non-goals / 扱わないこと

• 既知のベストプラクティス違反の指摘（それは既存スキルの役割）。
• 実装の細部（コードスタイル、命名規則など）への言及。
• すべての変更に対する網羅的なリスク列挙（重大な失敗シナリオに集中する）。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• 差分に設計判断を含む変更がある（ADR、設計ドキュメント、アーキテクチャ変更）
• 変更が機械的なもの（誤字修正、フォーマット、コメントのみ）ではない
• テストコードやフィクスチャのみの変更ではない
• inputContextにdiffまたはfullFileが含まれている

ゲート不成立時の出力: NO_REVIEW: pre-mortem — 設計判断を含む変更が検出されない

False-positive guards / 抑制条件

• すでにADRやデザインドキュメントでリスクと緩和策が明記されている項目は重複指摘しない。

Rule / ルール

分析フレームワーク

1. 仮想失敗宣言: 「この変更は6ヶ月後に深刻な障害を引き起こした」と断定する。
2. 逆算推論: その障害に至る具体的な因果連鎖を3つ以上構築する。
3. 隠れた前提の発掘: 変更が暗黙に依存している前提条件を列挙する。
4. ドミノ効果の追跡: 1つの前提が崩れたとき、何が連鎖的に壊れるかを追う。

失敗カテゴリ（優先順）

1. データ破損・不整合: スキーマ変更、マイグレーション、状態管理の欠陥
2. 障害の伝播: 依存サービスの停止、タイムアウト未設定、リトライ暴走
3. スケーラビリティの壁: 暗黙のO(n²)、メモリリーク、接続プール枯渇
4. 運用不能: ログ不足、ロールバック不可、監視の盲点
5. セキュリティ劣化: 権限昇格の経路、入力検証の抜け穴

制約

• 失敗シナリオは最大 5 件。最も致命的なものを優先。
• 各シナリオには必ず「崩れる前提」「因果連鎖」「検証方法」を含める。
• 推測は推測として明示する（「可能性がある」「〜の場合に限り」）。

Evidence / 根拠の取り方

• 失敗シナリオは差分の具体的な行に紐づける（<file>:<line>）。
• 因果連鎖は差分→既存コード→外部依存の順で追跡可能にする。
• 「なぜこの前提が崩れうるか」の根拠を示す（類似インシデント、既知の制約など）。

Output / 出力フォーマット

すべて日本語。

(pre-mortem):1: [要約] この変更の最大リスクは〈1文〉

<file>:<line>: [失敗シナリオ1] <タイトル>
  崩れる前提: <この変更が暗黙に依存していること>
  因果連鎖: <前提崩壊 → 中間事象 → 障害>
  検証方法: <この失敗を事前に防ぐ/検知する方法>

<file>:<line>: [失敗シナリオ2] ...