Launchdarkly Flag Discovery

LaunchDarkly Flag Discovery

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.

Prerequisites

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, tags
• get-flag: get full configuration for a single flag in a specific environment
• get-flag-status-across-envs: check a flag's lifecycle status across all environments

Optional MCP tools (enhance depth):

• find-stale-flags: find flags that are candidates for cleanup, sorted by staleness
• get-flag-health: get combined health view for a single flag (merges status + config)
• check-removal-readiness: detailed safety check for a specific flag

Workflow

Step 1: Understand the Project

Before diving into flag data, establish context:

1. Identify the project. Confirm the projectKey with the user. If they haven't specified one, ask. 2. Understand scope. Ask the user what they're trying to accomplish:

• Broad audit? ("What's the state of our flags?")
• Targeted investigation? ("Is this specific flag still needed?")
• Cleanup planning? ("What flags can we remove?")

Step 2: Explore the Flag Landscape

Adapt your approach to the user's goal:

For a broad audit:

• Use list-flags scoped to a critical environment (default to production).
• Note the total count: this tells you the scale of the flag surface area.
• Filter by state (active, inactive, launched, new) to segment the landscape.
• Filter by type (temporary vs permanent): temporary flags are the primary cleanup targets.

For cleanup planning:

• Use 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 period
• launched_no_changes: fully rolled out, no recent changes
• Default inactiveDays is 30. Increase for conservative cleanup (60, 90) or decrease for aggressive cleanup (7, 14).
• Default includeOnly is temporary. Set to all to include permanent flags.

For a targeted investigation:

• Use 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.
• Or use get-flag for the full configuration including rules, targets, and fallthrough details.

Step 3: Assess Flag Health

For flags that need deeper investigation, assess health signals. See Flag Health Signals for the full interpretation guide.

Key signals to evaluate:

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.

Step 4: Categorize and Prioritize

Group flags into actionable categories:

1. Ready to remove: Inactive everywhere, temporary, no dependencies. Direct the user to the flag cleanup skill for code removal. 2. Likely safe, needs verification: Launched (fully rolled out), no rule changes recently. The user should confirm the rollout is intentionally complete. 3. Needs investigation: Active in some environments but not others, or has complex targeting. Don't recommend action without more context. 4. Leave alone: Active flags doing their job, or permanent flags that are intentionally long-lived.

Step 5: Assess Removal Readiness (When Applicable)

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.

Step 6: Present Findings

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.

Important Context

• "Launched" means fully rolled out: targeting is on, a single variation is served to everyone, and no changes have been made recently. It doesn't mean "recently deployed."
• "Inactive" doesn't always mean safe to remove. The flag might be used in code that hasn't shipped yet, or referenced as a prerequisite by another flag.
• Permanent flags can be inactive on purpose. Some flags are designed to be dormant until needed (kill switches, emergency toggles). Don't automatically flag these for cleanup.
• Weights are scaled by 1000 in the API. A weight of 60000 means 60%. Always convert to human-readable percentages.
• This skill is for discovery, not action. If the user wants to remove a flag from code, direct them to the flag cleanup skill. If they want to change targeting, direct them to the flag targeting skill.

References

• Flag Health Signals: How to interpret lifecycle states, staleness, and health data
• Removal Readiness Checklist: Full safety assessment before recommending flag removal

LaunchDarkly Flag Discovery Skill

An Agent Skill for auditing and understanding your LaunchDarkly feature flag landscape.

Overview

This skill teaches agents how to:

• Survey the full feature flag inventory in a project
• Identify stale, inactive, or fully-launched flags
• Assess whether specific flags are ready for removal
• Provide prioritized, actionable recommendations

Installation (Local)

For now, install by placing this skill directory where your agent client loads skills.

Examples:

• Generic: copy skills/feature-flags/launchdarkly-flag-discovery/ into your client's skills path

Prerequisites

This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment. The remote server provides higher-level, agent-optimized tools that orchestrate multiple API calls and return pruned, actionable responses.

Refer to your LaunchDarkly account settings for instructions on connecting to the remotely hosted MCP server.

Usage

Once installed, the skill activates automatically when you ask about flag health or inventory:

What's the state of our feature flags?

Which flags are stale and should be cleaned up?

