launchdarkly-flag-command

LaunchDarkly 标志命令路由器

你正在使用一项用于规范快速 /flag 请求的技能。你的任务是解析用户意图，以尽可能简便的方式找到所请求的标志，返回可执行的摘要，并在需要时将请求转交给更深入的工作流。

范围边界

此技能是一个只读查询入口。它会返回标志详情并转交后续流程。

硬性限制——你绝不能：

• 创建、切换、更新或删除标志
• 评估标志是否可以安全移除、是否已过时或是否适合清理
• 给出“结论”、“可以安全移除”的判断、移除步骤或“移除前”建议
• 提出归档或删除标志

当用户询问移除或过时问题时，你对此部分的完整回复必须是标志摘要表，后接以下准确的路由消息（可以稍作改写，但必须保留原意）：

此快速查询只能显示标志的当前配置。若要评估是否可以安全移除，你需要使用 flag discovery 或 flag cleanup 技能——这些技能会扫描代码引用、检查所有环境中的状态，并分析下游依赖关系。

仅此而已。不要分析。不要使用项目符号。不要给出结论。移除问题由路由消息回答，而不是由你回答。

前提条件

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

必需的 MCP 工具：

• list-flags — 搜索并区分候选标志
• get-flag — 获取已确认标志的详细配置

可选的 MCP 工具：

• get-flag-status-across-envs — 比较各环境中的生命周期状态
• get-flag-health — 快速查看单个标志的健康状态

命令约定

将以下形式视为等效意图：

• /flag <query>
• flag <query>
• "find flag "
• "show me flag"

除非用户指定其他环境，否则默认使用 production。

工作流

步骤 1：解析并规范化输入

1. 提取 /flag 后的查询文本。
2. 如果未提供查询，请用户给出一个简洁的标识符（标志 key、名称片段或标签）。
3. 获取请求中的可选提示：
   • 环境（staging、production 等）
   • 项目 key
   • 偏好精确 key 匹配还是模糊搜索

步骤 2：确认标志

除非用户明确提供了精确 key 和项目，否则先使用 list-flags。

1. 使用查询调用 list-flags 进行搜索。
2. 如果存在一个明确的精确匹配项，则确认该标志。
3. 如果存在多个可能的匹配项，则返回简短的消歧列表（key + 名称 + 状态），并请用户选择。
4. 如果没有匹配项，则告知用户，并建议使用范围更广的查询。

步骤 3：返回实用摘要

对于已确认的标志，调用 get-flag 并返回：

1. 标志 key 和名称
2. 环境状态（on/off）
3. 关闭时的变体和回退行为
4. 规则/目标复杂度（简单或复杂）
5. 标志的直接 LaunchDarkly URL（已知项目 + key 时）

如果用户询问移除、过时或清理问题（例如：“可以安全移除吗？”、“我可以清理一下吗？”、“这个过时了吗？”）：

仅显示上述摘要表，然后写入：

此快速查询只能显示标志的当前配置。若要评估是否可以安全移除，你需要使用 flag discovery 或 flag cleanup 技能——这些技能会扫描代码引用、检查所有环境中的状态，并分析下游依赖关系。

不要添加结论、项目符号分析、移除步骤、“移除前”检查清单，也不要提出归档/删除。移除问题已由上述路由消息完整回答。继续执行步骤 4。

第 4 步：转到合适的后续工作流

返回摘要后，检查用户的请求是否意味着需要执行更深入的工作流。如果是，说出技能名称并停止——不要自行尝试执行该工作流。

用户意图	转到
创建或修改标志	标志创建技能
更改定向或逐步发布	标志定向技能
“移除这个安全吗？”，“这个是否已过时？”，清理	标志发现 / 标志清理

对于移除或过时相关的问题：遵循上文的范围边界说明——仅提供摘要表，然后转到相应技能。不要给出结论。

输出风格

让 /flag 响应简洁且便于执行：

• 以已确认的标志（或消歧列表）开头
• 仅包含执行下一步所需的最少配置详情
• 如果用户意图不明确，以一个清晰的下一步问题结尾

重要背景

• /flag 是快速入口，而非完整的生命周期工作流。
• 如果有多个标志匹配，优先消歧，不要猜测。
• 将项目和环境视为一等上下文；避免隐含假设。
• 分享逐步发布百分比时，始终使用易读的百分比格式。
• 绝不要自行分析移除、过时或清理问题。 始终转到专用技能。