메뉴
Use when authoring, retrofitting, or verifying Grafana service-monitoring dashboards — enforces probing live metrics before writing PromQL, a standard four-row health baseline, and a four-rung verification ladder before declaring a dashboard done.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Use when implementing multiple related enhancements, or a large feature that must be split across risk boundaries, and you need to decide branch/PR structure. Covers accumulating related work on one shared branch with atomic commits per enhancement, splitting risky multi-PR features along risk seams, and safely handling a branch that has both committed and dirty (uncommitted) work when shipping.
Use when a rebase or merge reports conflicts on a file where both branches only appended or inserted new content (append-only logs, registries, holding-pen documents) rather than editing the same lines. Recognizes the conflict as a false signal and resolves it as a union-keep-both operation instead of a real semantic merge.
Use when reskinning an app with a real brand's visual identity — extract the actual palette from a live site's raw CSS (not markdown), recreate logo/icon assets programmatically with documented extraction rationale, and codify everything as versioned, named design tokens rather than one-off hardcoded values.
Use when building a skill, doc, or knowledge base for an existing internal service or codebase, or when asked to audit past sessions for recurring failures and gaps — mine prior Claude conversation transcripts instead of reverse-engineering from logs or current code alone.
| name | grafana-dashboard-workflow |
| description | Use when authoring, retrofitting, or verifying Grafana service-monitoring dashboards — enforces probing live metrics before writing PromQL, a standard four-row health baseline, and a four-rung verification ladder before declaring a dashboard done. |
| status | active |
| version | "2026-07-05T00:00:00.000Z" |
Probe before you design. Never trust an exporter's README or an old design doc — metric names drift silently between versions. Hit the live endpoint first:
curl http://exporter:port/metrics | grep '^[a-z_]+'
Also check Prometheus targets to confirm instance labels and scrape availability. Write PromQL only against what you actually observe.
Author against the standard four-row baseline (applies across both LXC and container substrates):
traefik_service_* metrics keyed by service label.Query conventions: use vector(0) fallbacks so zero-series panels still render; use $__interval for cache-aware rate() windows; prefer rate() over raw counters. MUST rules: double-quote all label matchers (Grafana JSON silently strips single quotes), use pre-baked datasource UIDs (prometheus/loki — never re-resolve by name), and jq-validate the dashboard JSON before provisioning.
Register the dashboard in provisioning config, e.g. roles/grafana/defaults/main.yml. Dropping a JSON file into the dashboards directory alone does nothing — it must be registered or it will never be provisioned.
Run the verification ladder, in this exact order, before declaring done:
$__interval → 5m, to catch metric-name mismatches and label typos before apply.changed=1, second pass changed=0 — to prove the provisioning is idempotent.docker exec, not the external URL if it sits behind Authentik) to confirm the served panel set matches what was committed.When retrofitting existing dashboards onto the baseline: inventory dashboards by type (hand-authored single-service vs. community imports vs. analysis/diagnostic/fleet-aggregate). Apply an eligibility rubric — only single-service health dashboards are retrofit targets; analysis dashboards (e.g. internet-latency, flow analysis, sni-console) are exempt because the baseline's four rows don't map to their shape. Tier eligible dashboards by effort (how many rows are already compliant vs. need rework), then draft a per-tier PR sequence with a migration contract per dashboard (which rows to add, which metrics exist, known gaps). Treat the baseline as routine only once it's proven stable against at least two real reference dashboards.
reduce + seriesToRows transform to collapse the per-series matrix into a single table row.MemAvailable reads "available" even while page-cache holding a mmap'd model is thrashing). Add the signals that would have caught the incident (memory current-vs-max, swap usage, PSI pressure) rather than just re-trusting the existing metric.