菜单
Use when the user asks whether an obs-migrate Grafana/Datadog migration is ready for production cutover, wants a final go/no-go, needs a board/customer-ready cutover checklist, or asks what must be validated before switching users from the source observability stack to Kibana.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user wants a readiness assessment, feasibility verdict, "what will/won't migrate", how much manual effort is required, a go/no-go before committing, or to know how confident they can be in the result — assesses how much of a connected Grafana/Datadog environment will migrate cleanly versus need manual rework, and how trustworthy that assessment is. For a plain count/type inventory (no verdict), use scan-o11y-environment instead.
Use when the user wants to connect, authenticate, point the tool at, or verify connectivity/credentials to their Grafana or Datadog instance, or asks "can the tool reach my Grafana/Datadog" / "how do I set up access" — connects the obs-migrate / mig-to-kbn tool to a source observability vendor (Grafana or Datadog) and proves it can actually reach it before any migration.
Use when the user reports a panel rendering empty / "No results found" / "Migration Required" / wrong-shape values after running parity-rig/upload-all.sh or obs-migrate upload, or hands over a Kibana dashboard URL and asks "why is this panel broken" — diagnoses a Kibana dashboard that mig-to-kbn uploaded to the Serverless cluster by driving Chrome via the chrome-devtools MCP server, capturing the per-panel ES|QL the Kibana UI is actually running, the /_query network response, browser console errors, and a screenshot of the failing panel.
Use when the user asks whether their credentials/API key has the right permissions, roles, or privileges to export from their source or to import dashboards / create alert rules into Kibana, or wants to check access before committing to a migration — verifies the credentials have what an obs-migrate / mig-to-kbn migration needs end-to-end — read/export on the source (Grafana/Datadog) and write on the Elastic/Kibana target.
Use when the user asks "why didn't this panel migrate", "what does not_feasible mean here", "how do I fix the panels that need manual work", "explain the warnings", or "how do I rebuild this in Kibana" — explains WHY panels and widgets did NOT migrate cleanly, in plain language, with step-by-step guidance to rebuild them in Kibana. Read-only; reads migration artifacts already on disk. For an overall coverage summary use report-migration-coverage; to numerically verify the panels that DID migrate use validate-side-by-side.
Use when the user has decided to fully switch and wants to "migrate everything", "do the whole environment", "migrate all my dashboards and alerts", or a complete cutover — bulk-migrates EVERY supported dashboard and/or alerting rule from a connected Grafana or Datadog environment into Kibana in one sweep, and reports exactly which assets could not migrate. For a chosen subset use migrate-selected-assets; for a single proof dashboard use try-one-source-dashboard.
| name | prepare-production-cutover |
| description | Use when the user asks whether an obs-migrate Grafana/Datadog migration is ready for production cutover, wants a final go/no-go, needs a board/customer-ready cutover checklist, or asks what must be validated before switching users from the source observability stack to Kibana. |
Goal: turn migration artifacts and existing validation skills into a go/no-go cutover decision. This is the final gate before users stop relying on the source Grafana/Datadog dashboards or alerts. Do not rerun migration just to look decisive; read the artifacts, validate the risky paths, and keep a rollback plan visible.
Assume the user installed the package (obs-migrate on PATH); prefix .venv/bin/ only for a repo checkout.
| What you need | Where to get it |
|---|---|
| Asset scope | <output-dir>/run_summary.json (ran.dashboards, ran.alerts) |
| Dashboard coverage | report-migration-coverage over <output-dir>/dashboards/migration_summary.md and migration_manifest.json |
| Numeric/structural parity | validate-side-by-side over <output-dir>/dashboards/comparison_report.json |
| Gap explanations | explain-migration-gaps for requires_manual, not_feasible, FAIL, SKIP, or unexpected STRUCTURAL panels |
| Alert rule safety | review-and-enable-migrated-alerts over <output-dir>/alerts/*_comparison_results.json and rule-upload results |
| Back-out path | revert-migration for dashboard ids and migrated alert rules |
run_summary.json. If ran.alerts: false, do not claim alert cutover readiness. If dashboards-only was requested, make the cutover decision dashboards-only.report-migration-coverage. Record clean %, needs-review count, blocked count, and manual-effort buckets. Exit code alone is not evidence.validate-side-by-side. Numeric proof applies only where the native PROMQL oracle applies; STRUCTURAL, SKIP, and ERROR are not numeric proof.explain-migration-gaps for non-clean panels and parity failures. A cutover can proceed only if the owner accepts each unresolved gap.remediate-field-mapping-gaps before cutover. Do not label a schema mismatch as a product success.review-and-enable-migrated-alerts. Migrated rules are created disabled; enabling is a separate human gate.obs-migration / [migrated] ...), and who can execute revert-migration.GO, GO WITH CONDITIONS, or NO-GO. Include the evidence that justifies it.not_feasible, parity FAIL is unresolved, alert rules have not been reviewed, required fields are missing, or rollback ownership is unclear.Use a short, auditable readout:
Cutover decision: GO WITH CONDITIONS
Scope: dashboards=true, alerts=false from <output-dir>/run_summary.json
Coverage: <clean>/<total> clean; <needs-review> need review; <blocked> blocked
Validation: <strict/fuzzy/structural/fail/skip summary>; numeric proof only where native oracle applied
Open gaps: <accepted/manual/no-go items>
Rollback: dashboards by id via revert-migration; migrated rules by obs-migration marker via delete-rules dry run + confirm
run_summary.json says alerts did not run or if migrated rules have not been reviewed/enabled deliberately.report-migration-coverage — coverage headline and manual-effort buckets.validate-side-by-side — numeric/structural dashboard parity.explain-migration-gaps — why panels failed or need manual rebuild.remediate-field-mapping-gaps — fix missing fields / empty panels before cutover.review-and-enable-migrated-alerts — alert-rule review and enablement.revert-migration — target-side rollback.