0 Fork 0

mirror of https://github.com/affaan-m/ECC.git synced 2026-11-10 01:55:56 +00:00

Files

T

Affaan Mustafa c70874fae9 feat(pi): curated pi/core skills+prompts profile, CI load test, and 2.2.2 release sync (#3264 )

Adds a curated, Pi-native, skills+prompts-only profile at pi/core/ for downstream packagers that mirror GitHub Releases.

- manifests/pi-core.json: explicit include lists, per-item exclusion reasons, curation rules, safety allowlists; every root skill and command must be classified.
- scripts/build-pi-core.js regenerates pi/core deterministically (package.json from VERSION, LICENSE, README.md, CURATION.md, skills/, commands/); --check fails CI on drift. council is renamed ecc-council inside pi/core only.
- Safety checks: no callable endpoints outside the allowlist, no npx/curl|sh/pip install, no secrets, no absolute home paths, no symlinks, valid frontmatter, no duplicate names.
- CI: build + drift check and an offline Pi CLI load test of pi/core.
- Release: VERSION, package.json and pi/core/package.json at 2.2.2, CHANGELOG, tag-triggered release verification, and a two-week cadence in CONTRIBUTING.md.

pi/core: 123 of 293 skills and 24 of 94 commands; 35,006 characters of skill description text.

2026-09-29 20:24:05 -05:00

2.3 KiB

Raw Blame History

name, description, metadata

name

description

metadata

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.

version	origin
1.0.0	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

research-ops
backend-patterns
terminal-ops

2.3 KiB Raw Blame History