flag-prerequisites

flag-prerequisites

GrowthBook のフィーチャーフラグに対して、フィーチャーレベルの前提条件を追加、削除、または確認します。フィーチャーレベルの前提条件はブール値のゲートです。指定された前提条件フラグがユーザーに対してオフの場合、現在のフラグはすべてのルールをスキップし、そのユーザーに対して defaultValue を返します。

フィーチャーレベルの前提条件は、ブール値フラグのみを対象とします。 前提条件フラグは valueType: "boolean" である必要があります。ゲート条件は常に「前提条件フラグがオン」（{"value": true}）であり、カスタム条件は設定できません。より細かな依存関係（たとえば、文字列フラグの値を条件にする場合や、フラグ全体ではなく単一のルールをゲートする場合）が必要な場合は、flag-targeting に案内してください。

これはルールレベルの前提条件（単一のルールをゲートし、より柔軟な条件をサポートします）とは異なります。フィーチャーレベルの前提条件は、フラグ上のすべてのルールに同時に適用されます。

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

ワークフロー

パス A — 前提条件を追加する

1. フラグの現在の前提条件を取得します：

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

   既存の prerequisites 配列を取得します。以下の PUT は配列全体を置き換えるため、既存の前提条件を上書きしないように現在の内容を取得する必要があります。

2. 前提条件フラグが存在し、ブール値であることを確認します：

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

   valueType を確認します。"boolean" でない場合は中止します：

   「フィーチャーレベルの前提条件は、ブール値フラグのみをサポートしています。<prerequisite-flag-id> は <valueType> フラグです。非ブール値フラグの値を条件にするには、代わりに flag-targeting でルールレベルの前提条件を追加してください。」

3. 新しい前提条件配列を作成します。 既存のエントリに追加します。条件は常に {"value": true} です。ゲートの意味は「前提条件フラグがオン」です：

   [
     { "id": "<existing-prereq-id>", "condition": "{\"value\": true}" },
     { "id": "<new-prereq-id>", "condition": "{\"value\": true}" }
   ]
   

4. ドラフトとして適用します：

   echo '{"prerequisites":[...]}' \
     | gb-call PUT /api/v2/features/<flag-id>/revisions/new/prerequisites -
   

5. flag-publish に引き継ぎます。

パス B — 前提条件を削除する

1. 現在の前提条件を取得します（上記のステップ A-1）。
2. リストを表示し、どの前提条件を削除するか尋ねます。
3. 削除するエントリを除いて、更新後の配列を作成します。
4. フィルタリングした配列を使って、ドラフトとして適用します（上記のステップ A-4）。空の配列 [] を指定すると、すべての前提条件が削除されます。
5. flag-publish に引き継ぎます。

パス C — 現在の前提条件を確認する

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

prerequisites 配列を提示します。各エントリについて、前提条件フラグを取得し、現在評価されている状態と値の型を表示します。必要に応じて flag-graph を使い、依存関係の全体像をたどります。

ガードレール

• ドラフトのバージョンを引き継ぎます。 このセッションで以前の書き込みスキルによりバージョン番号がコンテキストにある場合は、.../revisions/42/prerequisites のように、その番号を明示的に使用し、new は使用しないでください。これにより、すべての変更が同じドラフトにまとめられます。新しく開始する場合は new を使用してください。最新の更新日時を持つオープンドラフトを自動的に作成または再利用します。
• PUT /prerequisites は配列全体を置き換えます。 追加ではありません。追加または変更を行う前に、必ず現在の配列を取得し、既存のすべてのエントリを含めてください。そうしないと、ユーザーが変更するつもりのなかった前提条件まで、気づかないうちに削除してしまいます。
• 前提条件のフラグはブール値でなければなりません。 ユーザーがブール値以外のフラグを前提条件として指定した場合は、処理を中断し、フラグターゲティングに引き継いでください。
• 条件は常に {"value": true} です。 機能レベルの前提条件にカスタム条件を指定したり生成したりしないでください。バックエンドは柔軟に受け付けますが、この制約を意図的に設けています。このゲートは「このフラグがオンである」ことを意味します。ユーザーがより複雑な条件（例：文字列フラグが特定の値と等しい、フラグがライブであればよく、必ずしも true でなくてもよい）を望む場合は、フラグターゲティングのルールレベルの前提条件に引き継いでください。
• 機能レベルとルールレベルの前提条件。 このスキルはフラグ全体にゲートを設定します。ユーザーが単一のルールに限定した前提条件を望む場合は、フラグターゲティングに引き継いでください。
• 循環依存を避けてください。 フラグ A がフラグ B を必要とし、フラグ B がフラグ A を必要とする場合、どちらも評価されません。前提条件を追加する前に、flag-graph を使って既存の依存関係チェーンを確認してください。
• 前提条件のフラグは、同じ GrowthBook プロジェクト内（または組織全体）に存在する必要があります。 SDK の構成によっては、プロジェクトをまたぐ前提条件が正しく解決されないことがあります。
• 前提条件のフラグを削除すると、それに依存するフラグが機能しなくなります。 依存先のフラグでは、前提条件の条件が気づかれないまま常に失敗するようになります。依存関係の確認中に flag-graph を使ってクリーンアップを行う前に、この点をユーザーに伝えてください。

使用するエンドポイント

• GET /api/v2/features/:id — 現在の prerequisites 配列を含むフラグの状態を取得します
• PUT /api/v2/features/:id/revisions/new/prerequisites（本文：{ "prerequisites": [...] }）

引き継ぎ先

• flag-search — ユーザーが前提条件となるフラグの名前を指定した場合に、その ID を検索します
• flag-graph — 依存関係チェーン全体を追跡し、循環依存を検出します
• flag-targeting — ルールレベルの前提条件を追加します（フラグ全体ではなく、単一のルールに限定します）
• flag-publish — ドラフトを公開し、承認が必要な場合（400）とマージの競合（409）に対処します