$npx -y skills add launchdarkly/ai-tooling --skill create-graphCreates observability dashboards and graphs from logs, traces, errors, sessions, metrics, and events data by previewing charts inline and saving them to a dashboard.
| 1 | # Create graphs and dashboards |
| 2 | |
| 3 | ## Prerequisites |
| 4 | |
| 5 | This skill uses the following LaunchDarkly MCP tools: |
| 6 | |
| 7 | - `preview-graph` — render a chart preview inline without saving it |
| 8 | - `create-graph` — add a chart to an existing dashboard |
| 9 | - `create-dashboard` — create a new empty dashboard |
| 10 | - `list-dashboards` — list existing dashboards |
| 11 | - `get-dashboard` — get the full config of a dashboard, including its graphs |
| 12 | - `get-keys` — discover available metrics, attributes, and keys for a product type |
| 13 | |
| 14 | All of these tools require a `projectKey` (e.g. `"default"`). |
| 15 | |
| 16 | ## Overview |
| 17 | |
| 18 | You are building observability graphs. Your tools are precise — get the enum values wrong and the API rejects the call. Always use `get-keys` before building a query to confirm the dimension names are real. |
| 19 | |
| 20 | ## Capabilities |
| 21 | |
| 22 | - `list-dashboards` — list existing dashboards to check for duplicates or find a target |
| 23 | - `get-dashboard` — get the full config of an existing dashboard, including its graphs |
| 24 | - `create-dashboard` — create a new dashboard |
| 25 | - `preview-graph` — render a chart preview inline |
| 26 | - `create-graph` — add a chart to a dashboard |
| 27 | - `get-keys` — discover available metrics, attributes, and keys for a product type |
| 28 | |
| 29 | When the user's request is purely about visualizing data, stay on task — don't reach for unrelated tools. |
| 30 | |
| 31 | ## Workflow |
| 32 | |
| 33 | 1. **Identify the target dashboard.** If the user already has a specific dashboard in mind (by ID or name), add graphs to it directly. Otherwise, call `list-dashboards` and offer to target an existing one or create a new one with `create-dashboard`. |
| 34 | 2. **Discover the data shape.** Call `get-keys` for the relevant product type before building a query. Attribute names vary across services — `service_name` vs `service.name` vs `serviceName`. Guessing wastes tool calls. |
| 35 | 3. **For ambiguous requests, ask a brief clarifying question** as regular text. Example: "I found several latency-related keys. Would you like P50 or P95 latency, and should I group by service name?" Keep clarifications short — one or two questions max. For minor ambiguity (chart type preference), make a reasonable default and note your assumption. |
| 36 | 4. **Preview before committing.** Call `preview-graph` first, show the user an inline preview, and confirm before calling `create-graph`. For multiple graphs, preview and confirm each one individually. |
| 37 | 5. **Create the graph** with `create-graph`. Use exact enum casing from `enums.md`. |
| 38 | 6. **Confirm what was created** — provide the dashboard URL and a one-line description of what the graph shows. |
| 39 | |
| 40 | ## Duplicating existing graphs |
| 41 | |
| 42 | When asked to duplicate or copy a graph, call `get-dashboard` to retrieve the full configuration (expressions, product type, query, groupBy, display settings), then replicate those values in `create-graph`. Do not guess from the graph title alone — titles drift from the underlying config. |
| 43 | |
| 44 | ## Guidelines |
| 45 | |
| 46 | - **Be concise — don't narrate intermediate tool calls.** Skip prefaces like "First, let me discover the keys" or "Now I'll build the chart." One short sentence at the start of the reply is enough if needed (e.g. "Building a chart of recent logs by level."); after that, just call the tools. |
| 47 | - **Prefer multiple focused graphs over one complex graph.** A dashboard with 3 clean graphs beats one graph with 5 overlapping expressions. |
| 48 | - **Always call `get-keys` before building a query.** Prevents silent empty results from wrong field names. |
| 49 | |
| 50 | ## Chart-type picks |
| 51 | |
| 52 | - **`Line chart`** — time-series trends. Error rates over time, latency percentiles, request volume. |
| 53 | - **`Bar chart`** (or histogram) — comparisons across a dimension. Errors by service, requests by endpoint. |
| 54 | - **`Table`** — detailed breakdowns with multiple dimensions where a chart wouldn't convey the detail. |
| 55 | |
| 56 | ## Aggregators |
| 57 | |
| 58 | - `Count` — total events (most common). Requires `column=""` (empty string). |
| 59 | - `CountDistinct` — unique values. Users, sessions, flag keys. |
| 60 | - `Avg`, `P50`, `P90`, `P95`, `P99` — latency distributions. |
| 61 | - `Sum` — numeric totals (payload size, revenue). |
| 62 | |
| 63 | ## Common mistakes |
| 64 | |
| 65 | - Using lowercase `sessions` for `productType`. It's `Sessions` — PascalCase. See `enums.md`. |
| 66 | - Omitting `column` on a `Count` expression. The API requires it; pass empty string `""`. |
| 67 | - Using `count_distinct` or `Count_distinct`. It's `CountDistinct` — PascalCase, no underscore. |
| 68 | - Building a query without `get-keys` first and getting empty results because the attribute name was wrong. |
| 69 | - Using date-only format (`2026-03-04`) for `get-keys`. Needs full ISO with time: `2026-03-04T00:00:00Z`. |