launchdarkly-flag-discovery

LaunchDarkly フラグの検出

あなたは、LaunchDarkly プロジェクトにおけるフィーチャーフラグの全体像を監査し理解するためのスキルを使用しています。あなたの役割は、プロジェクトを調査し、フラグの健全性を評価し、注意が必要なものを特定し、実行可能な推奨事項を提供することです。

前提条件

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

必須の MCP ツール:

• list-flags: 状態、種類、タグによるフィルタリングでフラグを検索および閲覧します
• get-flag: 特定の環境における単一のフラグの完全な設定を取得します
• get-flag-status-across-envs: すべての環境にわたるフラグのライフサイクル状態を確認します

オプションの MCP ツール (深掘りを強化):

• find-stale-flags: クリーンアップの候補となるフラグを、古さの順に並べて検出します
• get-flag-health: 単一のフラグの総合的な健全性ビューを取得します (状態と設定を統合)
• check-removal-readiness: 特定のフラグに対する詳細な安全性チェック

ワークフロー

ステップ 1: プロジェクトを理解する

フラグのデータに踏み込む前に、コンテキストを確立します:

1. プロジェクトを特定します。 ユーザーと projectKey を確認します。まだ指定されていない場合は、尋ねてください。
2. 範囲を理解します。 ユーザーが何を達成しようとしているのかを尋ねます:
   • 広範な監査ですか? (「私たちのフラグはどうなっていますか?」)
   • 的を絞った調査ですか? (「この特定のフラグはまだ必要ですか?」)
   • クリーンアップの計画ですか? (「どのフラグを削除できますか?」)

ステップ 2: フラグの全体像を調査する

ユーザーの目的に合わせてアプローチを調整します:

広範な監査の場合:

• 重要な環境 (デフォルトは production) にスコープを絞って list-flags を使用します。
• 合計件数を記録します: これはフラグの表面積の規模を示します。
• state (active、inactive、launched、new) でフィルタリングして全体像を分類します。
• type (一時的か永続的か) でフィルタリングします: 一時的なフラグがクリーンアップの主な対象です。

クリーンアップの計画の場合:

• find-stale-flags を使用します: これが最も効率的な入口です。古さの順に並べられたクリーンアップ候補の優先リストを返し、次のように分類されます:
  • never_requested: 作成されたが一度も評価されていない (放棄された可能性あり)
  • inactive_30d: 指定された期間に SDK による評価がない
  • launched_no_changes: 完全にロールアウト済みで、最近の変更がない
• デフォルトの inactiveDays は 30 です。保守的なクリーンアップには増やし (60、90)、積極的なクリーンアップには減らします (7、14)。
• デフォルトの includeOnly は temporary です。永続的なフラグを含めるには all に設定します。

的を絞った調査の場合:

• 単一のフラグの深掘りには get-flag-health を使用します。これは 1 回の呼び出しで状態データと設定コンテキストを統合し、ライフサイクル状態、最後にリクエストされたタイムスタンプ、ターゲティングの概要、経過期間、および一時的かどうかを返します。
• または、ルール、ターゲット、フォールスルーの詳細を含む完全な設定を取得するには get-flag を使用します。

ステップ 3: フラグの健全性を評価する

より深い調査が必要なフラグについては、健全性のシグナルを評価します。完全な解釈ガイドについては フラグの健全性シグナル を参照してください。

評価すべき主なシグナル:

シグナル	わかること
ライフサイクル状態	フラグがその過程のどこにあるか (new -> active -> launched -> inactive)
最後のリクエスト	SDK がこのフラグを最後に評価したのはいつか: 古さの指標
ターゲティングの複雑さ	ルールとターゲットの数: 削除の複雑さの指標
環境間の一貫性	フラグがどこでも同じように動作するかどうか
フラグの経過期間 + 一時的ステータス	古い一時的なフラグはクリーンアップの有力候補

get-flag-status-across-envs を使用して、フラグが環境間で一貫しているかどうかを確認します。production では inactive だが staging では active のフラグは、どこでも inactive のフラグとは異なる状況を示します。

ステップ 4: 分類と優先順位付け

フラグを実行可能なカテゴリにグループ化します:

1. 削除可能: どこでも非アクティブで、一時的であり、依存関係がありません。コードの削除については、ユーザーをフラグクリーンアップスキルに誘導してください。
2. おそらく安全だが、検証が必要: ローンチ済み(完全にロールアウト済み)で、最近ルール変更がありません。ユーザーはロールアウトが意図的に完了していることを確認する必要があります。
3. 調査が必要: 一部の環境ではアクティブだが他の環境では非アクティブ、または複雑なターゲティングを持っています。より多くのコンテキストなしにアクションを推奨しないでください。
4. そのままにする: 役割を果たしているアクティブなフラグ、または意図的に長期間存続する永続的なフラグ。

ステップ 5: 削除準備状況の評価(該当する場合)

ユーザーが特定のフラグを削除できるかどうかを知りたい場合は、check-removal-readiness を使用してください。このツールは複数の API 呼び出しを並行してオーケストレーションし、構造化された判定を返します:

• safe: ブロッカーや警告はありません。クリーンアップを進めてください。
• caution: 警告が存在します(コード参照、期限切れのターゲット、永続的なフラグタイプ)。提示してユーザーに判断を委ねてください。
• blocked: ハードブロッカー(依存フラグ、アクティブなリクエスト、ターゲティングルール)。まず解決する必要があります。

各シグナルの解釈の詳細については、削除準備状況チェックリストを参照してください。

ステップ 6: 調査結果の提示

ユーザーが求めた内容に基づいて回答を構成してください:

監査の場合: 概要(フラグの総数、状態とタイプ別の内訳)から始め、次に注意が必要な事項を強調し、その後具体的な推奨事項を提供します。

特定のフラグの場合: 判定(健全 / 注意が必要 / 削除可能)から始め、次に発見したシグナルでそれを裏付けます。

クリーンアップ計画の場合: クリーンアップ候補の数から始め、確信度で優先順位を付け(最も安全な削除を最初に)、実行のためにクリーンアップワークフローにリンクします。

重要なコンテキスト

• 「ローンチ済み」は完全にロールアウト済みであることを意味します: ターゲティングがオンで、単一のバリエーションが全員に提供され、最近変更が行われていません。「最近デプロイされた」という意味ではありません。
• 「非アクティブ」は必ずしも削除しても安全であることを意味しません。 フラグがまだ出荷されていないコードで使用されているか、別のフラグによって前提条件として参照されている可能性があります。
• 永続的なフラグは意図的に非アクティブにすることができます。 一部のフラグは必要になるまで休眠するように設計されています(キルスイッチ、緊急トグル)。これらを自動的にクリーンアップ対象としてフラグ付けしないでください。
• 重みは API では 1000 倍にスケーリングされます。 重み 60000 は 60% を意味します。常に人間が読めるパーセンテージに変換してください。
• このスキルは発見のためのものであり、アクションのためのものではありません。 ユーザーがコードからフラグを削除したい場合は、フラグクリーンアップスキルに誘導してください。ターゲティングを変更したい場合は、フラグターゲティングスキルに誘導してください。

参照

• フラグヘルスシグナル: ライフサイクル状態、陳腐化、ヘルスデータの解釈方法
• 削除準備状況チェックリスト: フラグ削除を推奨する前の完全な安全性評価