launchdarkly-flag-discovery by launchdarkly/agent-skills
npx skills add https://github.com/launchdarkly/agent-skills --skill launchdarkly-flag-discovery你正在使用一个技能,它将指导你审查和理解 LaunchDarkly 项目中的功能标志情况。你的工作是探索项目,评估其标志的健康状况,识别需要注意的问题,并提供可操作的建议。
此技能要求在你的环境中配置远程托管的 LaunchDarkly MCP 服务器。
必需的 MCP 工具:
list-flags — 通过状态、类型、标签过滤来搜索和浏览标志get-flag — 获取特定环境中单个标志的完整配置get-flag-status-across-envs — 检查标志在所有环境中的生命周期状态可选的 MCP 工具(增强深度):
find-stale-flags — 查找可进行清理的候选标志,按陈旧程度排序get-flag-health — 获取单个标志的综合健康视图(合并状态和配置)check-removal-readiness — 对特定标志进行详细的安全检查广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
在深入研究标志数据之前,先建立上下文:
projectKey。如果用户未指定,请询问。根据用户的目标调整你的方法:
对于广泛的审计:
production)中使用 list-flags。state(active, inactive, launched, new)过滤以划分概况。type(temporary vs permanent)过滤 — 临时标志是主要的清理目标。对于清理规划:
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 获取完整配置,包括规则、目标和回退细节。对于需要深入调查的标志,评估健康信号。完整的解读指南请参见 Flag Health Signals。
需要评估的关键信号:
| 信号 | 它告诉你什么 |
|---|---|
| 生命周期状态 | 标志在其旅程中的位置(new → active → launched → inactive) |
| 最后请求时间 | SDK 上次评估此标志的时间 — 陈旧度指标 |
| 定向复杂性 | 规则和目标的数目 — 移除复杂性指标 |
| 跨环境一致性 | 标志在所有环境中的行为是否一致 |
| 标志创建时间 + 临时状态 | 旧的临时标志是强有力的清理候选对象 |
使用 get-flag-status-across-envs 检查标志在不同环境间是否一致。一个在生产环境中不活跃但在暂存环境中活跃的标志,与在所有环境中都不活跃的标志,情况是不同的。
将标志分组为可操作的类别:
如果用户想知道某个特定标志是否可以移除,请使用 check-removal-readiness。此工具并行编排多个 API 调用,并返回结构化裁决:
safe — 无阻碍或警告。可以继续清理。caution — 存在警告(代码引用、即将到期的目标、永久标志类型)。呈现给用户并让其决定。blocked — 存在硬性阻碍(依赖标志、活跃请求、定向规则)。必须先解决。关于解读每个信号的完整详细信息,请参见 Removal Readiness Checklist。
根据用户的要求构建你的回答:
对于审计: 首先提供摘要(标志总数、按状态和类型细分),然后突出显示需要注意的问题,最后提供具体建议。
对于特定标志: 首先给出裁决(健康 / 需要注意 / 准备移除),然后用你发现的信号来支持它。
对于清理规划: 首先提供清理候选标志的数量,按置信度确定优先级(最安全的移除优先),并链接到清理工作流以执行。
60000 表示 60%。始终转换为人类可读的百分比。每周安装次数
137
仓库
GitHub 星标数
2
首次出现
2026年2月13日
安全审计
安装于
claude-code115
github-copilot75
codex75
opencode74
gemini-cli74
amp74
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.
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, tagsget-flag — get full configuration for a single flag in a specific environmentget-flag-status-across-envs — check a flag's lifecycle status across all environmentsOptional MCP tools (enhance depth):
find-stale-flags — find flags that are candidates for cleanup, sorted by stalenessget-flag-health — get combined health view for a single flag (merges status + config)check-removal-readiness — detailed safety check for a specific flagBefore diving into flag data, establish context:
projectKey with the user. If they haven't specified one, ask.Adapt your approach to the user's goal:
For a broad audit:
list-flags scoped to a critical environment (default to production).state (active, inactive, launched, new) to segment the landscape.type (temporary vs permanent) — temporary flags are the primary cleanup targets.For cleanup planning:
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 periodlaunched_no_changes — fully rolled out, no recent changesinactiveDays is 30. Increase for conservative cleanup (60, 90) or decrease for aggressive cleanup (7, 14).includeOnly is temporary. Set to all to include permanent flags.For a targeted investigation:
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.get-flag for the full configuration including rules, targets, and fallthrough details.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.
Group flags into actionable categories:
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.
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.
60000 means 60%. Always convert to human-readable percentages.Weekly Installs
137
Repository
GitHub Stars
2
First Seen
Feb 13, 2026
Security Audits
Gen Agent Trust HubWarnSocketPassSnykPass
Installed on
claude-code115
github-copilot75
codex75
opencode74
gemini-cli74
amp74
Azure Data Explorer (Kusto) 查询技能:KQL数据分析、日志遥测与时间序列处理
125,100 周安装