launchdarkly-flag-discovery

LaunchDarkly 功能标志发现

你正在使用一项技能，它将引导你审计并理解 LaunchDarkly 项目中的功能标志全貌。你的工作是探索该项目、评估其标志的健康状况、识别需要关注的内容，并提供可操作的建议。

前提条件

此技能要求在你的环境中配置远程托管的 LaunchDarkly MCP 服务。

必需的 MCP 工具：

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

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

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

工作流

第 1 步：了解项目

在深入标志数据之前，先建立背景信息：

1. 确定项目。 与用户确认 projectKey。如果他们尚未指定，请询问。
2. 了解范围。 询问用户想要达成什么目标：
   • 广泛审计？（“我们的标志现状如何？”）
   • 针对性调查？（“这个特定标志还需要吗？”）
   • 清理规划？（“我们可以移除哪些标志？”）

第 2 步：探索标志全貌

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

对于广泛审计：

• 使用 list-flags，范围限定在一个关键环境（默认为 production）。
• 记录总数：这能告诉你标志覆盖面的规模。
• 按 state（active、inactive、launched、new）筛选以划分全貌。
• 按 type（临时与永久）筛选：临时标志是主要的清理目标。

对于清理规划：

• 使用 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 获取完整配置，包括规则、目标和 fallthrough 详情。

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

对于需要深入调查的标志，评估健康信号。完整解读指南见 Flag Health Signals。

需要评估的关键信号：

信号	它告诉你的信息
生命周期状态	标志处于其生命周期的哪个阶段（new -> active -> launched -> inactive）
最后请求时间	SDK 最后一次评估此标志的时间：陈旧程度指标
定向复杂度	规则和目标的数量：移除复杂度指标
跨环境一致性	该标志在各处的行为是否相同
标志存在时长 + 临时状态	存在时间长的临时标志是强有力的清理候选

使用 get-flag-status-across-envs 检查某个标志在各环境中是否一致。在生产环境中不活跃但在预发环境中活跃的标志，与在所有环境中都不活跃的标志所反映的情况截然不同。

步骤 4：分类并确定优先级

将标记归入可操作的类别：

1. 可移除：在所有环境中均不活跃、临时性、无依赖。引导用户使用标记清理技能进行代码移除。
2. 可能安全，但需验证：已发布（完全推出）、近期无规则变更。用户应确认推出是有意完成的。
3. 需调查：在某些环境中活跃但在其他环境中不活跃，或具有复杂的目标定位。在没有更多上下文的情况下不要建议采取行动。
4. 保持不动：正在正常发挥作用的活动标记，或有意长期存在的永久标记。

步骤 5：评估移除就绪状态（如适用）

如果用户想知道某个特定标记是否可以移除，请使用 check-removal-readiness。该工具并行编排多个 API 调用，并返回结构化的结论：

• safe：没有阻塞项或警告。可继续清理。
• caution：存在警告（代码引用、即将过期的目标、永久标记类型）。呈现给用户，让其决定。
• blocked：存在硬性阻塞项（依赖标记、活动请求、目标定位规则）。必须先解决。

有关如何解读每种信号的完整细节，请参阅移除就绪检查清单。

步骤 6：呈现发现

根据用户的请求来组织你的回复：

对于审计： 先给出摘要（标记总数、按状态和类型细分），然后突出需要关注的内容，最后提供具体建议。

对于特定标记： 先给出结论（健康 / 需要关注 / 可以移除），然后用你发现的信号加以支持。

对于清理规划： 先给出清理候选数量，按置信度确定优先级（最安全的移除优先），并链接到清理工作流以执行。

重要背景

• "Launched" 意味着完全推出：目标定位已开启，向所有人提供单一变体，且近期没有进行任何更改。它不意味着"最近部署"。
• "Inactive" 并不总是意味着可以安全移除。 该标记可能用于尚未发布的代码中，或被另一个标记引用为先决条件。
• 永久标记可能是有意处于不活跃状态的。 有些标记被设计为休眠状态，直到需要时才启用（终止开关、紧急切换）。不要自动将这些标记列为清理对象。
• API 中的权重按 1000 缩放。 权重 60000 表示 60%。请始终转换为人类可读的百分比。
• 此技能用于发现，而非操作。 如果用户想从代码中移除标记，请引导他们使用标记清理技能。如果他们想更改目标定位，请引导他们使用标记目标定位技能。

参考资料

• 标记健康信号：如何解读生命周期状态、陈旧度和健康数据
• 移除就绪检查清单：在建议移除标记之前的完整安全评估