Create and configure LaunchDarkly feature flags in a way that fits the existing codebase. Use when the user wants to create a new flag, wrap code in a flag, add a feature toggle, or set up an experiment. Guides exploration of existing patterns before creating.
Detected risks:
A guided workflow for introducing a new LaunchDarkly feature flag into a codebase in a way that matches the team's existing conventions. It covers the full path from exploration through creation, code wiring, and verification, and is intended for when a user wants to create a new flag, wrap code in a flag, add a feature toggle, or set up an experiment. The skill requires the remotely hosted LaunchDarkly MCP server, using the required tools create-flag and get-flag, with the optional list-flags and update-flag-settings tools to enhance the workflow.
The process starts by exploring how flags are already used: finding the SDK in use (server-side Node, React, Python, Go, Java, and others), locating existing variation calls such as variation(), boolVariation(), or useFlags(), and learning conventions like key casing, where keys live, default values, and how the user or context object is built. It then determines the right flag type from user intent, mapping simple on/off toggles and gradual rollouts to boolean flags and A/B tests, numeric thresholds, or config objects to multivariate string, number, or JSON flags. Sensible defaults are applied, including setting temporary true unless the flag is explicitly permanent and generating a kebab-case key from the name while respecting the codebase convention.
After creating the flag with create-flag, the skill notes that flags are always created with targeting off and serve the offVariation until enabled, so it directs the user to a separate flag targeting skill to turn it on. It then adds evaluation code matching the patterns found earlier, always using the safe existing behavior as the in-code default so the feature stays off if LaunchDarkly is unreachable, and verifies via build or lint plus get-flag. It also documents metadata updates through update-flag-settings (rename, description, add or remove tags, mark temporary or permanent), stressing that flag keys are immutable once created.
It requires the remotely hosted LaunchDarkly MCP server. The required MCP tools are create-flag and get-flag, with list-flags and update-flag-settings as optional tools that enhance the workflow.
Boolean flags for on/off toggles and gradual rollouts, and multivariate flags using string, number, or JSON variations for A/B tests, numeric thresholds, or serving different config objects.
No. Flags are created with targeting off in all environments and serve the offVariation to everyone until targeting is turned on, which is a safety feature. Enabling targeting is handled by the separate flag targeting skill.
It uses the safe behavior, typically the existing behavior before the flag, as the in-code default. This ensures the feature stays off if the SDK cannot reach LaunchDarkly.
No, flag keys are immutable once created, so the key must be chosen carefully. Other metadata such as name, description, tags, and temporary or permanent status can be changed via update-flag-settings.
Quick Setup:
.claude/skills/Repository
launchdarkly/agent-skills