# Launchdarkly metric choose Human Guide

## What This Is For
You're using a skill that helps users select the right metrics before setting up an experiment, guarded rollout, or release policy. It gives the agent a clearer input/output frame for growth marketing: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Launchdarkly metric choose agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for launchdarkly metric choose.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Launchdarkly metric choose guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- `list-metrics` — inventory available metrics with their types and event keys
- `list-metric-events` — check which event keys have recent activity
- `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.
- **(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
- Plain-language description: "Rolling out a new checkout flow" / "Testing a new recommendation algorithm"
- Directly measure the hypothesis
- Have events actively flowing
- Have an unambiguous success direction (`HigherThanBaseline` or `LowerThanBaseline`)
- Bias toward reliability — engineering metrics (error rate, latency, crash rate) with stable, predictable baselines
- Avoid exploratory product metrics that are noisy or hard to interpret under regression analysis

## Decision Points And Nuance
The original skill emphasizes: Prerequisites, Workflow, Step 1: Identify the Context, Step 2: Fetch Existing Configuration (Guarded Rollout and Release Policy only), Step 3: Inventory Available Metrics with Event Health, Step 4: Recommend, (a) Experiment, (b) Guarded Rollout, (c) Release Policy, Step 5: Deliver the Recommendation.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- If no policies exist or none have metrics configured, note that all metrics must be selected manually.
- The primary metric must directly measure that hypothesis — not a proxy, not a correlation. If the user can't complete the sentence, help them get there first.
- **Propose one primary metric.** It must:
- Avoid exploratory product metrics that are noisy or hard to interpret under regression analysis
- **2–3 metrics maximum.** More than that turns the policy into a burden on every rollout, including ones where the metrics don't apply well.
- or remove it from the list to avoid a false rollback trigger.

## Copy-And-Paste Prompt
```text
Use the Launchdarkly metric choose human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the launchdarkly/agent-skills skill entry for `launchdarkly-metric-choose`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# 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.

---