premortem

プレモーテム

計画、設計、実装を体系的に問い直し、問題が発生する前に失敗要因を特定します。Gary Klein の手法を基に、Shreyas Doshi（Stripe）が広めました。

使い方

/premortem              # Auto-detect context, choose depth
/premortem quick        # Force quick analysis (plans, PRs)
/premortem deep         # Force deep analysis (before implementation)
/premortem <file>       # Analyze specific plan or code

基本概念

「今から3か月後、このプロジェクトが見事に失敗したと想像してください。なぜ失敗したのでしょうか？」

リスクの分類（Shreyas のフレームワーク）

分類	記号	意味
タイガー	[TIGER]	対処しなければ明確な損害をもたらす脅威
ペーパータイガー	[PAPER]	脅威に見えるものの、おそらく問題ありません
エレファント	[ELEPHANT]	誰も話題にしたがらないこと

重要：指摘する前に検証する

パターンマッチングだけに基づいてリスクを指摘しないでください。 タイガーとなり得るものはすべて、必ず検証してください。

偽陽性の問題

偽のタイガーを生み出す、よくある間違い：

• if exists(): によるフォールバックを確認せず、ハードコードされたパスを見つける
• 「X は対象範囲に含まれるのか？」と確認せず、機能 X がないと指摘する
• 前後の文脈を読むために行 N±20 を確認せず、行 N のコードを指摘する
• コードをたどって確認せず、エラーケースが処理されていないと思い込む

検証チェックリスト（必須）

タイガーを1つでも指摘する前に、次の点を検証してください。

potential_finding:
  what: "Hardcoded path at line 42"

verification:
  context_read: true    # Did I read ±20 lines around the finding?
  fallback_check: true  # Is there try/except, if exists(), or else branch?
  scope_check: true     # Is this even in scope for this code?
  dev_only_check: true  # Is this in __main__, tests/, or dev-only code?

result: tiger | paper_tiger | false_alarm

検証項目のいずれかが「いいえ」または「不明」の場合、タイガーとして指摘しないでください。

必須の根拠形式

すべてのタイガーには、次の情報を必ず含めてください。

tiger:
  risk: "<description>"
  location: "file.py:42"
  severity: high|medium
  # REQUIRED - what mitigation was checked and NOT found:
  mitigation_checked: "No exists() check, no try/except, no fallback branch"

mitigation_checked に具体的な根拠を記入できない場合、それは検証済みのタイガーではありません。

ワークフロー

ステップ 1：コンテキストと深度を判定する

# Auto-detect based on context
if in_plan_creation:
    depth = "quick"   # Localized scope
elif before_implementation:
    depth = "deep"    # Global scope
elif pr_review:
    depth = "quick"   # Localized scope
else:
    # Ask user
    AskUserQuestion(
        question="What depth of pre-mortem analysis?",
        header="Depth",
        options=[
            {"label": "Quick (2-3 min)", "description": "Plans, PRs, localized changes"},
            {"label": "Deep (5-10 min)", "description": "Before implementation, global scope"}
        ]
    )

ステップ 2：適切なチェックリストを実行する

クイックチェックリスト（計画、PR）

以下を頭の中で確認し、該当する項目を記録します。

基本的な質問：

1. うまくいかない可能性がある、最大の要因は何ですか？
2. 失敗する可能性のある外部依存関係はありますか？
3. 問題が起きた場合、ロールバックできますか？
4. テストでカバーされていないエッジケースはありますか？
5. 手戻りの原因になり得る不明確な要件はありますか？

出力形式：

premortem:
  mode: quick
  context: "<plan/PR being analyzed>"

  # Two-pass process: first gather potential risks, then verify each one
  potential_risks:  # Pass 1: Pattern-matching findings
    - "hardcoded path at line 42"
    - "missing error handling for X"

  # Pass 2: After verification
  tigers:
    - risk: "<description>"
      location: "file.py:42"
      severity: high|medium
      category: dependency|integration|requirements|testing
      mitigation_checked: "<what was NOT found>"  # REQUIRED

  elephants:
    - risk: "<unspoken concern>"
      severity: medium

  paper_tigers:
    - risk: "<looks scary but ok>"
      reason: "<why it's fine - what mitigation EXISTS>"
      location: "file.py:42-48"  # Show the mitigation location

  false_alarms:  # Findings that turned out to be nothing
    - finding: "<what was initially flagged>"
      reason: "<why it's not a risk>"

