Agent skill

Axiom Dashboard Builder

by openclaw in openclaw/clawhub

Designs and deploys Axiom dashboards through the API, choosing chart types and writing APL or metrics queries, with templates and migration notes for Splunk and Grafana.

MITAuto-check passedDevOps & Cloud

Install Axiom Dashboard Builder

skills CLI
$ npx skills add openclaw/clawhub --skill building-dashboards -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openclaw/clawhub building-dashboards --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openclaw/clawhub.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/building-dashboards .claude/skills/building-dashboards && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
building-dashboards
GitHub stars
9.5k
Token cost
~4.9k tokens
SKILL.md length
2,064 words
Files
51 (incl. scripts)
Skills in repo
55
Repo updated
First seen
Licence
MIT

At a glance

Designs and deploys Axiom dashboards through the API, choosing chart types and writing APL or metrics queries, with templates and migration notes for Splunk and Grafana.

  • Works in 8 steps: At-a-Glance (Statistic panels) → Trends (TimeSeries panels) → Breakdowns (Table/Pie panels) → …
  • Creating an Axiom dashboard from a plain-language description
  • SKILL.md covers Philosophy, Entry Points, Intake: What to Ask First and Dashboard Blueprint, plus 12 more sections
  • Migrating a Splunk or Grafana dashboard to Axiom

What it does

The skill guides an agent through building an Axiom dashboard from a vague request, a template, an existing Splunk or Grafana dashboard, or an exploration of live data. It starts with intake questions about the audience, such as on-call triage, team health or executive reporting, and about scope. It then checks the dataset kind to choose between the APL path for events and logs and the metrics path that uses MPL.

Its design rules favor one question per panel, rates and percentiles over averages, and an overview-to-drilldown-to-evidence flow. Fields have to be discovered from the schema rather than guessed, and a panel that cannot be computed is replaced with a Note explaining the blocker instead of showing a different quantity. The folder includes helper scripts, reference notes on chart config, layout recipes, SmartFilters and PromQL-to-MPL translation, and JSON templates such as api-health and service-overview.

When your agent uses it

  • Creating an Axiom dashboard from a plain-language description
  • Migrating a Splunk or Grafana dashboard to Axiom
  • Adding SmartFilters or adjusting chart options on a dashboard
  • Turning exploratory queries into an on-call overview

Example prompts

  • “Build an Axiom dashboard for the checkout service showing error rate and latency.”
  • “Convert this Grafana dashboard export into an Axiom dashboard.”
  • “Start from the api-health template and point it at our production API dataset.”

Requirements

  • Access to the Axiom API for the target deployment

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. At-a-Glance (Statistic panels)
  2. Trends (TimeSeries panels)
  3. Breakdowns (Table/Pie panels)
  4. Evidence (LogStream + SmartFilter)
  5. At-a-Glance (Statistic panels)
  6. Trends (TimeSeries panels)
  7. Breakdowns (TimeSeries or Table panels)
  8. Entity State (TimeSeries or Table panels)

What it can do on your machine

Read from SKILL.md and the folder at commit d044664. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/, which the agent can run.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • axiom.co

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Axiom Dashboard Builder loads about 4.9k tokens when it runs. Until then it costs about 63 tokens; SKILL.md has 2,064 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~63
When it runs · the whole SKILL.md, loaded when a task matches
~4.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from openclaw/clawhub at commit d044664, republished under its MIT licence (© openclaw). 2,064 words, ~4,947 tokens.

