Make o11y → Kibana migration discoverable from the Elastic skills

[miguel-sanchez-elastic]

Problem

Users evaluating a move from Grafana or Datadog to Elastic have no idea our migration tooling exists. The Observability Migration Platform already ships detailed agent skills that walk through every step of a migration — but those skills only reach people who have already found and cloned the project. Anyone working through the official Elastic skills (the front door for Elastic-assisted work) hits a dead end when they think about moving their dashboards, alerts, and monitors.

Why now

The agent surface is the cheapest, fastest way to put migration in front of prospects who don't know it exists, and it differentiates us from competitors whose migration lives behind a paywall or product login. A small discovery skill in the official Elastic skills turns "I wish I could move off Grafana" into "the agent just told me how" — at the exact moment a user is considering Elastic.

User stories

• As a Grafana or Datadog user exploring Elastic, when I ask the agent about moving my dashboards, I'm told the capability exists and pointed to the right tool — without having to know it by name.
• As an SE in a prospect conversation, I can rely on the agent to surface the migration path so I don't have to remember where it lives.
• As a user who's been routed in, I land on the project with a clear next step (install, then migrate) instead of a wall of documentation.

What we'll ship

• A concise discovery skill in the official Elastic skills repo (elastic/cursor-plugins, at skills/observability/<name>/SKILL.md) that recognizes migration intent and routes users to the Observability Migration Platform.
• Clear, honest framing of what the platform does: migrates dashboards, alerts, and monitors from Grafana and Datadog to Kibana, from files or live APIs, with transparent reporting on what didn't carry over.
• A single obvious next step — install the CLI (Effortless install: a one-stop install skill every migration skill relies on #191), then follow the project's detailed skills — rather than re-teaching the whole migration here.
• Honest expectation-setting up front: not everything migrates automatically, unsupported items are surfaced (never hidden), and migrated alerts arrive disabled for review.

Placement note: elastic/cursor-plugins uses a single flat skills/<category>/ layout — it does not use the .claude/skills + .cursor/skills mirroring this project uses. Ship one file there; do not duplicate it. Match the format of neighbors like skills/observability/edot-java-migrate/SKILL.md (frontmatter with name, description, metadata.author: elastic, version).

Success criteria

• A user who never knew the migration tool existed can get from a natural-language question to the project and a first command, guided only by the agent.
• The discovery skill triggers reliably on migration intent phrased in the user's own words (e.g. "switch off Datadog", "move my Grafana dashboards to Elastic").
• Everything the skill claims about the tool is true today — no invented sources, features, or guarantees.
• The skill stays a pointer, not a duplicate: detailed per-step guidance continues to live (and be maintained) in the project's own skills.

Out of scope

• Detailed step-by-step migration guidance (owned by the project's existing skills).
• Sources we don't support yet (New Relic, Splunk, CloudWatch, Prometheus).
• Asset types out of scope for v1 (SLOs, Synthetics, notification channels).

Dependencies

• Effortless install: a one-stop install skill every migration skill relies on #191 (install skill) — this skill routes users to it as the first step, so it should land first or alongside.

Open questions

• Does adding a skill to elastic/cursor-plugins require sign-off from the team that owns that repo, and what's their review bar?
• Should the discovery skill mention pricing/licensing context, or stay purely about capability?