launchdarkly-flag-cleanup

LaunchDarkly フラグのクリーンアップ

あなたは、本番環境の動作を維持しながらコードベースからフィーチャーフラグを安全に削除するためのスキルを使用しています。あなたの役割は、コードベースを調査してフラグがどのように使用されているかを理解し、LaunchDarkly に問い合わせて正しいフォワード値を判断し、フラグのコードをクリーンに削除し、その結果を検証することです。

クリーンアップするフラグをまだ特定していない場合は、まずフラグ探索スキルを使用して全体像を調査し、候補を見つけてください。

前提条件

このスキルを使用するには、リモートでホストされている LaunchDarkly MCP サーバーが環境内に設定されている必要があります。

必須の MCP ツール:

• check-removal-readiness: 詳細な安全性チェック (フラグ設定、クロス環境のステータス、依存関係、コード参照、有効期限切れのターゲットを並行してオーケストレーションします)
• get-flag: 特定の環境のフラグ設定を取得します

オプションの MCP ツール:

• archive-flag: コード削除後に LaunchDarkly でフラグをアーカイブします
• delete-flag: フラグを完全に削除します (取り消し不能です。アーカイブを優先してください)

基本原則

1. 安全性を最優先: 常に現在の本番環境の動作を維持します。
2. LaunchDarkly を信頼できる情報源とする: フォワード値を推測しないでください。実際の設定に問い合わせてください。
3. 規約に従う: 既存のコードスタイルと構造を尊重します。
4. 最小限の変更: フラグに関連するコードのみを削除します。無関係なリファクタリングは行いません。

ワークフロー

ステップ 1: コードベースを調査する

LaunchDarkly に触れたりコードを削除したりする前に、このフラグがコードベースでどのように使用されているかを理解してください。

1. フラグキーへのすべての参照を見つけます。 コードベース全体でフラグキーの文字列 (例: new-checkout-flow) を検索します。以下を確認してください:

   • 直接的な SDK 評価呼び出し (variation()、boolVariation()、useFlags() など)
   • キーを参照する定数や列挙型
   • SDK を抽象化するラッパーやサービスのパターン
   • 設定ファイル、テスト、ドキュメント
   • 言語別のパターンの完全な一覧については、SDK パターンを参照してください

2. 分岐を理解します。 各参照について、以下を特定してください:

   • フラグが true (またはバリエーション A) のときに実行されるコードは何か?
   • フラグが false (またはバリエーション B) のときに実行されるコードは何か?
   • 副作用、早期リターン、ネストされた条件はあるか?

3. 範囲を把握します。 このフラグはいくつのファイル、コンポーネント、モジュールに影響しますか? 1 つの if ブロックで使用されるフラグは、複数のレイヤーを貫通するフラグよりも単純です。

ステップ 2: 削除準備状況チェックを実行する

check-removal-readiness を使用して、詳細な安全性評価を取得します。この単一のツール呼び出しは、複数のチェックを並行してオーケストレーションします:

• フラグの設定とターゲティングの状態
• クロス環境のステータス
• 依存するフラグ (前提条件)
• 有効期限切れのターゲット
• コード参照の統計

このツールは準備状況の判定を返します:

safe: ブロッカーも警告もありません。削除を進めてください。

caution: ハードブロッカーはありませんが警告が存在します (例: 他のリポジトリ内のコード参照、有効期限切れのターゲットが予定されている、フラグが永続としてマークされている)。警告を提示し、ユーザーに判断を委ねてください。

blocked: ハードブロッカーが安全な削除を妨げています (例: 依存するフラグ、リクエストを活発に受信している、ターゲティングがオンでアクティブなルールがある)。ブロッカーを提示してください: ユーザーが先にそれらを解決する必要があります。

ステップ 3: フォワード値を判断する

get-flag を使用して、各重要な環境のフラグ設定を取得します。フォワード値とは、コード内でフラグを置き換えるバリエーションです。

シナリオ	フォワード値
すべての重要な環境が ON、同じフォールスルー、ルール/ターゲットなし	fallthrough.variation を使用します
すべての重要な環境が OFF、同じ offVariation	offVariation を使用します
重要な環境で ON/OFF の状態が異なる	安全ではありません: 停止してユーザーに通知してください
重要な環境で異なるバリエーションを配信している	安全ではありません: 停止してユーザーに通知してください

ステップ 4: クリーンアップ計画の提示

コードを変更する前に、ユーザーに概要を提示し、確認を待ちます:

