dashboard-builder

Use it when:: You're turning a list of metrics into a Grafana, SigNoz or similar dashboard that people will run a service from.
It does:: Starts from operator questions, studies your existing dashboards' JSON and query language, then builds the smallest board that answers them.
You get:: Dashboard JSON grouped into overview, performance, resources and service-specific sections, with titles, units, thresholds and filter variables.
Examples:: Panel sets for Elasticsearch, Kafka and API gateways.

TL;DR

A dashboard here exists to answer four questions: is it healthy, where is the bottleneck, what changed, and what should someone do. The agent organizes panels around health, latency, throughput, saturation and service-specific risk, never around visual layout or every metric available. Before building, it inspects the target platform's existing dashboards for their JSON structure, query language, variables, threshold styling and section layout. The board follows a fixed order: overview, performance, resources, then a service-specific section, and any panel that answers no real question is removed. Example panel sets cover Elasticsearch (cluster health, shard allocation, search latency, indexing rate, JVM heap), Kafka (brokers, under-replicated partitions, consumer lag, disk and network) and API gateways (request rate, p50, p95 and p99 latency, error rate, upstream health). A closing checklist asks for valid JSON, clear grouping, titles and units, meaningful thresholds, filter variables, a sensible default time range and refresh, and no vanity panels.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill dashboard-builder

skills.sh page Source on GitHub All skills from affaan-m/ecc

Total Downloads: 5,700 on skills.sh, Nov 9, 2026
Repo stars: 299,776 affaan-m/ecc
First seen: May 19, 2026 on skills.sh

Weekly Downloads

449

+68% over the 8 weeks to Nov 9

Weekly values

Week to	Installs
Sep 21	267
Sep 28	170
Oct 5	171
Oct 12	250
Oct 19	431
Oct 26	418
Nov 2	487
Nov 9	449

Category	category:cloud category:software-engineering Deploy, provision, observe and debug cloud apps. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:local Its own steps create or change files, git state or local tools.
Needs	needs:none Instructions only. Works in any agent that supports skills.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	observability
Stack	stack:grafana stack:signoz

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: dashboard-builder
description: 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.
metadata:
  version: "1.0.0"
  origin: ECC direct-port adaptation

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-ops
backend-patterns
terminal-ops