codeply-cli 0.3.1 → 0.4.1

package/skills/dashboard-builder/SKILL.md

@@ -1,109 +1,109 @@
----
-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:
-  origin: ECC direct-port adaptation
-version: "1.0.0"
----
-
-# 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`
+---
+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:
+  origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# 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`