premortem

事前検死

計画がすでに失敗したと想定し、その理由を説明します。この「プロスペクティブ・ヒンドサイト（事前回顧）」という時制の切り替え（Klein、HBR 2007）は、「何が問題になる可能性があるか？」と尋ねる場合よりも、失敗の原因を約30％多く引き出し、原因もより具体的になります。このスキルでは、この仕組みを、心配事のリストだけで終わらず、改訂した計画まで導く再現可能な手順にしています。

ワークフローの振り分け

トリガー	ワークフロー
「これを事前検死して」「事前検死を実施して」「何がこれを台無しにするか」、重大な計画	Workflows/RunPremortem.md（詳細：並列のディープダイブエージェント）
「簡易的な事前検死」、小規模な決定／個人的な決定、手早い直感チェック、情報が少ない状況	Workflows/QuickPremortem.md（単独で一度だけ実施、並列展開なし）
「事前検死スキルを更新して」、ワークフローの追加／修正	Workflows/Update.md

実質的なリスクを伴う場合は、デフォルトで RunPremortem を使用してください。QuickPremortem に切り替えるのは、決定が小規模な場合か、ユーザーが明示的にスピードを求めている場合だけです。

仕組み（この枠組みを省略しないでください）

この手法の要点はひとつです。失敗がすでに起きたと断定して伝え、その原因を尋ねます。 それ以外はすべて実施方法にすぎません。ユーザーが「すでに失敗した」という前提に入り込むのに役立たない手順は、省いてください。根拠と引用の全文は References/Methodology.md を参照してください。

クイックリファレンス

• 過去形で枠組みを示します。「[期間]が経ちました。[計画]は失敗しました。その理由はこちらです。」。「失敗するかもしれない」ではありません。
• まず、原因を個別に洗い出します。 RunPremortem では、並列エージェントは互いの出力を見てはいけません。これはアンカリングを防ぐための重要な対策です。
• 計画に固有の原因を求めます。 一般的なリスク（「スケジュールが遅れる」など）は退けてください。原因はすべて、計画の具体的な内容に基づいていなければなりません。
• 必ず行動につなげます。 残すリスクごとに、軽減策と早期警告シグナルを設定します。改訂した計画と、開始前チェックリストで締めくくります。実施後の対応がない事前検死は、形だけのものです。
• Markdownを正本とします。 トランスクリプト（.md）が記録です。HTMLは Tools/GenerateReport.ts --html で作成する任意のビジュアル資料であり、主な出力にはしません。

事前検死を実施しない場合

• 具体的な計画がない曖昧な構想 — 先に計画を集めてください。そうしないと、一般的なリスクしか挙がりません。
• すでに取り消せない決定 — 改訂する余地がないため、価値は低くなります。
• 事実に関する質問や創造的なフィードバック — 適切なツールではありません。
• アイデア／議論そのものを抽象的に批判する場合 → RedTeam。現在進行中の多視点ディベート → Council。

ツール

• Tools/GenerateReport.ts — 調査結果の JSON（スキーマは References/Templates.md）を Markdown レポート（デフォルト）または自己完結型 HTML レポート（--html）に変換します。bun で実行してください。詳しくは Tools/GenerateReport.help.md を参照してください。

注意点

このスキルで最も情報密度の高い部分です。実行のたびに予想外のことがあれば追記してください。

