flag-graph

flag-graph

GrowthBook の機能フラグに関する依存関係を追跡します。フラグの構造を変更（名前変更、アーカイブ、削除）する前に影響範囲を把握したい場合や、フラグ同士の依存関係について全体像を把握したい場合に、このスキルを使用してください。

読み取り専用です。このスキルが書き込みを行うことはありません。

すべての API 呼び出しは、同梱のヘルパー ${CLAUDE_PLUGIN_ROOT}/scripts/gb-call を経由します。GB_API_KEY を環境変数に設定するか、/growthbook:gb-setup によって ~/.config/growthbook/.env に書き込む必要があります。

ワークフロー

1. フラグを取得する

gb-call GET /api/v2/features/<flag-id>

確認する項目：prerequisites（機能レベル）、rules（ルールレベルの前提条件、experiment-ref エントリ、safe-rollout エントリを確認）、holdout。

2. このフラグは何に依存していますか？（前方依存関係）

フラグの prerequisites 配列から、それぞれの前提条件について次を実行します。

gb-call GET /api/v2/features/<prereq-flag-id>

表示する内容：前提条件となるフラグ ID、現在の状態（有効な環境、デフォルト値）、および現在のフラグがそのフラグに対して確認している条件です。前提条件となるフラグにも前提条件がある場合は、もう 1 レベル再帰し、連鎖全体を、終端となる箇所を示して表示します。

rules 配列内のルールレベルの前提条件も確認します。各ルールには、それぞれ独自の prerequisites フィールドを設定できます。これらはルールに紐づく依存関係として表示します。

3. このフラグに依存しているものは何ですか？（逆引き）

GrowthBook には、前提条件を逆引きする API エンドポイントがありません。完全な逆引きには、すべてのフラグをスキャンする必要があります。

gb-call GET /api/v2/feature-keys

次に、すべてのフラグをページネーションで取得し、対象のフラグが prerequisites に含まれているものを探します。

gb-call GET '/api/v2/features?limit=100'
gb-call GET '/api/v2/features?limit=100&offset=100'   # continue until exhausted

返された各フラグについて、prerequisites[*].id と rules[*].prerequisites[*].id が対象のフラグ ID と一致するか確認します。

これは、すべてのフラグを対象とした O(n) スキャンであることをユーザーに警告してください。数百個のフラグがある大規模な組織では、ページネーションを伴う API 呼び出しが何度か必要になる可能性があります。

4. このフラグに紐づく実験はどれですか？

フラグの rules 配列で、実験参照ルール（type: "experiment-ref" のルールにある experimentId フィールド）を確認します。それぞれについて、次を実行します。

gb-call GET /api/v1/experiments/<experiment-id>

実験名、ステータス（実行中／停止／下書き）、およびフラグの id が実験の trackingKey であるかどうかを表示します。

また、linkedFeatures にこのフラグを指定している実験がないかも確認します。

gb-call GET '/api/v1/experiments?trackingKey=<flag-id>'

これにより、慣例に基づいて紐づけられた実験（experiment-launch は trackingKey === flag-id を設定します）を検出できます。手動で紐づけられた実験については、上記の実験参照ルールのスキャンも併せて確認してください。

5. ホールドアウトとの関連付け

フラグに holdout フィールドが設定されている場合は、ホールドアウト ID を記載し、「このフラグはホールドアウト <holdout-id> に参加しています。このフラグを削除したり大幅に変更したりすると、ホールドアウト分析に影響する可能性があります」と警告します。

6. 依存関係レポートを提示する

Dependency graph for `<flag-id>`:

DEPENDS ON (forward):
  → flag-Y (prerequisite, condition: value === true)
      → flag-Z (flag-Y's prerequisite, condition: value === "v2")

DEPENDED ON BY (reverse, scanned <N> flags):
  ← flag-A (feature-level prerequisite)
  ← flag-B (rule-level prerequisite on rule "Beta testers")
  [limitation: reverse lookup scanned all flags; may miss any created after this scan]

EXPERIMENTS:
  exp_abc123 "Checkout experiment" — status: running, trackingKey matches

HOLDOUTS:
  holdout_xyz — flag participates; remove cautiously

SAFE TO DELETE?: <yes / no / caution — explain why>

ガードレール

• 逆引きは全件スキャンです。レート制限に注意してください。 レート制限は 60 rpm です。組織に 600 個を超えるフラグがある場合、スキャンには 10 回以上の API 呼び出しが必要になります。開始前に件数を伝え、続行するか確認してください。
• 逆引きの結果はスキャン実行時点のものです。 スキャン後に作成されたフラグは表示されません。レポートにスキャンのタイムスタンプを記載してください。
• 前提条件の逆引きに使える API はありません。 GET /features?dependsOn=<id> エンドポイントは存在しません。スキャンが唯一の信頼できる方法です。
• 実験の trackingKey スキャンで一般的なケースを検出できます。 experiment-launch は慣例として trackingKey === flag-id を設定します。手動での紐づけ（異なる trackingKey を使用し、linkedFeatures で紐づける方法）は trackingKey のクエリでは検出できない場合があります。そのため、ステップ 4 のルールスキャンで補完します。
• 読み取り専用です。 このスキルが書き込みを行うことはありません。前提条件を変更する場合は flag-prerequisites を使用してください。削除する場合は flag-cleanup を使用してください。
• 循環依存の検出。 前方依存関係をたどる途中で、開始フラグを参照するフラグが見つかった場合は、循環依存の警告として表示してください。これは、そのフラグを完全に評価できないことを意味します。

使用するエンドポイント

• GET /api/v2/features/:id — フラグとその依存関係を取得します
• GET /api/v2/feature-keys — 逆引き用のフラグ ID の全一覧を取得します
• GET /api/v2/features（ページネーション、limit/offset）— 逆引き用にフラグをすべてスキャンします
• GET /api/v1/experiments/:id — 関連付けられた実験の詳細を取得します
• GET /api/v1/experiments?trackingKey=<flag-id> — 規約に基づいて関連付けられた実験を検索します

引き継ぎ先

• flag-prerequisites — フィーチャーレベルの前提条件を追加、削除、または変更する場合
• flag-cleanup — 影響範囲を確認した後、フラグをアーカイブまたは削除する場合
• experiment-stop — 関連付けられた実験が実行中で、フラグを削除する前に停止する必要がある場合
• flag-search — 条件に一致するすべてのフラグを検索する場合（単一フラグの依存関係トレースより広範です）