flag-prerequisites

flag-prerequisites

Add, remove, or inspect feature-level prerequisites on a GrowthBook feature flag. A feature-level prerequisite is a boolean gate: if the specified prerequisite flag is off for a user, the current flag skips all its rules and returns its defaultValue for that user.

Feature-level prerequisites are boolean-flag-only. The prerequisite flag must have valueType: "boolean". The gate condition is always "prerequisite flag is on" ({"value": true}) — no custom conditions. If the user wants a more nuanced dependency (e.g. gate on a string flag's value, or gate a single rule rather than the whole flag), route to flag-targeting.

This is distinct from rule-level prerequisites (which gate a single rule and support richer conditions) — feature-level prerequisites apply to every rule on the flag simultaneously.

All API calls go through the bundled helper: ${CLAUDE_PLUGIN_ROOT}/scripts/gb-call. It needs GB_API_KEY set in env or written to ~/.config/growthbook/.env by /growthbook:gb-setup.

Workflow

Path A — Add a prerequisite

1. Fetch the flag's current prerequisites:

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

   Capture the existing prerequisites array. The PUT below replaces the full array, so you need the current contents to avoid overwriting existing prerequisites.

2. Confirm the prerequisite flag exists and is boolean:

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

   Check valueType. If it is not "boolean", halt:

   "Feature-level prerequisites only support boolean flags. <prerequisite-flag-id> is a <valueType> flag. To gate on a non-boolean flag's value, add a rule-level prerequisite instead via flag-targeting."

3. Build the new prerequisites array. Append to any existing entries. The condition is always {"value": true} — the gate means "prerequisite flag is on":

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

4. Apply via draft:

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

5. Hand off to flag-publish.

Path B — Remove a prerequisite

1. Fetch current prerequisites (step A-1 above).
2. Show the list and ask which to remove.
3. Build the updated array without the removed entry.
4. Apply via draft (step A-4 above) with the filtered array. An empty array [] removes all prerequisites.
5. Hand off to flag-publish.

Path C — Inspect current prerequisites

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

Surface the prerequisites array. For each entry, fetch the prerequisite flag to show its current evaluated state and value type. Use flag-graph to trace the full dependency chain if needed.

Guardrails

• Draft version threading. If a version number is already in context from a previous write skill in this session, use it explicitly (e.g. .../revisions/42/prerequisites) instead of new. This keeps all changes in the same draft. Fall back to new when starting fresh — it auto-creates or reuses the most recently updated open draft.
• PUT /prerequisites replaces the full array. It's not additive. Always fetch the current array first and include all existing entries when adding or modifying — otherwise you'll silently delete prerequisites the user didn't intend to touch.
• Prerequisite flags must be boolean. Halt and route to flag-targeting if the user specifies a non-boolean flag as a prerequisite.
• The condition is always {"value": true}. Do not accept or generate custom conditions for feature-level prerequisites. The backend is permissive but we intentionally constrain this — the gate means "this flag is on". If the user wants a richer condition (e.g. string flag equals a value, flag is live but not necessarily true), route to flag-targeting rule-level prerequisites.
• Feature-level vs rule-level prerequisites. This skill gates the entire flag. If the user wants a prerequisite scoped to a single rule, route to flag-targeting.
• Circular dependencies must be avoided. If flag A requires flag B and flag B requires flag A, neither will ever evaluate. Check the existing dependency chain via flag-graph before adding a prerequisite.
• Prerequisite flags must be in the same GrowthBook project (or org-wide). Cross-project prerequisites may not resolve correctly depending on SDK configuration.
• Deleting a prerequisite flag breaks any flag that depends on it. The dependent flag's prerequisite condition will silently always fail. Surface this when the user is reviewing dependencies via flag-graph before cleanup.

Endpoints used

• GET /api/v2/features/:id — fetch flag state including current prerequisites array
• PUT /api/v2/features/:id/revisions/new/prerequisites (body: { "prerequisites": [...] })

Handoffs

• flag-search — to find the prerequisite flag's ID if the user gives a name
• flag-graph — to trace the full dependency chain and detect circular dependencies
• flag-targeting — to add rule-level prerequisites (scoped to a single rule rather than the whole flag)
• flag-publish — to publish the draft, handle approval-required (400) and merge conflicts (409)