Download SKILL.mdSave it as .claude/skills/building-dashboards/SKILL.md (or your agent's skills folder). This skill also uses 50 other files; get the full folder from GitHub.
name
building-dashboards
description
Designs and builds Axiom dashboards via API. Covers chart types, APL and metrics/MPL query patterns, SmartFilters, layout, and configuration options. Use when creating dashboards, migrating from Splunk, or configuring chart options.

Building Dashboards

Philosophy

  1. Decisions first. Every panel answers a question that leads to an action.
  2. Overview → drilldown → evidence. Start broad, narrow on click/filter, end with raw logs.
  3. Rates and percentiles over averages. Averages hide problems; p95/p99 expose them.
  4. Simple beats dense. One question per panel. No chart junk.
  5. Validate with data. Never guess fields—discover schema first.
  6. Compute what's asked, or defer. If a panel can't be computed, replace it with a Note documenting the blocker. Never substitute a different quantity, even disclosed. See Compute or Defer.

Entry Points

Starting fromWorkflow
Vague descriptionIntake → check dataset kind → design blueprint (APL or MPL) → queries per panel → deploy
TemplatePick template → customize dataset/service/env → deploy
Splunk dashboardExtract SPL → translate via spl-to-apl → map to chart types → deploy
Grafana dashboardProject canonical panel spec (expr, legendFormat, unit, title, description) → translate PromQL → map chart types → deploy. See reference/grafana-migration.md.
ExplorationUse axiom-sre to discover schema/signals → productize into panels

Intake: What to Ask First

  1. Audience & decision

    • Oncall triage? (fast refresh, error-focused)
    • Team health? (daily trends, SLO tracking)
    • Exec reporting? (weekly summaries, high-level)
  2. Scope

    • Service, environment, region, cluster, endpoint?
    • Single service or cross-service view?
  3. Dataset kind. Run scripts/metrics/datasets <deploy> and check kind.

    • otel:metrics:v1 → metrics dataset, follow the Metrics path.
    • anything else → events/logs dataset, follow the APL path.

    Never run getschema on a metrics dataset. It returns 0 rows without error.

    APL path: discover fields with ['dataset'] | where _time between (ago(1h) .. now()) | getschema. Continue to steps 4–5.

    Metrics path:

    • scripts/metrics/metrics-spec <deploy> <dataset> — required before any MPL query.
    • scripts/metrics/metrics-info <deploy> <dataset> metrics | tags | tags <tag> values for discovery.
    • If discovery is empty, retry with --start 7 days ago (sparse metrics).
    • find-metrics <value> searches tag values, not metric names — use it only with a known entity name.
    • Skip to the Metrics/MPL Blueprint.
  4. Golden signals (APL path)

    • Traffic: requests/sec, events/min
    • Errors: error rate, 5xx count
    • Latency: p50, p95, p99 duration
    • Saturation: CPU, memory, queue depth, connections
  5. Drilldown dimensions (APL path)

    • What do users filter/group by? (service, route, status, pod, customer_id)

Dashboard Blueprint

Pick the blueprint matching the dataset kind.

APL Blueprint (events/logs datasets)
1. At-a-Glance (Statistic panels)

Single numbers that answer "is it broken right now?"

  • Error rate (last 5m)
  • p95 latency (last 5m)
  • Request rate (last 5m)
  • Active alerts (if applicable)

Time-based patterns that answer "what changed?"

  • Traffic over time
  • Error rate over time
  • Latency percentiles over time
  • Stacked by status/service for comparison
3. Breakdowns (Table/Pie panels)

Top-N analysis that answers "where should I look?"

  • Top 10 failing routes
  • Top 10 error messages
  • Worst pods by error rate
  • Request distribution by status
4. Evidence (LogStream + SmartFilter)

Raw events that answer "what exactly happened?"

  • LogStream filtered to errors
  • SmartFilter for service/env/route
  • Key fields projected for readability
Metrics/MPL Blueprint (metrics datasets)

Use align to $__interval using … for bucketing — $__interval is supplied by the dashboard runtime. Hard-coded windows over- or under-resolve. Validate every pipeline with scripts/metrics/mpl-validate-chart; both it and chart-add --mpl reject inline time ranges ([1h..]).

Exception: for sparse metrics where $__interval rounds to empty buckets, a fixed wider window (e.g. 1h) is acceptable; document why on the chart.

1. At-a-Glance (Statistic panels)

Current values — "what's the state right now?"

  • Use group using avg (gauges) or group using last (counters).
  • Read the metric's unit via metrics-info … metrics <m> info and pass it to chart-add --unit. Ratio metrics (0–1) need | map * 100 in MPL before --unit "%".

Trends over time — "what changed?"

  • align to $__interval using avg|sum|last.
  • Group by low-cardinality tags only (≤10 series per chart).
  • Embed the unit in --name ("P95 Latency (ms)", "Memory (MiB)"); scale magnitudes in MPL (| map / 1048576 for bytes → MiB).
3. Breakdowns (TimeSeries or Table panels)

Per-entity detail — "where should I look?"

  • Metrics broken down by entity (host, pod, service).
  • Filter to keep series count manageable.
  • One dimension per panel; don't overload a single chart.
4. Entity State (TimeSeries or Table panels)

Boolean/state metrics — answer "what is on/off/active?"

  • Use align to $__interval using last.
  • Sparse state metrics may need a fixed wider interval (1h+).

Required Chart Structure

Each chart needs a unique kebab-case id (error-rate, p95-latency); every layout i must match one. Pass the same id to chart-add --id and layout-pack <id>:…. dashboard-assemble cross-checks before emit.


Chart Unit Configuration

Pass a friendly unit string to chart-add --unit ("%", "s", "ms", "B", "req/s"). The script picks unit enum + customUnits suffix per chart type. customUnits is a label, not a formatter — scale magnitudes in MPL (| map / 1048576 for bytes → MiB, | map / 1000000 for bytes → MB, | map * 100 for 0–1 ratio → percent). For metrics charts, read the source unit from metrics-info … metrics <m> info and pass it through. Internals (advanced options the agent may merge with jq): reference/chart-config.md.


Compute or Defer

Each panel either computes the requested quantity, or it's replaced by a Note documenting the blocker. Substituting a different quantity is never acceptable — disclaimers don't reach whoever acts on the number.

Defer template (use chart-add --type Note):

**Deferred — blocked by:** <one-line reason>.

**Original spec:** <what the panel should compute, dimensions, unit>.

**To unblock:** <pointer to the fix>.

Common blockers: MPL parser limits, missing tag with no reverse-tag equivalent, missing metric with no OTel rename match. Full rationale: reference/design-playbook.md § Substituting a Different Quantity.


Chart Types

TypeWhenKey constraint
StatisticSingle KPI, current valueQuery must return one row.
TimeSeriesTrends over time, percentile overlaysbin_auto(_time); percentiles_array() for multi-percentile.
TableTop-N lists, breakdownsBound with top N; control columns via project.
PieShare-of-total for ≤6 categoriesAggregate to ≤6 slices; never high-cardinality.
LogStreamRaw event inspectiontake 100–500; project-keep to relevant fields; filter hard.
HeatmapDistribution / latency densitysummarize histogram(field, buckets) by bin_auto(_time).
Scatter PlotCorrelate two metrics per groupsummarize avg(x), avg(y) by group.
SmartFilterInteractive filter barEach panel query needs declare query_parameters. See reference/smartfilter.md.
Monitor ListMonitor status displayNo APL — select monitors in UI.
NoteMarkdown context, headers, runbook linkschart-add --type Note --text "<md>".

Per-type APL recipes: reference/chart-cookbook.md.


Chart Configuration

chart-add covers the common path (type, id, name, query, dataset, unit, sparkline). For options it doesn't expose — aggChartOpts variants on TimeSeries, tableSettings.columns on Table/LogStream, hideHeader, etc. — start from a chart-add output and merge the extra fields with jq. See reference/chart-config.md for the full option set, and the rejected-field list before merging anything bespoke.


APL Patterns

Time Filtering

Dashboard chart queries inherit time from the picker — omit _time filters. Ad-hoc queries (Axiom Query tab, axiom-sre) need an explicit where _time between (ago(1h) .. now()).

Bin Size Selection

Use bin_auto(_time) — it adjusts to the dashboard time window. Manual bin(_time, …) is only justified for non-standard cases (e.g. matching an upstream batch interval); document why.

Cardinality Guardrails

Bound summarize … by … with top N or a filter. Unbounded grouping on high-cardinality fields (user_id, trace_id) blows up.

apl
| summarize count() by route | top 10 by count_   // bounded
| summarize count() by user_id                    // unbounded — avoid
Field Escaping

Fields with dots need bracket notation:

apl
| where ['kubernetes.pod.name'] == "frontend"

Fields with dots IN the name (not hierarchy) need escaping:

apl
| where ['kubernetes.labels.app\\.kubernetes\\.io/name'] == "frontend"
Recipes

Traffic, error-rate, latency-percentile, and other golden-signal APL recipes: reference/chart-cookbook.md.


Layout Composition

layout-pack packs charts row-major into the 12-column grid using per-type defaults (Statistic 3×3, TimeSeries 6×4, Table 6×5, LogStream 12×6, Note 12×2). Override with id:WxH when needed. Section blueprints: reference/layout-recipes.md. Naming and panel-ordering conventions: reference/design-playbook.md.


Dashboard Settings

Refresh Rate

dashboard-assemble --refresh oncall|team|exec (60/300/900s) or pass an explicit integer (≥60). Short refresh + long time range = expensive queries; pick the longer end for exec/weekly boards.

Sharing

API tokens create shared dashboards only (owner: "X-AXIOM-EVERYONE"); private dashboards aren't supported. Per-user data visibility is still enforced by dataset permissions.

URL Time Range Parameters

?t_qr=24h (quick range), ?t_ts=...&t_te=... (custom), ?t_against=-1d (comparison)


Setup

Tools, prerequisites, and ~/.axiom.toml configuration: see README.md. Verify with scripts/setup.


Deployment

Show full SKILL.md (828 more words)Show less
Scripts
ScriptUsage
scripts/chart-add --type <T> --id <id> --name <n> [--apl <q> | --mpl <q> --dataset <d>] [--unit <u>]Emit a single chart JSON to stdout. Splits APL vs MPL; MPL queries are checked for inline time ranges; unit fields applied per chart type.
scripts/layout-pack <id>:<Type|WxH> ...Emit a layout JSON array to stdout. Row-major into a 12-column grid; type names map to default sizes.
scripts/dashboard-assemble --name … --datasets … --layout F.json [opts] CHART_FILES…Compose a complete dashboard JSON from chart files + layout. Owns the envelope (owner, schemaVersion, qr- prefix, refreshTime validation, id cross-checks).
scripts/dashboard-list <deploy>List all dashboards
scripts/dashboard-get <deploy> <id>Fetch dashboard JSON
scripts/dashboard-validate <file>Validate JSON structure
scripts/dashboard-create <deploy> <file>Create dashboard
scripts/dashboard-update <deploy> <id> <file>Update (needs version)
scripts/dashboard-chart-patch <deploy> <id> <chart-id> <patch-file> (--version <version> | --overwrite)Patch one chart
scripts/dashboard-copy <deploy> <id>Clone dashboard
scripts/dashboard-link <deploy> <id>Get shareable URL
scripts/dashboard-delete <deploy> <id>Delete (with confirm)
scripts/axiom-api <deploy> <method> <path>Dashboard/app API only (rewrites to app.*). For data/metrics endpoints use scripts/metrics/axiom-api
scripts/metrics/axiom-api <deploy> <method> <path>Data/metrics API (supports AXIOM_URL_OVERRIDE for edge routing)
scripts/metrics/datasets <deploy>List datasets with kind and edge deployment
scripts/metrics/metrics-spec <deploy> <dataset>Fetch MPL query specification
scripts/metrics/metrics-info <deploy> <dataset> ...Discover metrics, tags, and values
scripts/metrics/metrics-query <deploy> <mpl> <start> <end>Execute a metrics query (raw — no $__interval injection)
scripts/metrics/mpl-validate-chart <deploy> '<MPL>' [start] [end] [--interval D]Validate a chart MPL pipeline. Auto-injects param $__interval: Duration; and -p __interval=…; rejects inline time ranges. Use this in place of raw metrics-query when authoring chart queries.

The two axiom-api scripts are not interchangeable. scripts/axiom-api is for the dashboard app API; scripts/metrics/axiom-api is for data/metrics endpoints and edge routing. Wrong one → 404.

Targeted Chart Updates

Use scripts/dashboard-chart-patch when changing one existing chart and the dashboard layout, metadata, and other charts should remain untouched. It calls PATCH /v2/dashboards/uid/{uid}/charts/{chartId} with a JSON Merge Patch under the chart request field.

Patch files contain only the chart fields to change:

json
{
  "name": "Error Rate (5m)",
  "query": { "apl": "['logs'] | summarize errors=countif(status >= 500)" },
  "config": { "stale": null }
}

null removes an existing field. Nested objects merge recursively. If id is present in the patch, it must match the <chart-id> path argument. The server validates the resulting full dashboard before saving.

Use --version <version> for optimistic concurrency after fetching the dashboard with dashboard-get. Use --overwrite only when last-write-wins behavior is intended. Continue using dashboard-update for layout changes, multi-chart edits, dashboard metadata, owner, refresh interval, or time window updates.

Workflow

chart-add, layout-pack, and dashboard-assemble own the JSON shape. Each chart lives in its own temp file; nothing chart-shaped re-enters the agent's context.

  1. Discover schema (axiom-sre / getschema for events; metrics-spec + metrics-info for metrics).
  2. Write each panel query. Validate APL via axiom-sre with an explicit time filter; validate MPL via scripts/metrics/mpl-validate-chart.
  3. chart-add --type … --apl '<APL>' or chart-add --type … --mpl '<MPL>' --dataset <name> per chart, redirected to its own file.
  4. layout-pack <id>:<Type|WxH> … for the layout (ids in display order).
  5. dashboard-assemble --name … --datasets … --layout LAYOUT CHART_FILES… to compose.
  6. dashboard-validate then dashboard-create (or dashboard-update).
  7. dashboard-link for the URL — never hand-construct.

Sibling Skill Integration

  • spl-to-apl — Splunk SPL → APL (timechart → TimeSeries, stats → Statistic/Table). See reference/splunk-migration.md.
  • axiom-sre — schema discovery via getschema, baseline exploration.
  • query-metrics — metrics dataset/tag/value discovery; same scripts vendored under scripts/metrics/.

Templates

Compose with chart-add + layout-pack + dashboard-assemble. Pre-built templates remain under reference/templates/ (blank.json, service-overview.json, service-overview-with-filters.json, api-health.json) for legacy use; dashboard-from-template instantiates them but assumes specific field names (service, status, route, duration_ms) and needs sed-fixing. Prefer composition for new work.


Common Pitfalls

ProblemCauseSolution
getschema returns 0 rowsDataset is otel:metrics:v1Use scripts/metrics/metrics-info for metrics discovery.
Metrics discovery returns emptySparse metrics outside the 24h default windowRetry with --start 7 days ago.
404 from metrics API callsUsed scripts/axiom-api (dashboard) instead of scripts/metrics/axiom-apiUse scripts/metrics/axiom-api for /v1/query/*, /v1/datasets.
Statistic shows 1 instead of 100% for a 0–1 ratioPercent enum doesn't auto-multiply| map * 100 in MPL, then chart-add --unit "%".
OTel histogram chart shows nonsenseHistogram aligned as a scalarUse bucket … using interpolate_cumulative_histogram (or _delta per temporality). See promql-to-mpl.md § Histogram translation.
Grafana migration filters/groups on the wrong subsetRead expr without description, or vice versaProject all five panel fields before authoring; see reference/grafana-migration.md.
PromQL metric name not foundSkipped OTel rename rulesDrop _total, decompose histograms, normalise units; validate with metrics-info. Labels need reverse-tag discovery. See grafana-migration.md § Name Mapping.
MPL chart aggregates across a dimension PromQL filtered/grouped onDropped a selector or by(...) during translationEvery {label=…} → where; every by(…) → group by. See reference/promql-to-mpl.md.
Panel shipped a different quantity than askedSubstituted instead of deferringReplace with a Note documenting the blocker. See Compute or Defer.
403 "creating private dashboards"API tokens only create shared dashboardsLeave owner as dashboard-assemble's default (X-AXIOM-EVERYONE).

Reference

  • reference/chart-config.md — All chart configuration options (JSON)
  • reference/metrics-mpl.md — Metrics/MPL chart contract and discovery scripts
  • reference/smartfilter.md — SmartFilter/FilterBar full configuration
  • reference/chart-cookbook.md — APL patterns per chart type
  • reference/layout-recipes.md — Grid layouts and section blueprints
  • reference/splunk-migration.md — Splunk panel → Axiom mapping
  • reference/grafana-migration.md — Grafana panel → Axiom mapping (canonical-spec projection, PromQL→MPL pointers, OTel rename rules)
  • reference/promql-to-mpl.md — PromQL → MPL translation rules (selectors, groupings, rate, histograms, ratios, reverse-tag discovery)
  • reference/design-playbook.md — Decision-first design principles
  • reference/templates/ — Ready-to-use dashboard JSON files

For APL syntax: https://axiom.co/docs/apl/introduction

© openclaw, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 50 other files (scripts) in .agents/skills/building-dashboards of openclaw/clawhub.

  • SKILL.md
  • .meta/.gitkeep
  • README.md
  • reference/chart-config.md
  • reference/chart-cookbook.md
  • reference/design-playbook.md
  • reference/grafana-migration.md
  • reference/layout-recipes.md
  • reference/metrics-mpl.md
  • reference/promql-to-mpl.md
  • reference/smartfilter.md
  • reference/splunk-migration.md
  • reference/templates/api-health.json
  • reference/templates/blank.json
  • reference/templates/org-usage-cost-control.json
  • reference/templates/service-overview-with-filters.json
  • reference/templates/service-overview.json
  • scripts
  • … and 33 more

Open the folder on GitHubat commit d044664

Compare with similar skills

Axiom Dashboard Builder next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Axiom Dashboard Builder compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Axiom Dashboard Builder this skillopenclaw/clawhub9.5k—~4.9kAutomated safety check: PassMIT
Happy Infra Metrics and Grafanaslopus/happy24k—~2kAutomated safety check: NotesMIT
OpenTelemetry Pipeline Metrics Speccomet-ml/opik22k—~3.2kAutomated safety check: PassApache-2.0
Archestra Dev Observabilityarchestra-ai/archestra4.4k—~1.2kAutomated safety check: PassCustom licence
Frontmcp Observabilityagentfront/frontmcp146—~4.6kAutomated safety check: PassApache-2.0
Monitoring Observabilityahmedasmar/devops-claude-skills203—~3.9kAutomated safety check: PassNone

Similar skills

  • Queries live Prometheus metrics and manages Grafana dashboards as code for Happy's infrastructure, using the grafanactl CLI and the Grafana datasource proxy API.

    24k GitHub stars~2k tokensUpdated today
    DevOps & CloudAuto-check: notes
  • Specifies how to instrument an opik-backend pipeline with per-stage OpenTelemetry metrics for throughput, latency, errors and queue delay by workspace.

    22k GitHub stars~3.2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Archestra Dev Observability

    archestra-ai/archestra

    A skill your agent uses when changing Archestra tracing, metrics, OpenTelemetry, Tempo, Grafana, Prometheus, LLM/MCP spans, observability labels, or local observability setup.

    4.4k GitHub stars~1.2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Frontmcp Observability

    agentfront/frontmcp

    A skill your agent uses when adding tracing, structured logging, metrics, or monitoring to a FrontMCP server.

    146 GitHub stars~4.6k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed
  • Monitoring Observability

    ahmedasmar/devops-claude-skills

    Monitoring and observability strategy, implementation, and troubleshooting.

    203 GitHub stars~3.9k tokensUpdated 6 mo ago
    DevOps & CloudAuto-check passed
  • Agento11y Experiments

    grafana/agento11y

    Official

    Run any Python LLM agent as an Agent Observability experiment using the public agento11y.experiments package: define a test suite, run an existing agent through typed trials, bind or record…

    127 GitHub stars~2k tokensUpdated today
    DevOps & CloudAuto-check passed

More from openclaw/clawhub

All 55 skills in this repo
  • Creates and manages Axiom monitors and notifiers end to end through the v2 API, with scripts for each CRUD operation and a recommended create-validate-tune workflow.

    9.5k GitHub stars~2.1k tokensUpdated yesterday
    Auto-check passed
  • Axiom Cost Control

    openclaw/clawhub

    Finds unused data in Axiom by analyzing query patterns, then deploys a cost dashboard and ingest monitors to keep spend under the contract limit.

    9.5k GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed
  • Axiom Metrics Query

    openclaw/clawhub

    Explores and queries OpenTelemetry metrics in Axiom MetricsDB, listing datasets, metrics and tags first and picking the right aggregation for each metric's type.

    9.5k GitHub stars~2.6k tokensUpdated yesterday
    Auto-check passed
  • Axiom SRE Investigator

    openclaw/clawhub

    Investigates incidents and production problems with hypothesis-driven debugging, queries Axiom observability data when available, and keeps secrets out of commands and output.

    9.5k GitHub stars~7.1k tokensUpdated yesterday
    Auto-check passed
  • Axiom Eval Writer

    openclaw/clawhub

    Scaffolds evaluation suites for the Axiom AI SDK: eval files, scorers, flag schemas and axiom.config.ts, generated from plain descriptions of an AI capability.

    9.5k GitHub stars~4.1k tokensUpdated yesterday
    Auto-check: warnings
  • Drafts, previews, sends and records email for an existing ClawHub content rights case through the admin CLI, with a dry run and your sign-off before anything goes out.

    9.5k GitHub stars~984 tokensUpdated yesterday
    Auto-check passed

Works with

Questions about Axiom Dashboard Builder

What does Axiom Dashboard Builder do?

Designs and deploys Axiom dashboards through the API, choosing chart types and writing APL or metrics queries, with templates and migration notes for Splunk and Grafana. The skill guides an agent through building an Axiom dashboard from a vague request, a template, an existing Splunk or Grafana dashboard, or an exploration of live data. It starts with intake questions about the audience, such as on-call triage, team health or executive reporting, and about scope.

When should I use Axiom Dashboard Builder?

Axiom Dashboard Builder fits situations like: creating an Axiom dashboard from a plain-language description; migrating a Splunk or Grafana dashboard to Axiom; adding SmartFilters or adjusting chart options on a dashboard; turning exploratory queries into an on-call overview.

How do I install Axiom Dashboard Builder in Claude Code?

Run `npx skills add openclaw/clawhub --skill building-dashboards -a claude-code`. Or copy the skill folder (.agents/skills/building-dashboards in openclaw/clawhub) into .claude/skills/building-dashboards in your project. Claude Code loads it when a task matches its description.

How do I install Axiom Dashboard Builder in Codex?

Run `npx skills add openclaw/clawhub --skill building-dashboards -a codex`. Or copy the skill folder (.agents/skills/building-dashboards in openclaw/clawhub) into .agents/skills/building-dashboards in your project. Codex loads it when a task matches its description.

Can I use Axiom Dashboard Builder in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openclaw/clawhub --skill building-dashboards -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/building-dashboards, .gemini/skills/building-dashboards, .github/skills/building-dashboards and .opencode/skills/building-dashboards in your project.

What does Axiom Dashboard Builder need to run?

SKILL.md names no scripts, command-line tools or credentials: Axiom Dashboard Builder is instructions for the agent only. Our summary lists: Access to the Axiom API for the target deployment.

Does Axiom Dashboard Builder access the network?

SKILL.md names 1 domain. As links in the text: axiom.co. This is read from the text; nothing was executed.

Is Axiom Dashboard Builder safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Axiom Dashboard Builder use?

Axiom Dashboard Builder is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Axiom Dashboard Builder use?

About 4.9k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Axiom Dashboard Builder?

Skills that share tags, products or a category with Axiom Dashboard Builder: Happy Infra Metrics and Grafana (slopus/happy, 24k stars), OpenTelemetry Pipeline Metrics Spec (comet-ml/opik, 22k stars), Archestra Dev Observability (archestra-ai/archestra, 4.4k stars) and Frontmcp Observability (agentfront/frontmcp, 146 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Axiom Dashboard Builder?

openclaw (a GitHub organization) maintains it in openclaw/clawhub, which has 9,500 GitHub stars. The repository holds 55 skills in this directory. The repository was last updated on October 8, 2026.

Source: openclaw/clawhub on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.