Axiom 仪表盘搭建助手（building-dashboards）
通过 Axiom API 设计并部署可观测性仪表盘，覆盖 APL/MPL 查询、图表选型与 Splunk 迁移。
技能主要调用 Axiom API 创建/更新仪表盘，无恶意行为、无凭据收集或隐蔽外传；API token 存于本地 ~/.axiom.toml，README 建议最小权限 token。扣分：dashboard-delete 仅有'confirm'描述而未见实现细节，API 创建的仪表盘默认全员共享（文档已披露），无部署前用户确认机制，rollback 依赖手工 update/get，属共享仓库上下文而非技能自身声明。
文档自洽度高：脚本清单、API 陷阱（query.mpl 被拒、decimals 字段、$__interval 规则）、常见错误表、失败反馈（如空结果重试 7 天窗口）都很详细。扣分：静态审阅未执行；关键路径（创建/验证脚本）仅有一个 jq 归一化测试片段且文件被截断，未覆盖主流程；依赖外部 axiom-sre/query-metrics 技能与真实 API 可用性。
触发条件明确（创建仪表盘、Splunk 迁移、配置图表），受众与场景（oncall/团队/高管）清晰，非适用边界（仅 Axiom、依赖兄弟技能）有披露。扣分：完全绑定 Axiom 生态，核心功能依赖 api.axiom.co 海外可达性，无中文支持声明。
信息架构分层良好（SKILL.md + reference/* 渐进披露），有模板、FAQ 式 pitfalls、前置条件说明。扣分：无技能级版本号/变更日志，维护责任与更新路径依赖未验证的发布者；技能内容（Axiom 仪表盘）与仓库主题（PinchBench 基准）明显错位，provenance 不清；MIT 许可为仓库级而非技能级。
价值主张具体：从设计蓝图到部署的完整工作流、模板与迁移指南，边际价值明确。扣分：静态审阅无法验证输出可直接可用；APL/MPL 查询正确性、脚本行为均未经独立复现，声称的'validated against working production dashboards'不可审计。
有可审计的一手材料（脚本清单、API 陷阱记录、参考文档），且仓库含 lint CI 工作流。扣分：CI 仅覆盖 lint/manifest，无针对本技能关键路径的执行测试证据；主要断言为作者声称（如生产验证），缺乏第三方可复现证据。
- 静态审阅：未执行任何脚本或查询，可靠性/有效性判断仅基于源码阅读。
- 技能完全绑定 Axiom 平台并依赖 api.axiom.co，中国大陆网络可达性未验证；无中文支持。
- 技能主题（Axiom 仪表盘）与所在仓库（PinchBench 基准）明显不符，来源与维护归属需谨慎对待。
- API token 将以最小权限写入 ~/.axiom.toml 的建议应严格执行；API 创建的仪表盘默认对组织全员可见。
- 无技能级版本号/变更日志；dashboard-delete、chart-patch 等破坏性/写入操作仅依赖脚本内的确认提示。
这个 Skill 能做什么，适合哪些场景？
building-dashboards 是一个指导智能体构建 Axiom 仪表盘的技能。它通过 API 创建和更新仪表盘，处理图表类型选择、APL（事件/日志）与 MPL（指标）两种查询路径、SmartFilter 交互过滤和网格布局。技能内置按场景划分的部署脚本、预置模板和常见陷阱清单，适合从零搭建或从 Splunk 迁移的团队。
通过 scripts/dashboard-* 系列脚本调用 Axiom 仪表盘 API（列出、获取、校验、创建、更新、单个图表 patch、克隆、生成分享链接、删除）；先运行 scripts/metrics/datasets 判断数据集类型，再按 APL 或 MPL 路径发现 schema 与指标；生成含 charts 与 layout 的仪表盘 JSON 并强制校验唯一图表 id、$__interval 对齐等规则；提供 service-overview、api-health 等模板，用占位符 {{service}}、{{dataset}} 快速生成配置。
- SRE/DevOps 工程师需要为线上服务快速搭一套 oncall 仪表盘（错误率、p95/p99 延迟、流量）
- 团队从 Splunk 迁移，需要把 SPL 面板翻译成 APL 并映射到 Axiom 图表类型
- 开发者要为 otel:metrics:v1 指标数据集创建时间序列面板，需要正确的 MPL 语法和 metricsDataset 字段
- 平台团队想给现有仪表盘加 SmartFilter 下拉过滤或做单个图表的精准 patch 更新
- 运维负责人需要按受众（oncall、团队健康、高管周报）设计不同的刷新率与布局方案
这个 Skill 有哪些优点和局限？
- 工作流覆盖完整：从数据集类型判定、schema 发现、查询编写、校验到部署和分享链接一步不落
- 沉淀了大量实战陷阱（query.mpl 被拒、getschema 对指标数据集返回空、两个 axiom-api 脚本的区别），可避免常见翻车
- 内置多种模板和参考文档，Splunk 迁移有专门映射指南
- 强制校验机制（dashboard-validate、唯一 id 规则）降低部署出错的概率
- 深度绑定 Axiom 平台及其 API 与脚本体系，无法直接用于 Grafana/Datadog 等其他可观测性工具
- 模板假定字段名（service、status、route 等），不先做 schema 发现就可能查不到数据
- API token 创建的仪表盘只能全组织共享，不支持私有仪表盘
- 仓库主题标签为空，本技能与 PinchBench 基准主业务的关系未在文档中说明
如何安装这个 Skill？
该技能位于 pinchbench/skill 仓库的 .agents/skills/building-dashboards/ 目录，与另两个技能（spl-to-apl、axiom-sre、query-metrics）打包在同一仓库。将 skills 目录放入你的 Agent Skills 目录即可（具体放置路径文档未明确说明）。先运行 scripts/setup 检查依赖（curl、jq），并在 ~/.axiom.toml 中配置部署的 url、token 与 org_id。
如何使用这个 Skill？
触发场景：当用户要求创建 Axiom 仪表盘、从 Splunk 迁移面板或配置图表选项时。典型流程：1) 运行 scripts/metrics/datasets <deploy> 确认数据集类型；2) 按 APL 或 MPL 蓝图设计面板；3) 用 axiom-sre 或 scripts/metrics/metrics-query 校验查询；4) scripts/dashboard-validate 校验 JSON；5) scripts/dashboard-create prod ./dashboard. 部署；6) 用 scripts/dashboard-link <deploy> <id> 获取分享 URL——切勿手工拼接 URL。
这个 Skill 与同类方案有什么区别？
源文档提及 Grafana（其数据源同样通过 preamble 注入 $__interval）作为类比对象，但未做功能对比；若你已在用 Grafana，本技能的价值在于 Axiom 原生 API 自动化而非通用仪表盘能力。