Patch Readiness

Purpose

「急いで直したら本番が壊れた」を防ぐ。 パッチ適用前に安全装置（テスト・バックアップ・ロールバック）が揃っているかを確認し、 適用可否と適用タイミングを判断する材料を提供する。

Use When

• バグ修正・セキュリティパッチを本番環境に適用する前
• ホットフィックスやロールバックが必要な緊急対応の前
• 「今すぐ直す」か「次のリリースに含める」かを判断したい場合
• 依存ライブラリのバージョンアップを検討している場合

Inputs

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

• パッチ内容: 何を修正するか（差分の概要）
• 緊急度: なぜ今適用が必要か（または必要と判断しているか）
• 影響範囲: パッチが波及する機能・ファイル・DB
• 現在の本番状態: 現在のデプロイバージョン・稼働状況
• ロールバック手段: 直前のバージョンに戻す方法

Output Contract

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

1. 論点: このパッチを今適用できるかを左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. 準備状況チェック: 各チェック項目の状態
4. 含意: 適用可否が示す運用・リスク管理上の意味
5. 改善案: 不足している準備を最短で揃えるためのステップ
6. 代替案: 今すぐ適用できない場合の暫定対処
7. 判断材料: 「今すぐ適用 / 準備後に適用 / 次リリースへ延期」を選ぶための情報

準備状況チェック フォーマット

Review Lens

• 目的妥当性: チェック項目が本番適用リスクに対して適切か
• 範囲の過不足: パッチが単一目的に絞られているか（複数修正が混在していないか）
• 中長期リスク: 今回の暫定対処が技術的負債を生まないか
• LAB全体との整合性: Supabase / Vercel / Stripe の依存環境が考慮されているか
• 非エンジニア理解可能性: 適用リスクと準備状況を非技術者に説明できるか
• 他LLM移植耐性: チェック基準が Claude 固有の解釈に依存していないか

Instructions

1. パッチの目的を「何を / なぜ / どのファイルで / どう変更するか」で整理する
2. 各チェック項目を OK / 注意 / NG で評価する
3. NG が1つでもあれば「ブロック」を宣言し、未準備の項目を具体的に列挙する
4. 「注意」のみの場合は「条件付き適用可」とし、条件を明示する
5. 全項目 OK の場合のみ「適用可」を宣言する
6. 適用後の確認手順（動作確認・監視項目）を提示する
7. 最終判断は人間に委ねる

Guardrails

• 「急いでいるから」でチェックを省略しない
• テストなしの本番適用は必ず「注意」以上にする
• DB の不可逆マイグレーションは必ず「NG」候補として扱う
• ロールバック手順が「不明」の場合は必ず指摘する
• 複数の修正が混在するパッチは単一目的に分割することを推奨する

LAB Cross-Check

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

Handoff Notes

• 要件: パッチの適用仕様（変更差分・適用手順）
• 成功条件: 適用後に動作確認が完了し、エラーログが増加していない状態
• 失敗条件: 適用後にエラー率が上昇 / 機能が動作不能になった状態
• 実行範囲: 適用してよいファイル・環境（ステージング / 本番）
• 影響範囲: パッチが波及する機能・DB・外部サービス
• ロールバック方針: 失敗時の切り戻し手順（コマンド含む）
• コスト比較: 今すぐ適用するコスト vs 延期して問題が拡大するコスト

Further Reading

• change-impact-scan skill — 影響範囲の詳細洗い出し
• rollback-plan skill — ロールバック方針の詳細設計
• test-scope-definition skill — テストスコープの定義
• implementation-gate skill — 実装着手前のゲートチェック
• docs/CONTEXT.md — 技術スタック・デプロイ環境