launchdarkly-flag-discovery

Name: launchdarkly-flag-discovery
Author: launchdarkly

20stars6forks

How to install launchdarkly-flag-discovery?

launchdarkly/ai-tooling/launchdarkly-flag-discovery

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

Installs into the current project.

Summary

Audit your LaunchDarkly feature flags to understand the landscape, find stale or launched flags, and assess removal readiness. Use when the user asks about flag debt, stale flags, cleanup candidates, flag health, or wants to understand their flag inventory.

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Flag Discovery
2
3	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.
4
5	## Prerequisites
6
7	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
8
9	Required MCP tools:
10	- `list-flags`: search and browse flags with filtering by state, type, tags
11	- `get-flag`: get full configuration for a single flag in a specific environment
12	- `get-flag-status-across-envs`: check a flag's lifecycle status across all environments
13
14	Optional MCP tools (enhance depth):
15	- `find-stale-flags`: find flags that are candidates for cleanup, sorted by staleness
16	- `get-flag-health`: get combined health view for a single flag (merges status + config)
17	- `check-removal-readiness`: detailed safety check for a specific flag
18
19	## Workflow
20
21	### Step 1: Understand the Project
22
23	Before diving into flag data, establish context:
24
25	1. Identify the project. Confirm the `projectKey` with the user. If they haven't specified one, ask.
26	2. Understand scope. Ask the user what they're trying to accomplish:
27	- Broad audit? ("What's the state of our flags?")
28	- Targeted investigation? ("Is this specific flag still needed?")
29	- Cleanup planning? ("What flags can we remove?")
30
31	### Step 2: Explore the Flag Landscape
32
33	Adapt your approach to the user's goal:
34
35	For a broad audit:
36	- Use `list-flags` scoped to a critical environment (default to `production`).
37	- Note the total count: this tells you the scale of the flag surface area.
38	- Filter by `state` (active, inactive, launched, new) to segment the landscape.
39	- Filter by `type` (temporary vs permanent): temporary flags are the primary cleanup targets.
40
41	For cleanup planning:
42	- Use `find-stale-flags`: this is the most efficient entry point. It returns a prioritized list of cleanup candidates sorted by staleness, categorized as:
43	- `never_requested`: created but never evaluated (possibly abandoned)
44	- `inactive_30d`: no SDK evaluations in the specified period
45	- `launched_no_changes`: fully rolled out, no recent changes
46	- Default `inactiveDays` is 30. Increase for conservative cleanup (60, 90) or decrease for aggressive cleanup (7, 14).
47	- Default `includeOnly` is `temporary`. Set to `all` to include permanent flags.
48
49	For a targeted investigation:
50	- 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.
51	- Or use `get-flag` for the full configuration including rules, targets, and fallthrough details.
52
53	### Step 3: Assess Flag Health
54
55	For flags that need deeper investigation, assess health signals. See [Flag Health Signals](references/flag-health-signals.md) for the full interpretation guide.
56
57	Key signals to evaluate:
58
59	\| Signal \| What it tells you \|
60	\|--------\|-------------------\|
61	\| Lifecycle state \| Where the flag is in its journey (new -> active -> launched -> inactive) \|
62	\| Last requested \| When an SDK last evaluated this flag: staleness indicator \|
63	\| Targeting complexity \| Number of rules and targets: removal complexity indicator \|
64	\| Cross-environment consistency \| Whether the flag behaves the same everywhere \|
65	\| Flag age + temporary status \| Old temporary flags are strong cleanup candidates \|
66
67	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.
68
69	### Step 4: Categorize and Prioritize
70
71	Group flags into actionable categories:
72
73	1. Ready to remove: Inactive everywhere, temporary, no dependencies. Direct the user to the [flag cleanup skill](../launchdarkly-flag-cleanup/SKILL.md) for code removal.
74	2. Likely safe, needs verification: Launched (fully rolled out), no rule changes recently. The user should confirm the rollout is intentionally complete.
75	3. Needs investigation: Active in some environments but not others, or has complex targeting. Don't recommend action without more context.
76	4. Leave alone: Active flags doing their job, or permanent flags that are intentionally long-lived.
77
78	### Step 5: Assess Removal Readiness (When Applicable)
79
80	If the user wants to know whether a specific flag can be removed, use `check-removal-readiness

People who liked this also viewed

6 picks

Type

launchdarkly-flag-discovery

20stars6forks

View on GitHub

How to install launchdarkly-flag-discovery?

launchdarkly/ai-tooling/launchdarkly-flag-discovery

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Flag Discovery
2
3	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.
4
5	## Prerequisites
6
7	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
8
9	Required MCP tools:
10	- `list-flags`: search and browse flags with filtering by state, type, tags
11	- `get-flag`: get full configuration for a single flag in a specific environment
12	- `get-flag-status-across-envs`: check a flag's lifecycle status across all environments
13
14	Optional MCP tools (enhance depth):
15	- `find-stale-flags`: find flags that are candidates for cleanup, sorted by staleness
16	- `get-flag-health`: get combined health view for a single flag (merges status + config)
17	- `check-removal-readiness`: detailed safety check for a specific flag
18
19	## Workflow
20
21	### Step 1: Understand the Project
22
23	Before diving into flag data, establish context:
24
25	1. Identify the project. Confirm the `projectKey` with the user. If they haven't specified one, ask.
26	2. Understand scope. Ask the user what they're trying to accomplish:
27	- Broad audit? ("What's the state of our flags?")
28	- Targeted investigation? ("Is this specific flag still needed?")
29	- Cleanup planning? ("What flags can we remove?")
30
31	### Step 2: Explore the Flag Landscape
32
33	Adapt your approach to the user's goal:
34
35	For a broad audit:
36	- Use `list-flags` scoped to a critical environment (default to `production`).
37	- Note the total count: this tells you the scale of the flag surface area.
38	- Filter by `state` (active, inactive, launched, new) to segment the landscape.
39	- Filter by `type` (temporary vs permanent): temporary flags are the primary cleanup targets.
40
41	For cleanup planning:
42	- Use `find-stale-flags`: this is the most efficient entry point. It returns a prioritized list of cleanup candidates sorted by staleness, categorized as:
43	- `never_requested`: created but never evaluated (possibly abandoned)
44	- `inactive_30d`: no SDK evaluations in the specified period
45	- `launched_no_changes`: fully rolled out, no recent changes
46	- Default `inactiveDays` is 30. Increase for conservative cleanup (60, 90) or decrease for aggressive cleanup (7, 14).
47	- Default `includeOnly` is `temporary`. Set to `all` to include permanent flags.
48
49	For a targeted investigation:
50	- 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.
51	- Or use `get-flag` for the full configuration including rules, targets, and fallthrough details.
52
53	### Step 3: Assess Flag Health
54
55	For flags that need deeper investigation, assess health signals. See [Flag Health Signals](references/flag-health-signals.md) for the full interpretation guide.
56
57	Key signals to evaluate:
58
59	\| Signal \| What it tells you \|
60	\|--------\|-------------------\|
61	\| Lifecycle state \| Where the flag is in its journey (new -> active -> launched -> inactive) \|
62	\| Last requested \| When an SDK last evaluated this flag: staleness indicator \|
63	\| Targeting complexity \| Number of rules and targets: removal complexity indicator \|
64	\| Cross-environment consistency \| Whether the flag behaves the same everywhere \|
65	\| Flag age + temporary status \| Old temporary flags are strong cleanup candidates \|
66
67	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.
68
69	### Step 4: Categorize and Prioritize
70
71	Group flags into actionable categories:
72
73	1. Ready to remove: Inactive everywhere, temporary, no dependencies. Direct the user to the [flag cleanup skill](../launchdarkly-flag-cleanup/SKILL.md) for code removal.
74	2. Likely safe, needs verification: Launched (fully rolled out), no rule changes recently. The user should confirm the rollout is intentionally complete.
75	3. Needs investigation: Active in some environments but not others, or has complex targeting. Don't recommend action without more context.
76	4. Leave alone: Active flags doing their job, or permanent flags that are intentionally long-lived.
77
78	### Step 5: Assess Removal Readiness (When Applicable)
79
80	If the user wants to know whether a specific flag can be removed, use `check-removal-readiness

People who liked this also viewed

6 picks

Type