• 「30％」という統計は、正確さではなく量に関するものです。 1989年のMitchell/Russo/Penningtonの研究では、事前検死によって生成される理由の数が約30％増えることが示されました。正しい理由を特定する精度が30％向上するという意味ではありません。KleinによるHBRでの言い換え（「正しく特定する」）は誇張です。事前検死によって「正確さが30％向上する」とユーザーに伝えてはいけません。より多くの理由を、より_具体的に_挙げられるようになるのです。誤った引用をすると、分析全体がいいかげんに見えてしまいます。
• アンカリングは実行を台無しにします。 原因を順番に生成したり、あるエージェントに別のエージェントの出力を見せたりすると、最初に挙げられた失敗が、その後のすべてを方向づけてしまいます。独立して生成してから統合してください。これが、RunPremortemで並列エージェントを起動し、エージェント間のやり取りを明示的に禁止している理由です。
• 一般論に終始したリスクは、品質を損なう最大の要因です。 「予算超過」「チームの集中力が途切れる」「市場が変化する」は、あらゆる計画に当てはまり、何の役にも立ちません。対象を検索と置換で変えてもそのまま使える原因は、一般的すぎます。計画の実際の詳細を根拠として示すよう求めてください。
• 意思決定する前に実行してください。 資金を使い切り、チームも感情的に計画に入れ込んでから行う事前検死は、儀式にすぎなくなります。その価値は計画を_変える_ことにあるため、変更可能な計画が必要です。
• RedTeamやCouncilと混同しないでください。 事前検死は、_具体的な計画_の_将来の失敗_を想像し、計画の修正版を作成して終わります。RedTeamは、任意のアイデアに対する敵対的な攻撃です。Councilは、_現在の_複数の視点による議論です。用語は重なりますが、仕組みは異なります。
• コンテキストが乏しいと、一般論ばかりの出力になります。 （1）何を事前検死するのかを1文で説明できるか、（2）誰が影響を受けるか、（3）成功とは何か、のいずれかが不明なら、実行を止めて一度に1つだけ質問してください。何もないところから失敗を生成してはいけません。それでは、この手法が避けようとしている一般的なリスクをそのまま生み出してしまいます。
• 失敗は悲観主義ではありません。 出力するのは、緩和策を伴う具体的な因果関係の説明であり、破滅的な雰囲気ではありません。実行結果が「何もかもが危険だ」と読めるなら、失敗です。
• 発生可能性と深刻度は異なる軸です。 _最も起こりそうな_失敗と、_最も危険な_失敗は、たいてい同じではありません。両方を示してください。この違いが重要な洞察につながることがよくあります。

カスタマイズ

実行前に、~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/にユーザーのカスタマイズがあるか確認してください。PREFERENCES.mdが存在する場合は読み込み、適用してください（例：希望するデフォルトの想定期間、レポートのテーマ、失敗を分析するエージェントの数）。これらはデフォルト設定より優先されます。ディレクトリが存在しない場合は、スキルのデフォルト設定を使用してください。このスキル本体にプライベートな情報や個人識別情報を記載してはいけません。それらはSKILLCUSTOMIZATIONSに記載してください。

🚨 音声通知（呼び出し時に実行）

curl -s -X POST http://localhost:31337/notify \
  -H "Content-Type: application/json" \
  -d '{"message": "Running the WORKFLOWNAME workflow in the Premortem skill to ACTION"}' \
  > /dev/null 2>&1 &

続けて、次を出力します：Running the **WorkflowName** workflow in the **Premortem** skill to ACTION...

例

例1：ローンチの事前検死を完全に実施する

User: "Premortem our paid-newsletter launch next month"
→ RunPremortem: gather context (what/who/success) → frame "it's 6 months out, the launch failed"
→ generate plan-specific causes → fan out 1 agent per cause (independent) → synthesize
   most-likely + most-dangerous + hidden assumption + revised plan + checklist
→ write transcript .md, optionally GenerateReport.ts --html → 3-sentence chat summary

例2：手早く一人で直感を確認する

User: "quick premortem on accepting this contractor role"
→ QuickPremortem: single-pass, no agents → past-tense framing → 5-8 specific causes with
   likelihood/severity, hidden assumption, top mitigations → short markdown, no HTML

例3：RedTeamとの違いを明確にする

User: "poke holes in my argument that we should go remote-first"
→ This is attacking an ARGUMENT, not a plan-with-stakes → suggest RedTeam instead, or
   reframe: "if you want to premortem the remote-first *rollout plan*, I can do that."

実行ログ

ワークフローの完了後、JSONL形式のエントリを1つ追記してください：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Premortem","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl