thinkyou0714 Purpose
「失敗した後に何をすればいいかわからない」を防ぐ。 実装着手前にロールバック手順を設計し、失敗時の混乱と復旧コストを最小化する。
Use When
- 実装・デプロイ・DB マイグレーションの前
- 「失敗したらどうするか」が未定義のままタスクが進んでいる場合
- ホットフィックス・緊急パッチの前
- 新しい依存関係（ライブラリ・外部サービス）を導入する前
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 実装・変更内容: 何をするか（コード / DB / 設定 / インフラ）
- 変更範囲: 変更するファイル・テーブル・API・環境変数
- 現在の状態: 変更前の状態（ブランチ / DB スキーマバージョン / デプロイバージョン）
- 外部依存: 変更に伴う外部サービス・API の変更（Stripe / Supabase / Vercel 等）
- 許容ダウンタイム: ロールバック中に受け入れられる最大停止時間
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: このロールバック設計を左右する核心的な判断軸
- 根拠: その論点をそう判断した理由
- ロールバック手順: 段階別の具体的な手順
- 含意: ロールバック可能性の高さ/低さが示す設計上のリスク
- 改善案: ロールバックコストを下げるための変更設計上の工夫
- 代替案: 完全ロールバックが不可能な場合の部分ロールバック・補償手順
- 判断材料: 「このロールバック計画で進む / 計画を強化する / 変更設計を見直す」を選ぶための情報
ロールバック手順 フォーマット
| ステップ | 操作内容 | 実行者 | 確認方法 | 所要時間概算 |
|---|---|---|---|---|
| 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
- 変更を「コード / DB / 設定 / 外部サービス」に分類する
- 各分類ごとにロールバック方法を具体的に記述する（コマンド・操作を含む）
- 手順に依存関係がある場合は実行順序を明示する
- 不可逆な操作を特定し、補償手順（データ修正・ユーザー通知等）を設計する
- ロールバック後の確認手順（動作確認コマンド・監視確認）を含める
- 所要時間の概算を付ける（ダウンタイム許容値と照合するため）
- 最終判断は人間に委ねる
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-gateskill — 実装着手前のゲートチェック（ロールバック方針を要求）patch-readinessskill — パッチ適用前のロールバック準備確認change-impact-scanskill — 影響範囲の洗い出し（ロールバック対象の特定）lab-data-auth-ops/rollback-readinessskill — DB ロールバックの詳細確認- docs/CONTEXT.md — Vercel / Supabase のデプロイ環境