launchdarkly-metric-create

Name: launchdarkly-metric-create
Author: launchdarkly

20stars6forks

How to install launchdarkly-metric-create?

launchdarkly/ai-tooling/launchdarkly-metric-create

$npx -y skills add launchdarkly/ai-tooling --skill launchdarkly-metric-create

Installs into the current project.

Summary

Create a LaunchDarkly metric that measures what matters for an experiment or rollout. Use when the user wants to create a metric, track an event, measure page views, button clicks, conversion, latency, error rate, or any custom numeric or binary outcome. Instruments the event fir

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Metric Create
2
3	You're using a skill that will guide you through creating a LaunchDarkly metric. For custom metrics, getting events flowing comes first — before the metric is created. Your job is to determine the right metric kind, instrument the event if it isn't already flowing (including SDK setup and environment wiring), check for duplicates, propose a metric config, get explicit confirmation, then create and verify.
4
5	## Prerequisites
6
7	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
8
9	Required MCP tools:
10	- `create-metric` — create the metric
11	- `get-metric` — verify it after creation
12	- `get-environment` — fetch the client-side SDK key when instrumenting
13
14	Optional MCP tools (enhance workflow):
15	- `list-metrics` — check for existing metrics with the same event key and understand naming conventions
16	- `list-metric-events` — discover which event keys have recent activity before committing to one (custom metrics only)
17
18	## Two Different "Projects" — Never Confuse Them
19
20	Users work with two completely separate things that both get called "project." You must keep these distinct at all times:
21
22	\| \| What it is \| How the user refers to it \| What you do with it \|
23	\|---\|---\|---\|---\|
24	\| LaunchDarkly project \| The project inside the user's LD account where the metric will be created \| Usually sounds like an environment or team name: `my-app`, `anthony-agent-dev-5000`, `production` \| Pass as `projectKey` to all MCP tool calls \|
25	\| Local codebase \| The developer's application on disk that you'll instrument with a `track()` call \| Often a folder name, repo name, or app name: `checkout_proj`, `frontend`, `my-react-app` \| Use to find and edit source files \|
26
27	Rules for resolving these from user input:
28
29	- If the user says "my application at X" or "my codebase" or "my repo" → they mean the local codebase. `X` is a folder path or project name, not a LaunchDarkly key.
30	- If the user says "add it to X" or "in LaunchDarkly" or "my LD project" → they mean the LaunchDarkly project. `X` is the `projectKey` for API calls.
31	- A user can name their local codebase `checkout_proj` while their LaunchDarkly project is `anthony-agent-dev-5000`. These are unrelated.
32	- Never assume the local codebase name is a LaunchDarkly project key. If you're unsure which is which, ask directly: "Just to confirm — what's your LaunchDarkly project key? (This is different from your local app name — you can find it in the LD UI under Account Settings > Projects.)"
33
34	When both are needed (e.g. for a custom metric with instrumentation), confirm each explicitly before proceeding.
35
36	## Workflow
37
38	### Step 1: Determine the Metric Kind
39
40	LaunchDarkly has three metric kinds. Choose the right one before anything else.
41
42	\| Kind \| How events are collected \| Requires \|
43	\|------\|--------------------------\|----------\|
44	\| `custom` \| Developer calls `ldClient.track(eventKey)` in code \| `eventKey` \|
45	\| `pageview` \| Fires automatically when a user visits a matching URL — no SDK call needed \| `urls` (URL match rules) \|
46	\| `click` \| Fires automatically when a user clicks a CSS selector on a matching URL — no SDK call needed \| `urls` + `selector` \|
47
48	Decision rules:
49	- User says "track when someone views a page / visits a URL" → `pageview` (preferred — no instrumentation required)
50	- User says "track when someone clicks a button / link" → `click`
51	- User says "track a custom event" or references a `track()` call → `custom`
52
53	When `pageview` or `click` would work, suggest it over `custom` — it requires no code changes.
54
55	### Step 2: Resolve the Data Source
56
57	For `pageview` and `click` metrics:
58	- Ask for the URL(s) to match. Confirm the `kind` of URL match rule:
59	- `substring` — URL contains this string (most common)
60	- `exact` — URL must match exactly
61	- `canonical` — matches the canonical URL
62	- `regex` — full regex pattern
63	- For `click` metrics, also ask for the CSS selector (e.g. `.checkout-btn`, `#submit`).
64	- Skip `list-metric-events` — these metrics don't use event keys.
65	- Skip to Step 3.
66
67	For `custom` metrics — check events first, instrument if needed:
68
69	Call `list-metric-events` immediately to see which event keys are already flowing:
70
71	```
72	list-metric-events(projectKey, environmentKey?)
73	```
74
75	Case A — the event key is already in the list: Confirm the key with the user and procee

