launchdarkly-flag-discovery

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

LaunchDarkly Flag Discovery

LaunchDarkly 标志发现

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.

你正在使用一个Skill，它将引导你完成LaunchDarkly项目中功能标志的审计和整体情况梳理。你的任务是探索项目、评估标志的健康状况、识别需要关注的内容，并提供可执行的建议。

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

此Skill要求你的环境中已配置远程托管的LaunchDarkly MCP服务器。

必需的MCP工具：

```
list-flags
```
— 按状态、类型、标签筛选来搜索和浏览标志
```
get-flag
```
— 获取特定环境中单个标志的完整配置
```
get-flag-status-across-envs
```
— 检查标志在所有环境中的生命周期状态

可选MCP工具（增强深度）：

```
find-stale-flags
```
— 找出可作为清理候选对象的标志，按过时程度排序
```
get-flag-health
```
— 获取单个标志的综合健康视图（合并状态+配置）
```
check-removal-readiness
```
— 对特定标志进行详细的安全检查

Workflow

工作流程

Step 1: Understand the Project

步骤1：了解项目

Before diving into flag data, establish context:

Identify the project. Confirm the
```
projectKey
```
with the user. If they haven't specified one, ask.
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?")

在深入研究标志数据之前，先确定上下文：

确定项目。 与用户确认
```
projectKey
```
。如果用户未指定，请询问。
了解范围。 询问用户的目标：
- 全面审计？（如“我们的标志现状如何？”）
- 针对性调查？（如“这个特定标志是否还需要？”）
- 清理规划？（如“哪些标志可以移除？”）

Step 2: Explore the Flag Landscape

步骤2：探索标志整体情况

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.

根据用户的目标调整方法：

对于全面审计：

使用
```
list-flags
```
并限定在关键环境（默认是
```
production
```
）。
记录总数量——这能让你了解标志覆盖范围的规模。
按
```
state
```
（活跃、非活跃、已发布、新建）筛选，划分不同的标志群体。
按
```
type
```
（临时 vs 永久）筛选——临时标志是主要的清理目标。

对于清理规划：

使用
```
find-stale-flags
```
——这是最高效的切入点。它会返回按过时程度排序的优先级清理候选列表，分为以下类别：
- ```
never_requested
```
  — 创建后从未被评估（可能已被弃用）
- ```
inactive_30d
```
  — 在指定时间段内无SDK评估
- ```
launched_no_changes
```
  — 已全面推出，近期无更改
默认
```
inactiveDays
```
为30天。若要保守清理可增加天数（60、90），若要激进清理可减少天数（7、14）。
默认
```
includeOnly
```
为
```
temporary
```
。设置为
```
all
```
可包含永久标志。

对于针对性调查：

使用
```
get-flag-health
```
进行单标志深度分析。它会在一次调用中合并状态数据和配置上下文，返回生命周期状态、最后请求时间戳、目标受众摘要、标志时长以及是否为临时标志。
或使用
```
get-flag
```
获取完整配置，包括规则、目标和回退细节。

Step 3: Assess Flag Health

步骤3：评估标志健康状况

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.

对于需要深入调查的标志，评估健康信号。请参阅标志健康信号获取完整的解读指南。

需要评估的关键信号：

信号	说明
生命周期状态	标志处于其生命周期的哪个阶段（新建→活跃→已发布→非活跃）
最后请求时间	SDK最后评估此标志的时间——过时性指标
目标受众复杂度	规则和目标的数量——移除复杂度指标
跨环境一致性	标志在所有环境中的行为是否一致
标志时长 + 临时状态	存在时间久的临时标志是优先级较高的清理候选对象

使用

get-flag-status-across-envs

检查标志在各环境中的一致性。在生产环境中非活跃但在预发布环境中活跃的标志，与在所有环境中都非活跃的标志情况不同。

Step 4: Categorize and Prioritize

步骤4：分类与优先级排序

Group flags into actionable categories:

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

将标志分为可执行的类别：

可立即移除 — 在所有环境中均非活跃、临时标志、无依赖项。引导用户查看标志清理Skill进行代码移除。
大概率安全，需验证 — 已发布（全面推出）、近期无规则更改。用户应确认推出是否已完全完成。
需要调查 — 在部分环境中活跃但其他环境中不活跃，或具有复杂的目标受众配置。在没有更多上下文的情况下，不建议采取行动。
保留 — 正在正常工作的活跃标志，或有意长期存在的永久标志。

Step 5: Assess Removal Readiness (When Applicable)

步骤5：评估移除准备情况（适用时）

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.

如果用户想了解某个特定标志是否可以移除，使用

check-removal-readiness

。此工具会并行协调多个API调用，并返回结构化结论：

safe
— 无阻碍或警告。可继续清理。
caution
— 存在警告（代码引用、即将过期的目标、永久标志类型）。需告知用户并由其决定。
blocked
— 存在硬性阻碍（依赖标志、活跃请求、目标受众规则）。必须先解决这些问题。

请参阅移除准备情况检查表获取解读每个信号的完整细节。

Step 6: Present Findings

步骤6：呈现调查结果

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.

“已发布”指全面推出 — 目标受众已启用，向所有用户提供单一变体，且近期无更改。并不意味着“最近部署”。
“非活跃”并不总是意味着可以安全移除。该标志可能用于尚未发布的代码，或被另一个标志作为先决条件引用。
永久标志可能是有意设置为非活跃的。有些标志设计为在需要前保持休眠状态（如熔断开关、紧急切换器）。不要自动将这些标志标记为清理对象。
API中的权重以1000为缩放单位。权重
```
60000
```
表示60%。请始终转换为人类可读的百分比。
此Skill仅用于发现，不执行操作。如果用户想要从代码中移除标志，请引导他们查看标志清理Skill。如果用户想要更改目标受众配置，请引导他们查看标志目标受众配置Skill。

References

参考资料

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

标志健康信号 — 如何解读生命周期状态、过时性和健康数据
移除准备情况检查表 — 建议移除标志前的完整安全评估细节