Dashboard builder
Build monitoring dashboards that answer real operator questions for Grafana, SigNoz, and similar platforms. Use when turning metrics into a working dashboard instead of a vanity board.From its SKILL.md
npx -y skills add aAAaqwq/AGI-Super-Team --skill dashboard-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.3 KB, 474 tokens by cl100k_base, as published. Nobody here has run it
Dashboard Builder
Use this when the task is to build a dashboard people can operate from.
The goal is not "show every metric." The goal is to answer:
- is it healthy?
- where is the bottleneck?
- what changed?
- what action should someone take?
When to Use
- "Build a Kafka monitoring dashboard"
- "Create a Grafana dashboard for Elasticsearch"
- "Make a SigNoz dashboard for this service"
- "Turn this metrics list into a real operational dashboard"
Guardrails
- do not start from visual layout; start from operator questions
- do not include every available metric just because it exists
- do not mix health, throughput, and resource panels without structure
- do not ship panels without titles, units, and sane thresholds
Workflow
1. Define the operating questions
Organize around:
- health / availability
- latency / performance
- throughput / volume
- saturation / resources
- service-specific risk
2. Study the target platform schema
Inspect existing dashboards first:
- JSON structure
- query language
- variables
- threshold styling
- section layout
3. Build the minimum useful board
Recommended structure:
- overview
- performance
- resources
- service-specific section
4. Cut vanity panels
Every panel should answer a real question. If it does not, remove it.
Example Panel Sets
Elasticsearch
- cluster health
- shard allocation
- search latency
- indexing rate
- JVM heap / GC
Kafka
- broker count
- under-replicated partitions
- messages in / out
- consumer lag
- disk and network pressure
API gateway / ingress
- request rate
- p50 / p95 / p99 latency
- error rate
- upstream health
- active connections
Quality Checklist
- valid dashboard JSON
- clear section grouping
- titles and units are present
- thresholds/status colors are meaningful
- variables exist for common filters
- default time range and refresh are sensible
- no vanity panels with no operator value
Related Skills
research-opsbackend-patternsterminal-ops
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 3 of the 12 instructions most monitoring observability skills give in 474 tokens
Counted across 530 of the 532 authors here whose files we hold, read 2026-09-06
- Use structured JSON loggingin 40 of 530, across 36 files
- Link every alert to a runbookin 29 of 530, across 27 files
- Attach correlation IDs to every log linein 19 of 530, across 16 files
- Alert on symptoms rather than causesin 19 of 530, across 17 files
- Use OpenTelemetry for distributed tracingin 15 of 530, across 14 files
- Alert on symptoms users feelin 15 of 530, across 13 files
- Implement health check endpointsin 14 of 530, across 10 files
- Inspect existing dashboards firsthere, and in 12 of 530, across 4 files
- Build the minimum useful boardhere, and in 12 of 530, across 4 files
- Start from operator questionshere, and in 12 of 530, across 4 files
- Propagate trace context across boundariesin 11 of 530, across 10 files
- Include trace id in all log entriesin 10 of 530, across 9 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.