Change Impact Scan

Purpose

「直したら別の箇所が壊れた」を防ぐ。 変更の実行範囲と影響範囲を分けて整理し、波及リスクのある箇所を実装前に明示する。

Use When

• 既存コード・DB・API の変更を行う前
• リファクタリングや型変更など、波及が広い変更の前
• 「どこを直せばいいか」がわかった後、「どこに影響するか」を確認したい場合
• implementation-gate でゲートチェック後、影響範囲の詳細が必要な場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 変更内容: 何を変更するか（ファイル・関数・型・DB カラム等）
• 変更理由: なぜその変更が必要か
• 現在の利用箇所: 変更対象が使われている場所の既知情報
• 技術スタック: 言語・フレームワーク・ORM・テストツール
• テスト状況: 既存テストのカバレッジ・実行方法

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この変更の影響範囲を左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. 影響範囲マップ: 変更が波及する箇所の一覧
4. 含意: 影響範囲の広さが示す設計上の意味
5. 改善案: 影響範囲を最小化するための変更戦略
6. 代替案: 影響範囲を避けつつ目的を達成する別アプローチ
7. 判断材料: 「実装に進む / 段階的に進む / 設計を見直す」を選ぶための情報

影響範囲マップ フォーマット

種別:

• 直接変更: 実装の主要対象
• 依存: 変更対象を import / call している箇所
• 副作用: 変更によって間接的に影響を受ける箇所（型推論・テスト等）

Review Lens

• 目的妥当性: 影響範囲の洗い出し基準が変更リスクに対して適切か
• 範囲の過不足: 依存が深いところまで追えているか（過剰に広くなっていないか）
• 中長期リスク: 今後の機能追加で影響が拡大しそうな箇所を見落としていないか
• LAB全体との整合性: Supabase スキーマ・NextAuth・Stripe との依存が含まれているか
• 非エンジニア理解可能性: 重篤度と対処方針が非技術者に説明できるか
• 他LLM移植耐性: 影響種別の定義が Claude 固有の解釈に依存していないか

Instructions

1. 変更対象を「ファイル / 関数 / 型 / DB カラム / API レスポンス」に分類する
2. 各変更対象について依存元（呼び出し元・参照元）を列挙する
3. 依存元の依存元（2次波及）まで追う（3次以降は概要のみ）
4. 重篤度を「高（動作不能）/ 中（劣化・警告）/ 低（影響軽微）」で評価する
5. 各影響箇所に対処方針（修正 / テスト追加 / 監視 / 無視可）を付ける
6. 「ここは変更前に必ずテストを書くべき」な箇所を明示する
7. 最終判断（実装に進む / 段階的に進む / 設計を見直す）は人間に委ねる

Guardrails

• 「おそらく影響なし」で済ませず、不明な場合は「要確認」として残す
• DB のカラム変更・型変更は必ず高重篤度候補として扱う
• テストのない箇所への影響は必ず明示する
• 影響範囲を縮小するために変更内容を歪めない
• 破壊的変更（existing API の削除・rename）は必ず「高」重篤度にする

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

• 要件: 変更内容と影響対処まで含めた実装仕様
• 成功条件: 影響範囲の対処が完了し、既存テストが全通過している状態
• 失敗条件: 依存箇所で型エラー・テスト失敗・実行時エラーが発生した状態
• 実行範囲: 変更対象 + 影響対処が必要なファイル一覧
• 影響範囲: 変更が波及する箇所と重篤度のマップ
• ロールバック方針: 影響対処に失敗した場合の段階的な切り戻し手順
• コスト比較: 影響対処コスト vs 後から問題発覚した場合のコスト

Further Reading

• implementation-gate skill — 実装着手前のゲートチェック
• patch-readiness skill — パッチ適用前の準備確認
• test-scope-definition skill — テストスコープの定義
• rollback-plan skill — ロールバック方針の詳細設計
• docs/DECISIONS.md — 設計決定記録（ADR）