
Launchdarkly Metric Choose
Pick primary experiment metrics, guardrails, and rollout events in LaunchDarkly before you attach policies or ship a guarded release.
Overview
LaunchDarkly Metric Choose is an agent skill most often used in Ship (also Grow) that recommends primary metrics, guardrails, and rollout events for LaunchDarkly experiments and release policies using live MCP inventory.
Install
npx skills add https://github.com/launchdarkly/agent-skills --skill launchdarkly-metric-chooseWhat is this skill?
- Surfaces metrics that auto-attach from existing project release policies before recommending additions
- Uses LaunchDarkly MCP list-metrics and list-metric-events to inventory types, keys, and event health
- Optional list-release-policies pass aligns recommendations with current project policy context
- Produces a typed advisory recommendation only—no metric creation or experiment wiring
- Explicitly scoped to experiments, guarded rollouts, and release-policy monitoring questions
- Required MCP tools: list-metrics and list-metric-events
- Optional MCP tool: list-release-policies for policy-aware recommendations
Adoption & trust: 1.3k installs on skills.sh; 16 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to run an experiment or guarded rollout but are unsure which LaunchDarkly metrics are primary, which guardrails matter, and which events are actually receiving traffic.
Who is it for?
Teams already on LaunchDarkly who want MCP-backed metric selection before experiments, guarded rollouts, or release-policy reviews.
Skip if: Builders without the LaunchDarkly MCP server configured, or anyone who needs the skill to create metrics, attach them to flags, or push rollout configuration automatically.
When should I use this skill?
User wants to know which metrics to use, which is primary for an experiment, what guardrails to add, or which events to monitor in a rollout—including surfacing auto-attach from release policies.
What do I get? / Deliverables
You leave with a typed metric recommendation grounded in listed metrics, healthy events, and auto-attached release-policy context—ready to configure the experiment or rollout in LaunchDarkly without guessing measurement.
- Typed recommendation for primary metric, guardrails, and rollout monitor events
- Summary of metrics that will auto-attach from existing release policies
- Inventory notes on metric types, event keys, and recent event health
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Guarded rollouts and release policies are canonical ship work—metrics must be chosen before launch gates and experiment configuration. Launch subphase covers release readiness: which metrics prove success and which guardrails block a bad rollout.
Where it fits
Choose a primary conversion metric and error-rate guardrails before enabling a percentage-based guarded rollout.
Validate which project release-policy metrics will auto-attach so the experiment design does not duplicate or miss required monitors.
Decide which event keys with recent activity should stay on the rollout dashboard after launch.
How it compares
Advisory planning over live LaunchDarkly catalog data—not a generic analytics checklist or a self-contained feature-flag UI tutorial.
Common Questions / FAQ
Who is launchdarkly-metric-choose for?
Solo builders and small teams shipping feature-flagged products who use Claude Code, Cursor, or Codex with the LaunchDarkly MCP server and need defensible experiment and rollout metrics before configuration.
When should I use launchdarkly-metric-choose?
Use it in Ship when scoping a guarded rollout or release policy, in Ship/launch when picking a primary experiment metric, and in Grow when deciding which rollout events to monitor—especially after policies may auto-attach metrics you should account for first.
Is launchdarkly-metric-choose safe to install?
It is advisory and read-oriented via MCP tooling, but it still talks to your LaunchDarkly project; review the Security Audits panel on this page and confirm MCP credentials and scopes before enabling it in production orgs.
SKILL.md
READMESKILL.md - Launchdarkly Metric Choose
# LaunchDarkly Metric Choose You're using a skill that helps users select the right metrics before setting up an experiment, guarded rollout, or release policy. Your job is to understand the feature context, surface what will auto-attach from existing project policies, inventory what's available and healthy, and produce a clear typed recommendation. This skill is advisory. It does not create metrics, attach them to experiments, or configure rollouts. For those tasks, see the related skills at the end of this document. ## Prerequisites This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment. **Required MCP tools:** - `list-metrics` — inventory available metrics with their types and event keys - `list-metric-events` — check which event keys have recent activity **Optional MCP tools (enhance workflow):** - `list-release-policies` — fetch project-level policies that configure which metrics auto-attach to guarded rollouts. Use this for the guarded rollout and release policy paths. ## Workflow ### Step 1: Identify the Context Ask two questions upfront: 1. **What is this for?** - **(a) Experiment** — testing a hypothesis with a flag variant - **(b) Guarded rollout** — progressively rolling out a change with automatic regression detection - **(c) Release policy** — creating or editing a project-wide policy that configures default metrics for all guarded rollouts matching certain conditions 2. **What is the change?** - Flag key (if applicable) - Plain-language description: "Rolling out a new checkout flow" / "Testing a new recommendation algorithm" ### Step 2: Fetch Existing Configuration (Guarded Rollout and Release Policy only) **For experiments — skip this step.** There is no pre-existing configuration to surface. **For guarded rollouts and release policy work**, call `list-release-policies` first: ``` list-release-policies(projectKey) ``` Surface the results before making any recommendations: ``` Your project has 2 release policies: Policy: "Production guardrails" (applies to: environment=production) Auto-attaches to guarded rollouts: ✓ api-error-rate (count, LowerThanBaseline) ✓ p95-latency (value, LowerThanBaseline) ✓ [Metric group] Core Platform Health (3 metrics) Policy: "Default" (applies to: all environments) No metrics configured. ``` This tells the user what's already covered before they choose anything additional. For a guarded rollout, these metrics will appear automatically — the recommendation is about what to add on top, not rebuild from scratch. If no policies exist or none have metrics configured, note that all metrics must be selected manually. ### Step 3: Inventory Available Metrics with Event Health Call `list-metrics` to see all metrics in the project, then cross-reference with `list-metric-events`. Organize into two groups: | Group | Criteria | Note | |-------|----------|------| | **Healthy** | Event key appears in `list-metric-events` | Safe to recommend | | **At-risk** | Event key absent from `list-metric-events` | Warn: may not produce data | Show this inventory before recommending — it may reveal that a metric the user has in mind has no events flowing. ### Step 4: Recommend The reasoning differs meaningfully by context. --- #### (a) Experiment **Start with the hypothesis, not the metric list.** Ask the user to complete this sentence be