flag-rules

flag-rules

GrowthBook の機能フラグに対するルール操作のエントリーポイントです。このスキルを使用して、ルールの確認、削除、並べ替えを行います。ルールの作成や編集では、このスキルが適切なルールタイプを特定し、専用スキルに引き継ぎます。

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

ルールタイプのリファレンス

タイプ	動作	スキル
force / rollout	特定の値を返します。任意で、ランダムに選んだユーザーの一定割合を対象にできます。rollout は force と同じタイプですが、coverage < 1 であり、hashAttribute が必須です。有効なカバレッジに応じて、サーバーが両者を自動的に切り替えます。	flag-targeting
experiment-ref	リンクされた実験を使って A/B テストを実施します	flag-experiment

ルールは上から順に評価され、最初に一致したルールが適用されます。順序が重要です。

ワークフロー

パス A — フラグのルールを一覧表示する

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

rules 配列を評価順に、番号付きリストで表示します。

Rules on `<flag-id>` (top-to-bottom evaluation):
  1. [force]          all environments              value="true"    "Beta testers" (saved group)
  2. [rollout]        production                    coverage=10%    hash=id
  3. [experiment-ref] production, staging           → exp_abc123    "Checkout experiment"
  4. [force]          staging                       value="false"   "Kill switch"

各ルールについて、番号、タイプ、スコープ（allEnvironments または特定の環境）、有効状態、ルールの効果の概要（1 行）、参照用のルール ID（UUID）を表示します。

パス B — ルールの作成・編集に適したスキルに引き継ぐ

ユーザーの目的を尋ねて、適切なスキルに引き継ぎます。

ユーザーの意図	引き継ぎ先
「条件 Y に一致するユーザーに X を返す」	flag-targeting
「ユーザーの N% に段階的に展開する」	flag-targeting
「A/B テストを実施する」（実験はすでに存在する）	flag-experiment
「A/B テストを実施する」（最初から開始する）	experiment-launch — 実験を作成し、フラグを最初から最後まで再利用または作成します
「午前 9 時にオン、午後 5 時にオフにする」	flag-schedule
「トラフィックを 5% から 100% へ段階的に増やす」	flag-ramp
「ガードレール指標を監視しながら段階的にリリースする」	flag-monitoring
「機能 Y が有効な場合に限る」（フラグ全体）	flag-prerequisites
「機能 Y が有効な場合に限る」（1 つのルール）	flag-targeting

ユーザーの説明が曖昧な場合は、引き継ぎ先を決める前に確認の質問を 1 つします。

パス C — ルールを削除する

番号を指定してもらえるよう、番号付きリスト（パス A）を表示します。次のように確認します。

「ルール <N>（<type>、<scope>、<summary>）を削除しますか？これはドラフトに追加され、公開後にのみ反映されます。」

gb-call DELETE /api/v2/features/<flag-id>/revisions/new/rules/<rule-id>

返された version を取得します。flag-publish に引き継ぎます。

safe-rollout の削除： ルールがまだドラフトで、ロールアウトが開始されていない場合、サーバーは SafeRollout エンティティをクリーンアップします。ロールアウトがすでに開始されている場合、SafeRollout エンティティは保持され（データ損失なし）、フラグからルールが削除されます。

experiment-ref の削除： リンクされた実験には影響しません。フラグ上のルールを削除しても、実験は停止も変更もされません。

パス D — ルールを並べ替える

現在の順序（パス A）を表示します。新しい順序を番号で指定するか、希望する並びを説明してもらいます。

echo '{"ruleIds":["<id-1>","<id-2>","<id-3>"]}' \
  | gb-call POST /api/v2/features/<flag-id>/revisions/new/rules/reorder -

すべてのルール ID を含む完全な順序配列を指定します。これは一部の入れ替えではなく、順序全体を置き換えます。返された version を取得します。flag-publish に引き継ぎます。

評価は上から順に行われ、最初に一致したルールが適用されることをユーザーに伝えます。リストの上位にあるルールほど優先されます。

ガードレール

• ルールは順番に評価されます。配置が重要です。（条件なしで50％ロールアウトするなどの）広範なルールを先に置くと、その下にあるより具体的なルールより先に一致します。ユーザーがルールを追加または並べ替えた場合は、この点を伝えてください。
• ルール ID は文字列の UUID（fr_...）であり、位置番号ではありません。 編集／削除／並べ替えのエンドポイントを呼び出す前に、必ずrules配列から UUID を特定してください。
• 並べ替えには配列全体が必要です。 並べ替えのペイロードでルール ID が欠けていると、エラーが発生するか、ルールが失われます。現在のrules配列を取得し、メモリ上で並べ替えた後、すべての ID を送信してください。
• ドラフトバージョンの引き継ぎ。 このセッションで以前に実行した書き込みスキルからバージョン番号をコンテキストに引き継いでいる場合は、newではなく、その番号を明示的に使用してください。新たに開始する場合は、newを使用してください。
• version=newが標準的なドラフトのパターンです。 先に手動で/revisionsへ POST しないでください。newの特殊な動作により、ドラフトがアトミックに作成または再利用されます。
• experiment-ref ルールは、ここでのみ削除できます。 experiment-ref ルールのターゲティング条件またはスコープを編集するには、flag-targeting を使用してください。リンクされた実験を変更する場合は、ユーザーに警告して flag-experiment を使用してください。

使用するエンドポイント

• GET /api/v2/features/:id — 現在のルールとフラグの状態を一覧表示します
• DELETE /api/v2/features/:id/revisions/new/rules/:ruleId — ルールを削除します
• POST /api/v2/features/:id/revisions/new/rules/reorder（本文：{ "ruleIds": ["<id>", ...] }）

引き継ぎ先

• flag-targeting — 条件、保存済みグループ、ルールレベルの前提条件を持つ強制／ロールアウトルール
• flag-experiment — experiment-ref ルールとインライン実験ルール
• flag-schedule — ルールの時間指定アクティベーション期間
• flag-ramp — 複数ステップの段階的ロールアウトスケジュール
• flag-monitoring — モニタリング対象のロールアウトと安全なロールアウトルール
• flag-prerequisites — 機能レベルの前提条件ゲート（ルールレベルではありません）
• flag-publish — 削除または並べ替え後にドラフトを公開する場合