mcpField
F
flag-metadata

flag-metadata

github.com/growthbook開発2540 回インストール4 週間前に更新
リポジトリ

flag-metadata について

GrowthBook の既存フィーチャーフラグの管理メタデータを変更するスキルです。変更をドラフトのリビジョンに反映し、更新前に値を確認して、公開は別途行います。

主な機能

  1. 01説明、担当者、プロジェクトの変更
  2. 02タグとカスタムフィールドの更新
  3. 03JSON Schema と neverStale の設定
  4. 04変更をドラフトリビジョンに反映

活用シーン

  1. 01フラグの担当者やプロジェクトの変更
  2. 02フラグの説明やタグの更新
  3. 03カスタムフィールドや JSON Schema の編集

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/growthbook/skills --skill flag-metadata

インストール後、Claude Code で/flag-metadataを入力して読み込まれたか確認します。

詳細

flag-metadata

既存の GrowthBook フィーチャーフラグの管理メタデータを更新します。説明、担当者、プロジェクト、タグ、カスタムフィールド、JSON スキーマの変更は、ほかのすべてのフラグ変更と同様にドラフトリビジョンを経由します。変更を反映するには、公開する必要があります。

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

必須入力

開始前に、次の情報を収集します。

  • フラグ ID — ケバブケースのキーです。ユーザーが説明を提示した場合は、まず flag-search を使って特定します。
  • 変更内容 — 説明、担当者、プロジェクト、タグ、neverStale、customFields、jsonSchema のうち、1 つ以上です。

ワークフロー

1. 現在のメタデータを取得する
gb-call GET /api/v2/features/<flag-id>

変更予定のフィールドについて、現在の値をユーザーに提示します。変更を適用する前に、新しい値を確認します。

2. プロジェクト ID を解決する（プロジェクトを変更する場合）

API ではプロジェクト名を受け付けないため、まず名前を ID に解決します。

gb-call GET /api/v1/projects

ユーザーが指定したプロジェクト名を返された一覧と照合し、id フィールドを使用します。

3. ドラフト経由でメタデータの変更を適用する
echo '<payload>' | gb-call PUT /api/v2/features/<flag-id>/revisions/new/metadata -

new のマジックバージョンは、新しいドラフトを作成するか、既存のドラフトに変更をアトミックに重ねます。

対応フィールドとその型は次のとおりです。

{
  "description": "<string>",
  "owner": "<email or u_... userId>",
  "project": "<project-id or empty string to clear>",
  "tags": ["<tag>", "<tag>"],
  "neverStale": true,
  "customFields": { "<key>": "<value>" },
  "jsonSchema": { "<json-schema-object>" }
}

ユーザーが変更を希望するフィールドだけを送信します。変更しないフィールドをそのまま返さないでください。

公開ステップのために、返された version 番号を記録します。

4. 公開を提案する

次のように尋ねます。「このメタデータの変更を今すぐ公開しますか、それともドラフトのままにしますか？」

メタデータの変更はリスクが低いため、すぐに公開することをデフォルトで提案します。公開ステップでは flag-publish に引き継ぎ、承認が必要な場合やマージ競合が発生した場合の処理も含めます。

ガードレール

  • ドラフトバージョンの引き継ぎ。 このセッションで以前の書き込みスキルからバージョン番号がすでにコンテキストにある場合は、new ではなく明示的に使用します（例：.../revisions/42/metadata）。これにより、すべての変更が同じドラフトにまとまります。新たに開始する場合は new を使用します。これは最新の更新日時を持つオープンなドラフトを自動的に作成するか、再利用します。
  • owner はメールアドレスまたは u_... userId を受け付けます。 割り当てる相手のメールアドレスまたは userId をユーザーに尋ねます。自分自身に割り当てる場合は、その人のメールアドレスまたは userId を尋ねます。環境変数から読み取れるデフォルト値はありません。ユーザーがメールアドレスではなく名前を指定した場合は、確認を求めます。API は表示名を受け付けません。
  • project は名前ではなく ID です。 設定する前に、必ず GET /api/v1/projects でプロジェクト名を解決します。空文字列 "" を指定するとプロジェクトとの関連付けが解除され、フラグは組織全体のスコープに戻ります。
  • tags は配列全体を置き換えます。 追加方式ではありません。フラグに既存のタグがあり、ユーザーが 1 つだけ追加したい場合は、まず現在のタグを取得し、新しいタグを追加して、更新後の配列全体を送信します。
  • neverStale: true を設定すると、フラグは古さの検出対象から永久に除外されます。 キルスイッチ、運用トグル、ライセンスゲートに使用します。設定後は、数か月間変更されていなくても古いフラグのレポートに表示されなくなることをユーザーに警告します。
  • jsonSchema は Enterprise 専用です。 組織でこの機能が利用できない場合、API はエラーを返します。ユーザーにエラーを明確に伝えます。
  • メタデータの変更も承認ワークフローを通過します。 一見無害な説明の変更でも、組織のレビューゲートが適用される場合があります。flag-publish を使用し、ほかのリビジョンと同じように、承認が必要な場合やマージ競合が発生した場合のエラーに備えます。
  • customFields のキーは、組織で設定されているカスタムフィールド定義と一致する必要があります。 組織で認識されないキーは、API によってエラーになったり、黙って破棄されたりする場合があります。カスタムフィールドのキー名が正しいことを確認します。

使用するエンドポイント

  • GET /api/v2/features/:id — 確認のために現在のメタデータを取得
  • GET /api/v1/projects — プロジェクト名を ID に解決
  • PUT /api/v2/features/:id/revisions/new/metadata — ドラフトにメタデータの変更を適用

引き継ぎ

  • flag-search — ユーザーがフラグ ID ではなく説明を指定した場合
  • flag-default-value — ルールに一致しない場合にフラグが返す値を変更する場合
  • flag-cleanup — フラグをアーカイブまたは完全に削除する場合
  • flag-publish — 下書きを公開し、承認が必要な場合（400）やマージコンフリクト（409）に対処する場合

コメント

Markdown 対応