Rollback plan

Purpose

「失敗した後に何をすればいいかわからない」を防ぐ。 実装着手前にロールバック手順を設計し、失敗時の混乱と復旧コストを最小化する。

Use When

• 実装・デプロイ・DB マイグレーションの前
• 「失敗したらどうするか」が未定義のままタスクが進んでいる場合
• ホットフィックス・緊急パッチの前
• 新しい依存関係（ライブラリ・外部サービス）を導入する前

Inputs

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

• 実装・変更内容: 何をするか（コード / DB / 設定 / インフラ）
• 変更範囲: 変更するファイル・テーブル・API・環境変数
• 現在の状態: 変更前の状態（ブランチ / DB スキーマバージョン / デプロイバージョン）
• 外部依存: 変更に伴う外部サービス・API の変更（Stripe / Supabase / Vercel 等）
• 許容ダウンタイム: ロールバック中に受け入れられる最大停止時間

Output Contract

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

1. 論点: このロールバック設計を左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. ロールバック手順: 段階別の具体的な手順
4. 含意: ロールバック可能性の高さ/低さが示す設計上のリスク
5. 改善案: ロールバックコストを下げるための変更設計上の工夫
6. 代替案: 完全ロールバックが不可能な場合の部分ロールバック・補償手順
7. 判断材料: 「このロールバック計画で進む / 計画を強化する / 変更設計を見直す」を選ぶための情報

ロールバック手順 フォーマット

ステップ	操作内容	実行者	確認方法	所要時間概算
1	（例: git revert / feature flag OFF）	AI / 人間	（確認コマンド・URL）	（分）
2	（例: DB マイグレーションのロールバック）	AI / 人間
3	（例: 環境変数の切り戻し）	AI / 人間
4	（例: 動作確認）	AI / 人間

ロールバック不可能な操作（例: 不可逆 DB 変更、外部サービスへの通知）は「補償手順」として別途記載する。

Review Lens

• 目的妥当性: ロールバック手順が実際の変更に対して実行可能か
• 範囲の過不足: 外部サービス（Stripe / Supabase）の状態変更が含まれているか
• 中長期リスク: ロールバック後に一時的に整合性が失われる期間がないか
• LAB全体との整合性: Vercel / Supabase の具体的なロールバック方法が含まれているか
• 非エンジニア理解可能性: ロールバック手順を非技術者が実行できるか
• 他LLM移植耐性: 手順が Claude 固有の解釈に依存していないか

Instructions

1. 変更を「コード / DB / 設定 / 外部サービス」に分類する
2. 各分類ごとにロールバック方法を具体的に記述する（コマンド・操作を含む）
3. 手順に依存関係がある場合は実行順序を明示する
4. 不可逆な操作を特定し、補償手順（データ修正・ユーザー通知等）を設計する
5. ロールバック後の確認手順（動作確認コマンド・監視確認）を含める
6. 所要時間の概算を付ける（ダウンタイム許容値と照合するため）
7. 最終判断は人間に委ねる

Guardrails

• 「git revert で戻せる」だけで終わらせない。DB・設定・外部サービスを含める
• ロールバック後に整合性が崩れる箇所（例: 支払い記録と DB の状態の不一致）を省略しない
• 「おそらくロールバック可能」で不可逆操作を無視しない
• ロールバック手順に手動操作が含まれる場合、その人間への通知方法を明示する
• ロールバック計画が実行不可能な変更設計を推奨しない

LAB Cross-Check

観点	状態	備考
自動化フロー	—	n8n / Webhook フローのロールバックが含まれているか
データ / 認証 / ログ	—	Supabase スキーマ・RLS のロールバックが含まれているか
実装 / 運用フロー	—	Vercel デプロイのロールバック（前バージョン revert）が含まれているか
非エンジニア理解可能性	—	ロールバック手順を説明できる言葉か
会員共有 / 再利用耐性	—	手順フォーマットが他変更にも転用できるか
他LLM移植耐性	—	手順が Claude 固有に依存していないか

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

Handoff Notes

• 要件: ロールバック手順の定義（ステップ・実行者・確認方法）
• 成功条件: ロールバック後に変更前の状態が確認できている
• 失敗条件: ロールバック後もエラーが継続している / DB 整合性が崩れている
• 実行範囲: ロールバックを実行してよいファイル・DB・環境
• 影響範囲: ロールバックが波及する外部サービス・ユーザーへの影響
• ロールバック方針: （このスキル自体がロールバック方針の出力）
• コスト比較: ロールバック計画設計コスト vs ロールバック手順未定義のまま失敗するコスト

Further Reading

• implementation-gate skill — 実装着手前のゲートチェック（ロールバック方針を要求）
• patch-readiness skill — パッチ適用前のロールバック準備確認
• change-impact-scan skill — 影響範囲の洗い出し（ロールバック対象の特定）
• lab-data-auth-ops/rollback-readiness skill — DB ロールバックの詳細確認
• docs/CONTEXT.md — Vercel / Supabase のデプロイ環境