From launchdarkly
Audits LaunchDarkly feature flags to assess stale flags, flag debt, cleanup candidates, and overall flag health across environments.
How this skill is triggered — by the user, by Claude, or both
Slash command
/launchdarkly:launchdarkly-flag-discoveryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You're using a skill that will guide you through auditing and understanding the feature flag landscape in a LaunchDarkly project. Your job is to explore the project, assess the health of its flags, identify what needs attention, and provide actionable recommendations.
You're using a skill that will guide you through auditing and understanding the feature flag landscape in a LaunchDarkly project. Your job is to explore the project, assess the health of its flags, identify what needs attention, and provide actionable recommendations.
This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
Required MCP tools:
list-flags: search and browse flags with filtering by state, type, tagsget-flag: get full configuration for a single flag in a specific environmentget-flag-status-across-envs: check a flag's lifecycle status across all environmentsOptional MCP tools (enhance depth):
find-stale-flags: find flags that are candidates for cleanup, sorted by stalenessget-flag-health: get combined health view for a single flag (merges status + config)check-removal-readiness: detailed safety check for a specific flagBefore diving into flag data, establish context:
projectKey with the user. If they haven't specified one, ask.Adapt your approach to the user's goal:
For a broad audit:
list-flags scoped to a critical environment (default to production).state (active, inactive, launched, new) to segment the landscape.type (temporary vs permanent): temporary flags are the primary cleanup targets.For cleanup planning:
find-stale-flags: this is the most efficient entry point. It returns a prioritized list of cleanup candidates sorted by staleness, categorized as:
never_requested: created but never evaluated (possibly abandoned)inactive_30d: no SDK evaluations in the specified periodlaunched_no_changes: fully rolled out, no recent changesinactiveDays is 30. Increase for conservative cleanup (60, 90) or decrease for aggressive cleanup (7, 14).includeOnly is temporary. Set to all to include permanent flags.For a targeted investigation:
get-flag-health for a single-flag deep dive. It merges status data with configuration context in one call, returning lifecycle state, last-requested timestamp, targeting summary, age, and whether it's temporary.get-flag for the full configuration including rules, targets, and fallthrough details.For flags that need deeper investigation, assess health signals. See Flag Health Signals for the full interpretation guide.
Key signals to evaluate:
| Signal | What it tells you |
|---|---|
| Lifecycle state | Where the flag is in its journey (new -> active -> launched -> inactive) |
| Last requested | When an SDK last evaluated this flag: staleness indicator |
| Targeting complexity | Number of rules and targets: removal complexity indicator |
| Cross-environment consistency | Whether the flag behaves the same everywhere |
| Flag age + temporary status | Old temporary flags are strong cleanup candidates |
Use get-flag-status-across-envs to check if a flag is consistent across environments. A flag inactive in production but active in staging tells a different story than one inactive everywhere.
Group flags into actionable categories:
If the user wants to know whether a specific flag can be removed, use check-removal-readiness. This tool orchestrates multiple API calls in parallel and returns a structured verdict:
safe: No blockers or warnings. Proceed with cleanup.caution: Warnings exist (code references, expiring targets, permanent flag type). Present and let the user decide.blocked: Hard blockers (dependent flags, active requests, targeting rules). Must resolve first.See Removal Readiness Checklist for the full details on interpreting each signal.
Structure your response based on what the user asked for:
For audits: Lead with a summary (total flags, breakdown by state and type), then highlight what needs attention, then provide specific recommendations.
For specific flags: Lead with the verdict (healthy / needs attention / ready to remove), then support it with the signals you found.
For cleanup planning: Lead with the count of cleanup candidates, prioritize by confidence (safest removals first), and link to the cleanup workflow for execution.
60000 means 60%. Always convert to human-readable percentages.npx claudepluginhub launchdarkly/ai-tooling --plugin launchdarklyIdentifies and cleans up stale feature flags in PostHog projects. Covers staleness detection, dependency checking, and safe removal workflows.
Manages feature flag lifecycle: detect flags in codebases, classify categories, and design rollout strategies with naming conventions. For auditing stale flags or planning new flag architecture.
Operational discipline for feature flags as production infrastructure: flag types, naming, targeting, rollout strategy, lifecycle, governance, stale flag management, and technical debt patterns.