Building Dashboards (Axiom)
Designs and deploys Axiom observability dashboards via API, covering APL/MPL queries, chart selection, and Splunk migration.
The skill calls Axiom APIs to create/update dashboards; no malware, credential harvesting, or covert exfiltration. API tokens live in local ~/.axiom.toml; README recommends minimal-privilege tokens. Deductions: dashboard-delete's 'confirm' behavior is asserted but not shown, API-created dashboards are org-wide shared by default (disclosed), no pre-deploy user confirmation, rollback relies on manual get/update, and attribution/maintenance ownership is unverified publisher context only.
High internal consistency: script tables, documented API gotchas (query.mpl rejection, decimals field, $__interval rule), pitfalls table, and failure-feedback guidance (empty-result retry with 7-day window). Deductions: static review only; the sole visible test (jq layout normalization) is truncated and does not cover create/validate key paths; hard dependency on sibling skills and a live API.
Clear triggers (create dashboards, Splunk migration, chart config), audience scenarios, and non-fit boundaries (Axiom-only, sibling-skill dependencies). Deductions: fully bound to Axiom, core function depends on api.axiom.co reachability, no Chinese-language support declared — relevant for mainland-China users.
Well-layered progressive disclosure (SKILL.md plus reference docs), templates, FAQ-style pitfalls, prerequisites. Deductions: no skill-level versioning or changelog, maintenance/update path unclear with unverified publisher, and the skill's Axiom-dashboard content visibly mismatches the hosting repo's PinchBench benchmark theme; MIT license is repo-level, not skill-declared.
Concrete value claim: end-to-end workflow from design blueprint to deploy, templates, migration guide — plausible marginal value. Deductions: static review cannot verify output is directly usable; APL/MPL correctness and script behavior are unreproduced, and the 'verified against working production dashboards' claim is unauditable.
Auditable primary material (script inventory, API gotchas, reference docs) and repo-level lint CI. Deductions: CI covers lint/manifest only, no execution tests over this skill's key paths; key claims are author assertions without third-party corroboration.
- Static review only: no scripts or queries were executed; reliability/effectiveness judgments rest on source reading.
- Skill is fully bound to Axiom and api.axiom.co reachability is unverified from mainland China; no Chinese-language support.
- The skill's Axiom-dashboard content mismatches the hosting PinchBench repository; provenance and maintenance ownership warrant caution.
- Follow the recommendation to use minimal-privilege API tokens in ~/.axiom.toml; dashboards created via API are org-wide visible by default.
- No skill-level versioning/changelog; destructive/write operations (dashboard-delete, chart-patch) rely on script-internal confirmation only.
What does this skill do, and when should you use it?
building-dashboards is a skill that guides an agent to build Axiom dashboards end to end. It creates and updates dashboards through the Axiom API, handling chart type selection, separate APL (events/logs) and MPL (metrics) query paths, SmartFilter interactive filtering, and grid layout. It ships deployment scripts, ready-made templates, and a detailed pitfalls list, suited to teams building from scratch or migrating from Splunk.
Calls the Axiom dashboard API via scripts/dashboard-* scripts (list, get, validate, create, update, per-chart patch, copy, share-link, delete); first classifies each dataset with scripts/metrics/datasets, then discovers schema or metrics via the APL or MPL path; produces dashboard JSON with charts and layout while enforcing unique chart ids and $__interval alignment rules; provides templates (service-overview, api-health, etc.) populated via {{service}} and {{dataset}} placeholders.
- An SRE/DevOps engineer needing a fast oncall dashboard for a live service (error rate, p95/p99 latency, traffic)
- A team migrating from Splunk that must translate SPL panels into APL and map them to Axiom chart types
- A developer creating TimeSeries panels for an otel:metrics:v1 dataset who needs correct MPL syntax and the metricsDataset field
- A platform team adding SmartFilter dropdowns or patching a single chart on an existing dashboard
- An ops lead designing refresh rates and layouts per audience (oncall, team health, executive weekly)
What are this skill's strengths and limitations?
- Complete workflow: dataset classification, schema/metrics discovery, query writing, validation, deployment, and share links
- Distills many production gotchas (query.mpl rejected, getschema returning 0 rows on metrics datasets, the two differing axiom-api scripts)
- Ships multiple templates and reference docs, including a dedicated Splunk migration mapping
- Enforced validation (dashboard-validate, unique-id rules) reduces deploy-time mistakes
- Deeply bound to Axiom's platform, API, and script suite; not usable with Grafana/Datadog or other observability tools
- Templates assume field names (service, status, route, etc.); skipping schema discovery can yield empty panels
- API-token dashboards are org-wide shared only; private dashboards are unsupported
- The repository has no topics listed, and the skill's relationship to PinchBench's benchmarking purpose is not explained in the docs
How do you install this skill?
The skill lives at .agents/skills/building-dashboards/ inside the pinchbench/skill repository, bundled with sibling skills (spl-to-apl, axiom-sre, query-metrics). Place the skills folder in your Agent Skills directory (the exact destination path is not documented). Run scripts/setup to check prerequisites (curl, jq) and configure the deployment url, token, and org_id in ~/.axiom.toml.
How do you use this skill?
Triggers: when a user asks to create an Axiom dashboard, migrate Splunk panels, or configure chart options. Typical flow: 1) run scripts/metrics/datasets <deploy> to identify dataset kind; 2) design panels per the APL or MPL blueprint; 3) validate queries with axiom-sre or scripts/metrics/metrics-query; 4) run scripts/dashboard-validate on the JSON; 5) deploy with scripts/dashboard-create prod ./dashboard.; 6) get the URL via scripts/dashboard-link <deploy> <id> — never construct Axiom URLs manually.
How does this skill compare with similar options?
The source mentions Grafana as an analogy (its datasource also injects $__interval via a preamble) but offers no feature comparison; if you already run Grafana, this skill's value is Axiom-native API automation rather than generic dashboarding.