LaunchDarkly Flag Cleanup
You're using a skill that will guide you through safely removing a feature flag from a codebase while preserving production behavior. Your job is to explore the codebase to understand how the flag is used, query LaunchDarkly to determine the correct forward value, remove the flag code cleanly, and verify the result.
If you haven't already identified which flag to clean up, use the flag discovery skill first to audit the landscape and find candidates.
Prerequisites
This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
Required MCP tools:
check-removal-readiness: detailed safety check (orchestrates flag config, cross-env status, dependencies, code references, and expiring targets in parallel)get-flag: fetch flag configuration for a specific environment
Optional MCP tools:
archive-flag: archive the flag in LaunchDarkly after code removaldelete-flag: permanently delete the flag (irreversible, prefer archive)
Core Principles
- Safety First: Always preserve current production behavior.
- LaunchDarkly as Source of Truth: Never guess the forward value. Query the actual configuration.
- Follow Conventions: Respect existing code style and structure.
- Minimal Change: Only remove flag-related code. No unrelated refactors.
Workflow
Step 1: Explore the Codebase
Before touching LaunchDarkly or removing code, understand how this flag is used in the codebase.
- Find all references to the flag key. Search for the flag key string (e.g.,
new-checkout-flow) across the codebase. Check for:
- Direct SDK evaluation calls (variation(), boolVariation(), useFlags(), etc.) - Constants/enums that reference the key - Wrapper/service patterns that abstract the SDK - Configuration files, tests, and documentation - See SDK Patterns for the full list of patterns by language
- Understand the branching. For each reference, identify:
- What code runs when the flag is true (or variation A)? - What code runs when the flag is false (or variation B)? - Are there side effects, early returns, or nested conditions?
- Note the scope. How many files, components, or modules does this flag touch? A flag used in one
ifblock is simpler than one threaded through multiple layers.
Step 2: Run the Removal Readiness Check
Use check-removal-readiness to get a detailed safety assessment. This single tool call orchestrates multiple checks in parallel:
- Flag configuration and targeting state
- Cross-environment status
- Dependent flags (prerequisites)
- Expiring targets
- Code reference statistics
The tool returns a readiness verdict:
safe: No blockers or warnings. Proceed with removal.
caution: No hard blockers but warnings exist (e.g., code references in other repos, expiring targets scheduled, flag marked as permanent). Present warnings and let the user decide.
blocked: Hard blockers prevent safe removal (e.g., dependent flags, actively receiving requests, targeting is on with active rules). Present blockers: the user must resolve them first.
Step 3: Determine the Forward Value
Use get-flag to fetch the flag configuration in each critical environment. The forward value is the variation that replaces the flag in code.
| Scenario | Forward Value |
|---|---|
| All critical envs ON, same fallthrough, no rules/targets | Use fallthrough.variation |
| All critical envs OFF, same offVariation | Use offVariation |
| Critical envs differ in ON/OFF state | NOT SAFE: stop and inform the user |
| Critical envs serve different variations | NOT SAFE: stop and inform the user |
Step 4: Present the Cleanup Plan
Before modifying any code, present a summary to the user and wait for confirmation:
- The forward value — which variation will be hardcoded and why (based on the flag's current state).
- All code references found — file paths and line numbers from Step 1.
- Planned changes — for each reference, describe what will be removed and what will be kept.
- Readiness verdict — the result from
check-removal-readiness(safe, caution, or blocked) and any warnings. - LaunchDarkly action — confirm the flag will be archived after code changes are complete.
Do not proceed with code changes until the user explicitly confirms.
Step 5: Remove the Flag from Code
Now execute the removal using what you learned in Step 1.
- Replace flag evaluations with the forward value.
- Preserve the code branch matching the forward value - Remove the dead branch entirely - If the flag value was assigned to a variable, replace the variable with the literal value or inline it
- Clean up dead code.
- Remove imports, constants, and type definitions that only existed for the flag - Remove functions, components, or files that only existed for the dead branch - Check for orphaned exports, hooks, helpers, styles, and test files - If the repo uses an unused-export tool (Knip, ts-prune, lint rules), run it and remove any flag-related orphans
- Don't over-clean.
- Only remove code directly related to the flag - Don't refactor, optimize, or "improve" surrounding code - Don't change formatting or style of untouched code
Example transformation (boolean flag, forward value = true):
// Before
const showNewCheckout = await ldClient.variation('new-checkout-flow', user, false);
if (showNewCheckout) {
return renderNewCheckout();
} else {
return renderOldCheckout();
}
// After
return renderNewCheckout();Step 6: Create Pull Request
Use the template in references/pr-template.md for a structured PR description. The PR should clearly communicate:
- What flag was removed and why
- What the forward value is and why it's correct
- The readiness assessment results (from
check-removal-readiness) - What code was removed and what behavior is preserved
- Whether other repos still reference this flag
Step 7: Verify
Before considering the job done:
- Code compiles and lints. Run the project's build and lint steps.
- Tests pass. If the flag was used in tests, the tests should be updated to reflect the hardcoded behavior.
- No remaining references. Search the codebase one more time for the flag key to make sure nothing was missed.
- PR is complete. The description covers the readiness assessment, forward value rationale, and any cross-repo coordination needed.
Edge Cases
| Situation | Action |
|---|---|
| Flag not found in LaunchDarkly | Inform user, check for typos in the key |
| Flag already archived | Ask if code cleanup is still needed (flag is gone from LD but code may still reference it) |
| Multiple SDK patterns in codebase | Search all patterns: variation(), boolVariation(), variationDetail(), allFlags(), useFlags(), plus any wrappers |
Dynamic flag keys (flag-${id}) | Warn that automated removal may be incomplete: manual review required |
| Different default values in code vs LD | Flag as inconsistency in the PR description |
| Orphaned exports/files remain after removal | Run unused-export checks and remove dead files |
What NOT to Do
- Don't change code unrelated to flag cleanup.
- Don't refactor or optimize beyond flag removal.
- Don't remove flags still being actively rolled out.
- Don't guess the forward value: always query LaunchDarkly.
After Cleanup
Once the PR is merged and deployed:
- Archive the flag in LaunchDarkly using
archive-flag. Archival is reversible; deletion is not. Always archive first. - Notify other teams if
check-removal-readinessreported code references in other repositories. - If the flag had targeting changes pending, they can be ignored: the flag is being removed.
References
- PR Template: Structured PR description for flag removal
- SDK Patterns: Flag evaluation patterns by language/framework
- Flag Discovery: Find cleanup candidates before using this skill
- Flag Targeting: If you need to change targeting instead of removing