詳細チェックリスト（実装前）

各カテゴリを体系的に確認します。

技術的リスク：

• スケーラビリティ：現在の負荷の10倍、100倍でも動作しますか？
• 依存関係：外部サービスとフォールバックが定義されていますか？
• データ：可用性、一貫性、移行が明確ですか？
• レイテンシ：SLA の要件を満たせますか？
• セキュリティ：認証、インジェクション、OWASP を考慮していますか？
• エラー処理：すべての失敗ケースをカバーしていますか？

統合リスク：

• 互換性を損なう変更を特定していますか？
• 移行経路を定義していますか？
• ロールバック戦略はありますか？
• フィーチャーフラグは必要ですか？

プロセスリスク：

• 要件は明確で、網羅されていますか？
• すべての関係者から意見を集めていますか？
• 技術的負債を追跡していますか？
• 保守の負担を把握していますか？

テストリスク：

• カバレッジの不足箇所を特定していますか？
• 統合テスト計画はありますか？
• 負荷テストは必要ですか？
• 手動テスト計画を定義していますか？

出力形式：

premortem:
  mode: deep
  context: "<implementation being analyzed>"

  # Two-pass process
  potential_risks:  # Pass 1: Initial scan findings
    - "no circuit breaker for external API"
    - "hardcoded timeout value"

  # Pass 2: After verification (read context, check for mitigations)
  tigers:
    - risk: "<description>"
      location: "file.py:42"
      severity: high|medium
      category: scalability|dependency|data|security|integration|testing
      mitigation_checked: "<what mitigations were looked for and NOT found>"
      suggested_fix: "<how to address>"

  elephants:
    - risk: "<unspoken concern>"
      severity: medium|high
      suggested_fix: "<suggested approach>"

  paper_tigers:
    - risk: "<looks scary>"
      reason: "<why it's actually ok - cite the mitigation code>"
      location: "file.py:45-52"

  false_alarms:
    - finding: "<initial concern>"
      reason: "<why verification showed it's not a risk>"

  checklist_gaps:
    - category: "<which checklist section>"
      items_failed: ["<item1>", "<item2>"]

ステップ 3：AskUserQuestion を通じてリスクを提示する

必須： 調査結果を提示し、ユーザーの判断を求めてください。

# Build risk summary
risk_summary = format_risks(tigers, elephants)

AskUserQuestion(
    question=f"""Pre-Mortem identified {len(tigers)} tigers, {len(elephants)} elephants:

{risk_summary}

How would you like to proceed?""",
    header="Risks",
    options=[
        {
            "label": "Accept risks and proceed",
            "description": "Acknowledged but not blocking"
        },
        {
            "label": "Add mitigations to plan (Recommended)",
            "description": "Update plan with risk mitigations before proceeding"
        },
        {
            "label": "Research mitigation options",
            "description": "I don't know how to mitigate - help me find solutions"
        },
        {
            "label": "Discuss specific risks",
            "description": "Talk through particular concerns"
        }
    ]
)

ステップ 4：ユーザーの回答に対応する

「リスクを受け入れて進める」の場合

# Log acceptance for audit trail
print("Risks acknowledged. Proceeding with implementation.")
# Continue to next workflow step

「計画に緩和策を追加する」の場合

# User provides mitigation approach
# Update plan file with mitigations section
# Re-run quick premortem to verify mitigations address risks

「緩和策の選択肢を調査する」の場合

