launchdarkly-flag-cleanup

Name: launchdarkly-flag-cleanup
Author: launchdarkly

20stars6forks

How to install launchdarkly-flag-cleanup?

launchdarkly/ai-tooling/launchdarkly-flag-cleanup

$npx -y skills add launchdarkly/ai-tooling --skill launchdarkly-flag-cleanup

Installs into the current project.

Summary

Safely remove a feature flag from code while preserving production behavior. Use when the user wants to remove a flag from code, delete flag references, or create a PR that hardcodes the winning variation after a rollout is complete.

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Flag Cleanup
2
3	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.
4
5	If you haven't already identified which flag to clean up, use the [flag discovery skill](../launchdarkly-flag-discovery/SKILL.md) first to audit the landscape and find candidates.
6
7	## Prerequisites
8
9	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
10
11	Required MCP tools:
12	- `check-removal-readiness`: detailed safety check (orchestrates flag config, cross-env status, dependencies, code references, and expiring targets in parallel)
13	- `get-flag`: fetch flag configuration for a specific environment
14
15	Optional MCP tools:
16	- `archive-flag`: archive the flag in LaunchDarkly after code removal
17	- `delete-flag`: permanently delete the flag (irreversible, prefer archive)
18
19	## Core Principles
20
21	1. Safety First: Always preserve current production behavior.
22	2. LaunchDarkly as Source of Truth: Never guess the forward value. Query the actual configuration.
23	3. Follow Conventions: Respect existing code style and structure.
24	4. Minimal Change: Only remove flag-related code. No unrelated refactors.
25
26	## Workflow
27
28	### Step 1: Explore the Codebase
29
30	Before touching LaunchDarkly or removing code, understand how this flag is used in the codebase.
31
32	1. Find all references to the flag key. Search for the flag key string (e.g., `new-checkout-flow`) across the codebase. Check for:
33	- Direct SDK evaluation calls (`variation()`, `boolVariation()`, `useFlags()`, etc.)
34	- Constants/enums that reference the key
35	- Wrapper/service patterns that abstract the SDK
36	- Configuration files, tests, and documentation
37	- See [SDK Patterns](references/sdk-patterns.md) for the full list of patterns by language
38
39	2. Understand the branching. For each reference, identify:
40	- What code runs when the flag is `true` (or variation A)?
41	- What code runs when the flag is `false` (or variation B)?
42	- Are there side effects, early returns, or nested conditions?
43
44	3. Note the scope. How many files, components, or modules does this flag touch? A flag used in one `if` block is simpler than one threaded through multiple layers.
45
46	### Step 2: Run the Removal Readiness Check
47
48	Use `check-removal-readiness` to get a detailed safety assessment. This single tool call orchestrates multiple checks in parallel:
49	- Flag configuration and targeting state
50	- Cross-environment status
51	- Dependent flags (prerequisites)
52	- Expiring targets
53	- Code reference statistics
54
55	The tool returns a readiness verdict:
56
57	`safe`: No blockers or warnings. Proceed with removal.
58
59	`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.
60
61	`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.
62
63	### Step 3: Determine the Forward Value
64
65	Use `get-flag` to fetch the flag configuration in each critical environment. The forward value is the variation that replaces the flag in code.
66
67	\| Scenario \| Forward Value \|
68	\|----------\|---------------\|
69	\| All critical envs ON, same fallthrough, no rules/targets \| Use `fallthrough.variation` \|
70	\| All critical envs OFF, same offVariation \| Use `offVariation` \|
71	\| Critical envs differ in ON/OFF state \| NOT SAFE: stop and inform the user \|
72	\| Critical envs serve different variations \| NOT SAFE: stop and inform the user \|
73
74	### Step 4: Present the Cleanup Plan
75
76	Before modifying any code, present a summary to the user and wait for confirmation:
77
78	1. The forward value — which variation will be hardcoded and why (based on the flag's current state).
79	2. All code references found — file paths and line numbers from Step 1.
80	3. Planned changes — for each reference, describe what will be removed and what will be kept.
81	4. Readiness verdict — the result from `check-removal-readiness` (safe, caution, or blocked) and any warnings.
82	5. LaunchDarkly action — confirm the flag will be archived after code changes are complete.
83
84	Do not proceed with code changes until the user explicitly confirms.
85
86	### Step 5: Remove the Flag from Code
87
88	Now e

People who liked this also viewed

6 picks

Type

launchdarkly-flag-cleanup

20stars6forks

View on GitHub

How to install launchdarkly-flag-cleanup?

launchdarkly/ai-tooling/launchdarkly-flag-cleanup

$npx -y skills add launchdarkly/ai-tooling --skill launchdarkly-flag-cleanup

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Flag Cleanup
2
3	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.
4
5	If you haven't already identified which flag to clean up, use the [flag discovery skill](../launchdarkly-flag-discovery/SKILL.md) first to audit the landscape and find candidates.
6
7	## Prerequisites
8
9	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
10
11	Required MCP tools:
12	- `check-removal-readiness`: detailed safety check (orchestrates flag config, cross-env status, dependencies, code references, and expiring targets in parallel)
13	- `get-flag`: fetch flag configuration for a specific environment
14
15	Optional MCP tools:
16	- `archive-flag`: archive the flag in LaunchDarkly after code removal
17	- `delete-flag`: permanently delete the flag (irreversible, prefer archive)
18
19	## Core Principles
20
21	1. Safety First: Always preserve current production behavior.
22	2. LaunchDarkly as Source of Truth: Never guess the forward value. Query the actual configuration.
23	3. Follow Conventions: Respect existing code style and structure.
24	4. Minimal Change: Only remove flag-related code. No unrelated refactors.
25
26	## Workflow
27
28	### Step 1: Explore the Codebase
29
30	Before touching LaunchDarkly or removing code, understand how this flag is used in the codebase.
31
32	1. Find all references to the flag key. Search for the flag key string (e.g., `new-checkout-flow`) across the codebase. Check for:
33	- Direct SDK evaluation calls (`variation()`, `boolVariation()`, `useFlags()`, etc.)
34	- Constants/enums that reference the key
35	- Wrapper/service patterns that abstract the SDK
36	- Configuration files, tests, and documentation
37	- See [SDK Patterns](references/sdk-patterns.md) for the full list of patterns by language
38
39	2. Understand the branching. For each reference, identify:
40	- What code runs when the flag is `true` (or variation A)?
41	- What code runs when the flag is `false` (or variation B)?
42	- Are there side effects, early returns, or nested conditions?
43
44	3. Note the scope. How many files, components, or modules does this flag touch? A flag used in one `if` block is simpler than one threaded through multiple layers.
45
46	### Step 2: Run the Removal Readiness Check
47
48	Use `check-removal-readiness` to get a detailed safety assessment. This single tool call orchestrates multiple checks in parallel:
49	- Flag configuration and targeting state
50	- Cross-environment status
51	- Dependent flags (prerequisites)
52	- Expiring targets
53	- Code reference statistics
54
55	The tool returns a readiness verdict:
56
57	`safe`: No blockers or warnings. Proceed with removal.
58
59	`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.
60
61	`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.
62
63	### Step 3: Determine the Forward Value
64
65	Use `get-flag` to fetch the flag configuration in each critical environment. The forward value is the variation that replaces the flag in code.
66
67	\| Scenario \| Forward Value \|
68	\|----------\|---------------\|
69	\| All critical envs ON, same fallthrough, no rules/targets \| Use `fallthrough.variation` \|
70	\| All critical envs OFF, same offVariation \| Use `offVariation` \|
71	\| Critical envs differ in ON/OFF state \| NOT SAFE: stop and inform the user \|
72	\| Critical envs serve different variations \| NOT SAFE: stop and inform the user \|
73
74	### Step 4: Present the Cleanup Plan
75
76	Before modifying any code, present a summary to the user and wait for confirmation:
77
78	1. The forward value — which variation will be hardcoded and why (based on the flag's current state).
79	2. All code references found — file paths and line numbers from Step 1.
80	3. Planned changes — for each reference, describe what will be removed and what will be kept.
81	4. Readiness verdict — the result from `check-removal-readiness` (safe, caution, or blocked) and any warnings.
82	5. LaunchDarkly action — confirm the flag will be archived after code changes are complete.
83
84	Do not proceed with code changes until the user explicitly confirms.
85
86	### Step 5: Remove the Flag from Code
87
88	Now e

People who liked this also viewed

6 picks

Type