Dashboard Builder
Turn a pile of metrics into a Grafana, SigNoz, or similar dashboard that operators can actually act on.
Overview
Dashboard Builder is an agent skill most often used in Operate (also Ship perf) that designs monitoring dashboards around operator questions for Grafana, SigNoz, and similar platforms.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill dashboard-builderWhat is this skill?
- Starts from four operator questions: healthy, bottleneck, what changed, what action to take
- Four guardrails against vanity metrics and unstructured mixed panels
- Five-step workflow: operator questions → platform schema → minimum board → thresholds → handoff
- Recommended four-section layout: overview, performance, resources, service-specific risk
- Inspects existing dashboard JSON, variables, and threshold styling before authoring
- 4 recommended dashboard sections: overview, performance, resources, service-specific risk
- 4 operator questions drive layout before any visual design
- 4 guardrails against vanity metrics and unstructured panels
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have metrics available but no structured dashboard that tells you whether the system is healthy or what to do next.
Who is it for?
Solo operators wiring observability after a service ships who need Kafka, ES, or APM boards without metric sprawl.
Skip if: Purely local dev with no metrics backend, or one-off ad-hoc queries where a saved explore link is enough.
When should I use this skill?
Build a Kafka, Elasticsearch, or service monitoring dashboard; create Grafana or SigNoz boards from a metrics list; turn metrics into a real operational dashboard.
What do I get? / Deliverables
You get a structured operational dashboard with clear sections, units, thresholds, and panels mapped to health, latency, throughput, and saturation.
- Dashboard JSON or panel spec with titles, units, and thresholds
- Sectioned layout mapped to operator questions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Operational dashboards live where you run production, even though metrics are often defined earlier during ship and build. Monitoring subphase is the canonical shelf for boards that answer health, bottlenecks, and what changed in prod.
Where it fits
Define latency and error SLO panels before you flip traffic to production.
Rebuild a vanity metrics board into overview → performance → resources → risk sections for on-call.
Add saturation panels for Kafka or Elasticsearch when capacity emails start after a launch spike.
Separate product analytics from infra health so growth experiments do not pollute operator dashboards.
How it compares
Use instead of copying random community dashboard JSON that mixes every metric without an on-call narrative.
Common Questions / FAQ
Who is dashboard-builder for?
Indie builders and small teams who own production and need Grafana- or SigNoz-style boards they can run incidents from.
When should I use dashboard-builder?
In Operate (monitoring) when building or refactoring prod dashboards; in Ship (perf) when defining SLO panels before launch; when prompts say “build a Kafka/Elasticsearch/service monitoring dashboard.”
Is dashboard-builder safe to install?
The skill describes dashboard design workflow; any live queries touch your observability stack credentials—review the Security Audits panel on this Prism page before install.
SKILL.md
READMESKILL.md - Dashboard Builder
# 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: 1. overview 2. performance 3. resources 4. 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-ops` - `backend-patterns` - `terminal-ops`