1. フォワード値 — どのバリエーションをハードコードするか、その理由 (フラグの現在の状態に基づく)。
2. 検出されたすべてのコード参照 — ステップ 1 で得たファイルパスと行番号。
3. 変更予定 — 各参照について、何を削除し、何を残すかを記述します。
4. 削除準備の判定 — check-removal-readiness の結果 (安全、注意、またはブロック) と警告があればその内容。
5. LaunchDarkly の操作 — コード変更の完了後にフラグをアーカイブすることを確認します。

ユーザーが明示的に確認するまで、コード変更を進めないでください。

ステップ 5: コードからフラグを削除する

ここで、ステップ 1 で把握した内容を使って削除を実行します。

1. フラグの評価をフォワード値に置き換えます。

   • フォワード値に一致するコード分岐は保持する
   • デッド分岐は完全に削除する
   • フラグの値が変数に代入されていた場合は、その変数をリテラル値に置き換えるか、インライン化する

2. デッドコードをクリーンアップします。

   • そのフラグのためだけに存在していたインポート、定数、型定義を削除する
   • デッド分岐のためだけに存在していた関数、コンポーネント、ファイルを削除する
   • 孤立したエクスポート、フック、ヘルパー、スタイル、テストファイルがないか確認する
   • リポジトリで未使用エクスポートのツール (Knip、ts-prune、lint ルール) を使用している場合は、実行してフラグ関連の孤立項目を削除する

3. 過剰にクリーンアップしないでください。

   • フラグに直接関連するコードのみを削除する
   • 周辺のコードをリファクタリング、最適化、「改善」しない
   • 手を付けていないコードのフォーマットやスタイルを変更しない

変換例 (ブール値フラグ、フォワード値 = true):

// Before
const showNewCheckout = await ldClient.variation('new-checkout-flow', user, false);
if (showNewCheckout) {
  return renderNewCheckout();
} else {
  return renderOldCheckout();
}

// After
return renderNewCheckout();

ステップ 6: プルリクエストを作成する

references/pr-template.md のテンプレートを使用して、構造化された PR の説明を作成します。PR では以下を明確に伝える必要があります:

• どのフラグを削除したか、その理由
• フォワード値は何か、それがなぜ正しいか
• 削除準備の評価結果 (check-removal-readiness より)
• どのコードを削除し、どの動作が保持されるか
• 他のリポジトリがまだこのフラグを参照しているかどうか

ステップ 7: 検証する

作業完了と見なす前に:

1. コードがコンパイルおよび lint を通過すること。 プロジェクトのビルドと lint のステップを実行します。
2. テストが通過すること。 フラグがテストで使用されていた場合は、ハードコードされた動作を反映するようにテストを更新する必要があります。
3. 残存する参照がないこと。 フラグキーについてコードベースをもう一度検索し、見落としがないことを確認します。
4. PR が完全であること。 説明に、削除準備の評価、フォワード値の根拠、および必要なクロスリポジトリの調整が含まれていることを確認します。

エッジケース

状況	対応
LaunchDarkly でフラグが見つからない	ユーザーに通知し、キーのタイプミスを確認する
フラグがすでにアーカイブ済み	コードのクリーンアップがまだ必要か確認する (フラグは LD から消えているが、コードがまだ参照している可能性がある)
コードベースに複数の SDK パターンがある	すべてのパターンを検索する: variation()、boolVariation()、variationDetail()、allFlags()、useFlags()、および任意のラッパー
動的なフラグキー (flag-${id})	自動削除が不完全になる可能性があると警告する: 手動でのレビューが必要
コードと LD でデフォルト値が異なる	PR の説明で不整合として指摘する
削除後に孤立したエクスポート/ファイルが残る	未使用エクスポートのチェックを実行し、デッドファイルを削除する

やってはいけないこと

• フラグのクリーンアップに関係のないコードを変更しないでください。
• フラグの削除を超えてリファクタリングや最適化をしないでください。
• まだ積極的にロールアウト中のフラグを削除しないでください。
• フォワード値を推測しないでください: 常に LaunchDarkly に問い合わせてください。

クリーンアップ後

PR がマージされてデプロイされたら:

1. LaunchDarkly でフラグをアーカイブします (archive-flag を使用)。アーカイブは可逆ですが、削除は不可逆です。常に先にアーカイブしてください。
2. 他のチームに通知します — check-removal-readiness が他のリポジトリでのコード参照を報告した場合。
3. フラグに保留中のターゲティング変更があった場合、 それらは無視してかまいません: フラグは削除されるからです。

参考資料

• PR テンプレート: フラグ削除のための構造化された PR 説明
• SDK パターン: 言語/フレームワーク別のフラグ評価パターン
• フラグ検出: このスキルを使用する前にクリーンアップ候補を探す
• フラグターゲティング: 削除ではなくターゲティングを変更する必要がある場合