People who liked this also viewed

6 picks

Type

launchdarkly-metric-create

20stars6forks

View on GitHub

How to install launchdarkly-metric-create?

launchdarkly/ai-tooling/launchdarkly-metric-create

$npx -y skills add launchdarkly/ai-tooling --skill launchdarkly-metric-create

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly Metric Create
2
3	You're using a skill that will guide you through creating a LaunchDarkly metric. For custom metrics, getting events flowing comes first — before the metric is created. Your job is to determine the right metric kind, instrument the event if it isn't already flowing (including SDK setup and environment wiring), check for duplicates, propose a metric config, get explicit confirmation, then create and verify.
4
5	## Prerequisites
6
7	This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
8
9	Required MCP tools:
10	- `create-metric` — create the metric
11	- `get-metric` — verify it after creation
12	- `get-environment` — fetch the client-side SDK key when instrumenting
13
14	Optional MCP tools (enhance workflow):
15	- `list-metrics` — check for existing metrics with the same event key and understand naming conventions
16	- `list-metric-events` — discover which event keys have recent activity before committing to one (custom metrics only)
17
18	## Two Different "Projects" — Never Confuse Them
19
20	Users work with two completely separate things that both get called "project." You must keep these distinct at all times:
21
22	\| \| What it is \| How the user refers to it \| What you do with it \|
23	\|---\|---\|---\|---\|
24	\| LaunchDarkly project \| The project inside the user's LD account where the metric will be created \| Usually sounds like an environment or team name: `my-app`, `anthony-agent-dev-5000`, `production` \| Pass as `projectKey` to all MCP tool calls \|
25	\| Local codebase \| The developer's application on disk that you'll instrument with a `track()` call \| Often a folder name, repo name, or app name: `checkout_proj`, `frontend`, `my-react-app` \| Use to find and edit source files \|
26
27	Rules for resolving these from user input:
28
29	- If the user says "my application at X" or "my codebase" or "my repo" → they mean the local codebase. `X` is a folder path or project name, not a LaunchDarkly key.
30	- If the user says "add it to X" or "in LaunchDarkly" or "my LD project" → they mean the LaunchDarkly project. `X` is the `projectKey` for API calls.
31	- A user can name their local codebase `checkout_proj` while their LaunchDarkly project is `anthony-agent-dev-5000`. These are unrelated.
32	- Never assume the local codebase name is a LaunchDarkly project key. If you're unsure which is which, ask directly: "Just to confirm — what's your LaunchDarkly project key? (This is different from your local app name — you can find it in the LD UI under Account Settings > Projects.)"
33
34	When both are needed (e.g. for a custom metric with instrumentation), confirm each explicitly before proceeding.
35
36	## Workflow
37
38	### Step 1: Determine the Metric Kind
39
40	LaunchDarkly has three metric kinds. Choose the right one before anything else.
41
42	\| Kind \| How events are collected \| Requires \|
43	\|------\|--------------------------\|----------\|
44	\| `custom` \| Developer calls `ldClient.track(eventKey)` in code \| `eventKey` \|
45	\| `pageview` \| Fires automatically when a user visits a matching URL — no SDK call needed \| `urls` (URL match rules) \|
46	\| `click` \| Fires automatically when a user clicks a CSS selector on a matching URL — no SDK call needed \| `urls` + `selector` \|
47
48	Decision rules:
49	- User says "track when someone views a page / visits a URL" → `pageview` (preferred — no instrumentation required)
50	- User says "track when someone clicks a button / link" → `click`
51	- User says "track a custom event" or references a `track()` call → `custom`
52
53	When `pageview` or `click` would work, suggest it over `custom` — it requires no code changes.
54
55	### Step 2: Resolve the Data Source
56
57	For `pageview` and `click` metrics:
58	- Ask for the URL(s) to match. Confirm the `kind` of URL match rule:
59	- `substring` — URL contains this string (most common)
60	- `exact` — URL must match exactly
61	- `canonical` — matches the canonical URL
62	- `regex` — full regex pattern
63	- For `click` metrics, also ask for the CSS selector (e.g. `.checkout-btn`, `#submit`).
64	- Skip `list-metric-events` — these metrics don't use event keys.
65	- Skip to Step 3.
66
67	For `custom` metrics — check events first, instrument if needed:
68
69	Call `list-metric-events` immediately to see which event keys are already flowing:
70
71	```
72	list-metric-events(projectKey, environmentKey?)
73	```
74
75	Case A — the event key is already in the list: Confirm the key with the user and procee

People who liked this also viewed

6 picks

Type