Is the `dark-mode` flag ready to be removed?

Structure

launchdarkly-flag-discovery/
├── SKILL.md
├── marketplace.json
├── README.md
└── references/
    ├── flag-health-signals.md
    └── removal-readiness-checklist.md

Related

• LaunchDarkly Flag Cleanup: Remove flags from code after discovery identifies candidates
• LaunchDarkly MCP Server
• LaunchDarkly Docs

License

Apache-2.0

Flag Health Signals

How to interpret the data you get back from LaunchDarkly when assessing flag health.

Lifecycle States

Every flag in every environment has a lifecycle state. Here's what each one means and what action it implies:

Staleness Signals

Targeting Complexity

The more complex a flag's targeting, the more carefully you need to assess it:

Cross-Environment Signals

Use get-flag-status-across-envs to build a complete picture:

Decision Matrix

Combine signals to reach a recommendation:

Removal Readiness Checklist

A systematic safety check to determine whether a feature flag can be safely removed. Run through this checklist before recommending flag removal to a user.

The Checklist

1. Cross-Environment Status

Check: Use get-flag-status-across-envs to verify the flag's state in all environments.

Pass criteria:

• Flag is inactive or launched in ALL critical environments (production, staging, etc.)
• No environment shows new or active state

Fail criteria:

• Flag is active in any critical environment
• Flag is new anywhere (still being rolled out)
• Critical environments show different states (e.g., production ON, staging OFF)

2. Configuration Consistency

Check: Use get-flag for each critical environment and compare configurations.

Pass criteria:

• All critical environments serve the same variation (same fallthrough.variation or same offVariation)
• No targeting rules or individual targets exist in critical environments

Caution criteria:

• Environments serve the same variation but through different mechanisms (one via fallthrough, another via rules)
• Simple rules exist but all resolve to the same variation

Fail criteria:

• Critical environments serve different variations
• Complex targeting rules exist that serve multiple variations
• Individual targets override the default behavior

3. Dependency Check

Check: Look for prerequisites in the flag configuration. Also check if this flag appears as a prerequisite in other flags.

Pass criteria:

• No other flags list this flag as a prerequisite
• This flag has no prerequisites of its own (simpler removal)

Fail criteria (hard blocker):

• Other flags depend on this flag as a prerequisite: removing it would break their targeting logic

4. Code References

Check: If available, use check-removal-readiness which includes code reference statistics. Otherwise, use get-code-references to find repositories that reference this flag.

Pass criteria:

• No code references found, or references only exist in the current repository (about to be cleaned up)

Caution criteria:

• Code references exist in multiple repositories: flag removal in code needs to be coordinated

Note: Code reference scanning has limitations. It tracks static string matches and may miss dynamic flag key construction (flag-${name}) or have false positives from comments/documentation.

5. Expiring Targets

Check: Look for scheduled expiring targets on the flag.

Pass criteria:

• No expiring targets scheduled

Caution criteria:

• Expiring targets exist: someone actively set a future removal date. Coordinate with them.

6. Flag Type

Check: The temporary field on the flag.

Pass criteria:

• Flag is marked as temporary: it was intended to be removed

Caution criteria:

• Flag is marked as permanent: it may be intentionally long-lived. Confirm with the user before recommending removal.

Readiness Levels

After running the checklist, categorize the result:

Safe

All checks pass. No blockers or warnings.

• Recommend proceeding with code removal using the flag cleanup skill
• Suggest archival in LaunchDarkly after code changes are deployed

Caution

No hard blockers, but warnings exist.

• Present each warning with context
• Recommend archive (reversible) over delete (permanent)
• Suggest addressing warnings first (e.g., remove code references, then re-check)

Blocked

Hard blockers prevent safe removal.

• Present each blocker with specifics
• For prerequisite dependencies: user must update dependent flags first
• For active targeting: user should toggle off and wait for a cool-down period
• For active status: flag is still being used: don't remove

Presenting Results

Structure the assessment as:

1. Verdict: Lead with safe / caution / blocked 2. Blockers (if any): Each with type and actionable detail 3. Warnings (if any): Each with type and context 4. Forward value: What variation should replace the flag in code (only if safe or caution) 5. Next steps: What to do now (proceed with cleanup, address warnings, resolve blockers)