用途：在 Grafana 中编写和迭代仪表盘，采用 MCP 驱动的工作流：发现指标 → 构建 JSON → 推送到 Grafana → 截图 → 迭代 → 写入 ConfigMap。查询 Prometheus 请用 prometheus 技能，监控资源（告警、ServiceMonitor）请用 monitoring-authoring 技能。
前提条件：在 .mcp.json 中配置 mcp-grafana MCP 服务器；端口转发 kubectl port-forward svc/grafana 3000:80 -n monitoring &；集群内部署 Image Renderer（在 Grafana Helm values 中启用）；匿名认证已启用为 Admin 角色，无需服务账号令牌。
主要能力与用法：不要猜测指标名，先用 MCP 工具发现，如 list_prometheus_metric_names、list_prometheus_metric_metadata、list_prometheus_label_values、query_prometheus。构建仪表盘 JSON 后用 update_dashboard 推送预览（overwrite: true）。Grafana 的 persistence.enabled 为 false，通过 API 推送的仪表盘是临时的，可自由试验。用 get_panel_image 截图做视觉审查，可指定 dashboardUid、panelId、width、height、theme。满意后写入 ConfigMap，需带标签 grafana_dashboard: "true" 供 sidecar 发现，注解 grafana_folder 控制文件夹，data 键与仪表盘 uid 一致，JSON 体用 |-。最后在 kubernetes/platform/config/monitoring/kustomization.yaml 中按字母顺序注册。
结构约定："id" 始终为 null；"graphTooltip" 始终为 1；datasource 始终为 { "type": "prometheus", "uid": "prometheus" }，不要用 ${datasource}；uid 用 kebab-case 且全局唯一。网格宽 24 列：三等分面板 w:8，x 为 0、8、16；四个 stat 面板 w:6，x 为 0、6、12、18；六个紧凑 stat w:4，x 为 0、4、8、12、16、20；行始终 h:1、w:24、x:0，面板从 y: row_y + 1 开始。每个面板必须有 description，说明指标含义、触发告警名及哪个方向为坏。
限制与反模式：猜测指标名会导致空白面板；使用 ${datasource} 变量导入时会出错；面板链接硬编码域名跨集群会失效，应使用 ${internal_domain}；gridPos 坐标重叠会导致面板堆叠错误；缺少 grafana_dashboard: "true" 标签 sidecar 会忽略 ConfigMap；包含 pluginVersion 会在 Grafana 升级时产生变更；"id" 设为具体数字导入时会冲突。更多 JSON 骨架、布局表、面板示例、PromQL 模式、单位与颜色阈值约定见技能内 references 文件。