# Spawn parallel research for each HIGH severity tiger
for tiger in high_severity_tigers:
    # Internal: How has codebase handled this before?
    Task(
        subagent_type="scout",
        prompt=f"""
        Find how this codebase has previously handled: {tiger.category}

        Specifically looking for patterns related to: {tiger.risk}

        Return:
        - File:line references to similar solutions
        - Patterns used
        - Libraries/utilities available
        """
    )

    # External: What are best practices?
    Task(
        subagent_type="oracle",
        prompt=f"""
        Research best practices for: {tiger.risk}

        Context: {tiger.category} in a {tech_stack} codebase

        Return:
        - Recommended approaches (ranked)
        - Library options
        - Common pitfalls to avoid
        """
    )

# Wait for research to complete
# Synthesize options
# Present via AskUserQuestion with 2-4 mitigation options

「特定のリスクについて話し合う」の場合

# Ask which risk to discuss
AskUserQuestion(
    question="Which risk would you like to discuss?",
    header="Risk",
    options=[format_risk_option(r) for r in all_risks[:4]]
)
# Then have conversation about that specific risk

ステップ 5：計画を更新する（緩和策を追加した場合）

ユーザーが緩和策を追加した場合、計画に追記します。

## Risk Mitigations (Pre-Mortem)

### Tigers Addressed:
1. **{risk}** (severity: {severity})
   - Mitigation: {user_or_researched_mitigation}
   - Added to phase: {phase_number}

### Accepted Risks:
1. **{risk}** - Accepted because: {reason}

### Pre-Mortem Run:
- Date: {timestamp}
- Mode: {quick|deep}
- Tigers: {count}
- Elephants: {count}

統合ポイント

create_plan / plan-agent 内

計画の構成が承認された後、ExitPlanMode の前：

# Run quick premortem
/premortem quick

# If HIGH risks found, block until addressed
# If only MEDIUM/LOW, inform and proceed

計画の承認後、実装の前

# Run deep premortem on full plan
/premortem deep thoughts/shared/plans/YYYY-MM-DD-feature.md

# Block until all HIGH tigers addressed

PR レビューワークフロー内

# Run quick premortem on diff scope
/premortem quick

# Inform of any risks found

重大度のしきい値

重大度	ブロック対象？	必要な対応
HIGH	はい	必ず対処するか、明示的に受け入れる
MEDIUM	いいえ	ユーザーに知らせ、対処を推奨する
LOW	いいえ	注意事項として記録する

セッション例

User: /premortem deep thoughts/shared/plans/2026-01-08-api-rate-limiting.md

Claude: Running deep pre-mortem on API rate limiting plan...

[Reviews plan against deep checklist]

Pre-mortem complete. Found 2 tigers, 1 elephant:

**TIGERS:**
1. [HIGH] No circuit breaker for external payment API
   - Category: dependency
   - If payment API is slow/down, requests will pile up

2. [HIGH] No rollback strategy defined
   - Category: integration
   - If rate limiting breaks auth flow, no quick fix path

**ELEPHANTS:**
1. [MEDIUM] Team hasn't used Redis before
   - We're introducing Redis for rate limit counters
   - Learning curve could slow implementation

**PAPER TIGERS:**
1. Database migration size - Only adds one index, <1s migration

[AskUserQuestion presented]

User: Research mitigation options

Claude: Researching mitigations...

[Spawns scout + oracle in parallel]

Found 3 options for circuit breaker:

1. **Use existing retry util** (Recommended)
   - Found at src/utils/retry.ts:45
   - Already handles exponential backoff
   - Just need to add circuit breaker state

2. **Add resilience4j-lite**
   - Popular library for this pattern
   - More features but new dependency

3. **Custom implementation**
   - Full control but more code to maintain

Which approach for the circuit breaker?

User: Option 1 - use existing retry util

Claude: Added to plan:

## Risk Mitigations (Pre-Mortem)

### Tigers Addressed:
1. **No circuit breaker** (HIGH)
   - Mitigation: Extend src/utils/retry.ts with circuit breaker state
   - Added to Phase 1

Shall I also address the rollback strategy tiger?

参考資料

• Shreyas Doshi によるプレモーテム
• Gary Klein のオリジナル研究
• プロジェクトのプレモーテムガイド - Mountain Goat Software