Update to LaunchDarkly

{
  "name": "alert-investigation",
  "description": "Investigates a triggered observability alert and returns a structured diagnosis with likely cause, scope, and next steps.",
  "included_files": [
    {
      "relative_path": "errors.md",
      "size_in_bytes": 2091
    },
    {
      "relative_path": "logs.md",
      "size_in_bytes": 2208
    },
    {
      "relative_path": "metrics.md",
      "size_in_bytes": 2078
    },
    {
      "relative_path": "sessions.md",
      "size_in_bytes": 2208
    },
    {
      "relative_path": "traces.md",
      "size_in_bytes": 2187
    }
  ],
  "skill_md_contents": "---\nname: alert-investigation\ndescription: \"Investigates a triggered observability alert and returns a structured diagnosis with likely cause, scope, and next steps.\"\nlicense: Apache-2.0\ncompatibility: Requires the remotely hosted LaunchDarkly MCP server\nmetadata:\n  author: launchdarkly\n  version: \"0.1.0\"\n---\n\n# Alert investigation\n\nYou are investigating a specific triggered alert. Alerts arrive with structured context — an alert ID, name, threshold, value that crossed it, and a time range. Your job is to explain *why* it fired, assess *scope*, and recommend *action*.\n\n## Prerequisites\n\nThis skill uses the following LaunchDarkly observability MCP tools:\n\n- `query-logs` — query log records\n- `query-traces` — query distributed traces\n- `query-error-groups` — query error groups\n- `query-sessions` — query sessions\n- `query-aggregations` — query aggregated/time-bucketed metrics\n- `get-keys` — discover available attribute keys before filtering\n\n## Workflow\n\n1. **Parse the alert context.** The first turn of the conversation carries alert variables: `alertID`, `alertName`, `alertValue`, `group`, `groupValue`, `query`, `thresholdWindow`, `timeRange`, plus a product-specific link. Use these, don't re-derive them.\n2. **Load the per-product companion.** Based on the alert's product type, load the matching companion: `logs.md`, `traces.md`, `errors.md`, `sessions.md`, or `metrics.md`. Each captures the per-product investigation shape.\n3. **Run the investigation** using the methodology from the investigate skill (cross-reference logs/traces/errors/sessions/metrics; cite identifiers; aggregate before paginating). Scoped to the alert's time range and filter.\n4. **Produce a structured diagnosis.** See output template below.\n\n## Output template\n\nAlert investigations have a consistent structure so consumers (notification channels, dashboards) can parse them.\n\n```\n## What triggered\n\n<1-2 sentences naming the alert, the threshold, and the value that crossed it.>\n\n## Likely cause\n\n<Root-cause narrative citing specific evidence: trace IDs, log timestamps, error group IDs, flag keys, deploy timing.>\n\n## Scope\n\n<Who or what is affected. Number of users, services, sessions, error groups. Time window of impact.>\n\n## Next steps\n\n<1-3 concrete actions the on-call or owner should take. Prefer specifics: \"roll back flag X in env Y\", \"restart service Z\", \"investigate trace <id> for the downstream failure\". Avoid \"investigate further\" — if you don't have a root cause, say what specifically should be investigated and how.>\n```\n\n## When to load which companion\n\n- **`logs.md`** — log alert, log pattern alert\n- **`traces.md`** — latency alert, trace-error-rate alert, span-specific alert\n- **`errors.md`** — error-rate alert, new-error-group alert, crash-rate alert\n- **`sessions.md`** — session-health alert, user-facing-error-rate alert\n- **`metrics.md`** — custom metric threshold, aggregated metric alert, composite alert\n\nIf the alert crosses product boundaries (e.g. a metric alert driven by error data), load both companions.\n\n## Guidelines\n\n- **Stay tight.** Alert investigations feed notifications — keep the output structured and scannable. No preamble (\"Here is my analysis...\"), no repeated framing.\n- **Cite identifiers.** Every claim in the diagnosis should reference a specific trace ID, error group ID, session ID, or log timestamp.\n- **If the alert appears to be noise**, say so explicitly — \"This alert fired because of <X>, but the underlying behavior is within normal variance because <Y>\". Noise is a legitimate outcome; don't invent root causes.\n- **Don't redo the investigation you just did.** The diagnosis output should let the on-call act without re-querying.\n"
}