用途：以迭代产品流程创建 Grafana 仪表盘，而非一次性写清单。循环为：理解目标→发现数据→编写仪表盘→校验/推送→快照→检查→修订。推送成功不算完成，须经视觉检查或说明快照受阻原因。仅操作已有仪表盘（列表、搜索、拉取、推送、提升、恢复、删除、一次性快照）应改用 manage-dashboards。
主要能力与规则：不得在任意/默认文件夹创建；目标上下文或文件夹不明确且会写入时，只问一个简洁问题。用户已给出上下文、文件夹、数据源或标题时按假设继续。写入前验证 gcx 上下文；添加面板前验证数据源、指标、标签与日志字段，不得臆造 PromQL、LogQL、数据源 UID、标签名或文件夹 UID。优先沿用项目既有约定。用 gcx dashboards snapshot 做视觉反馈，渲染 PNG 后须用图像/读取工具检查，不能只报路径。首次快照后若出现登录页、变量错误、主面板为空、标题截断、布局破损、图例不可读或首屏分诊差等问题，至少迭代一次。优先用专用 gcx 命令而非 gcx api。
必要用法：先运行 gcx config current-context、gcx config check、gcx config list-contexts 验证上下文与权限，后续命令可用 --context <name>。用 gcx resources get folders -o json 找文件夹，gcx dashboards search 找相似仪表盘，并用 --api-version dashboard.grafana.app/v1beta1 固定版本。用 gcx datasources list 及 prometheus/loki/tempo/pyroscope 的 labels 子命令发现数据。编写可选两种模式：既有 resources-as-code 项目按仓库模式，或用 gcx dev generate 生成桩；独立清单用 gcx resources list-types dashboards 获取 schema，创建 ./resources/dashboards/<name>.yaml，文件夹通过 metadata.annotations 的 grafana.app/folder 指定，spec 内无 folderUID 字段。随后 gcx resources validate、push --dry-run、push，并用 gcx resources get 验证。快照示例：GCX_AGENT_MODE=true gcx dashboards snapshot <dashboard-name> --output-dir ./snapshots --since 6h --var cluster=<cluster> --var namespace=<namespace> --width 1920 --theme dark；可疑面板可加 --panel <panel-id>。
适用场景：需要新建 Grafana 仪表盘并做视觉验证的运维/SRE 分诊场景。限制：快照失败须报告具体类别（缺少图像渲染器、认证/RBAC、变量错误、渲染超时或命令错误），不得声称已视觉审查；若仪表盘受其他 manager 注解保护须停止，仅在用户明确要求时用 --include-managed。其他细节资料未提供。