grafana/skills

skill-authoring

Author, audit, and improve Grafana SKILL.md files against Anthropic's published Agent Skills guidance and the four-dimension rubric the grafana/skills CI gate uses (conciseness, actionability, workflow clarity, progressive disclosure).

Voir la source
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

Authoring & Improving Grafana Skills

How to write, review, and improve SKILL.md files so they pass the repo's CI gate and score well against the Anthropic-aligned rubric Tessl uses.

Critical rules (always)

  1. Description is the primary trigger — third-person, ≤1024 chars, must include explicit "Use when..." phrasing AND list concrete trigger terms users naturally say. See references/descriptions.md for the pushy-description pattern that combats undertriggering.
  2. Body under 500 lines — split into references/*.md if approaching the limit. SKILL.md is the routing layer, not the entire knowledge base.
  3. One level of nesting for references — link from SKILL.md directly, never SKILL.md → a.md → b.md. Claude may use head -100 previews on nested chains and miss content.
  4. Imperative voice — "Run X" not "You should run X" not "It is important to run X". Explain why over heavy-handed MUST markers.
  5. Concrete examples beat prose — copy-paste-ready commands, real config snippets. Tessl's actionability dimension scores this directly.
  6. No reserved words in `name`anthropic and claude are forbidden in skill names.
  7. No time-sensitive language in the body — "after August 2025…" rots. Use an <details> "Old patterns" section for legacy info instead.
  8. Validate before committing./scripts/lint-skills.sh skills/<plugin>/<your-skill> clean + Tessl score ≥75 (run tessl skill review --json <dir>).

The rubric

CI fails any PR where a touched SKILL.md scores below 75 on four 0-3 dimensions: conciseness, actionability, workflow clarity, progressive disclosure. Full per-dimension scoring + Anthropic-doc mapping in references/rubric.md.

Score variance

The judge is an LLM and swings 7-10 points run-to-run. Local 94 commonly lands at CI 85. Ship only on three consecutive local 100s.

Decision tree for a new skill

  1. What product / domain does this skill belong to?

Pick the right plugin folder: grafana-core/, grafana-cloud/, grafana-lgtm/, grafana-app-sdk/, grafana-k6/, grafana-plugins/. If none fits cleanly, ask the user before creating a new plugin group (a new group requires updating three marketplace.json files).

  1. Estimate body length.
  1. Write a "pushy" description first.

The description is the only thing always loaded into context. If agents don't trigger the skill, nothing else matters. See references/descriptions.md for the pattern.

  1. Draft body with the four-dimension rubric in mind.
  • Cut every sentence Claude already knows (Conciseness)
  • Replace prose explanations with code blocks (Actionability)
  • Number every multi-step procedure + add a validation step at the end (Workflow clarity)
  • If you reach for <details>, consider whether that content belongs in references/ instead (Progressive disclosure)
  1. Register in marketplace manifests.

Add the skill path to the skills array in all three:

  • .claude-plugin/marketplace.json
  • .cursor-plugin/marketplace.json
  • .agents-plugin/marketplace.json
  1. Validate locally.
bash
   # 1. Lint clean (0 errors)
   ./scripts/lint-skills.sh skills/<plugin>/<your-skill>

   # 2. Tessl reviewScore ≥75 (the CI gate)
   tessl skill review --json skills/<plugin>/<your-skill> | jq '.review.reviewScore'

   # 3. If below 75 or you want ≥85: run --optimize (requires auth)
   tessl skill review --optimize --yes --max-iterations 3 skills/<plugin>/<your-skill>

If the run fails: read the lint error / Tessl suggestion, fix, re-run. Don't open the PR until both checks pass cleanly. The feedback-loop pattern beats one-shot writing.

Fixing a low-scoring existing skill

  1. Read the judge's verbatim Suggestions text (non-JSON output):
bash
   tessl skill review skills/<plugin>/<name>

The Suggestions: block under each dimension names the exact sentences/sections to cut. Copy the suggestion — don't guess. Then verify the lowest dimension matches your read.

  1. Apply the fix pattern from references/rubric.md:
  • Conciseness 1-2 → cut intros, definitions, multi-line tables that mostly point to refs
  • Actionability 1-2 → replace prose with code blocks and CLI commands
  • Workflow clarity 1-2 → add numbered steps + validation checkpoints
  • Progressive disclosure 1-2 → split into references/*.md
  1. If the skill is intentionally a routing document (like grafana-k6/k6-docs), don't let --optimize inline the bundle back into SKILL.md. Hand-craft a minimal copy-paste "validation loop" inline so SKILL.md is independently actionable, while preserving the bundle.
  1. Re-score five times locally. Don't stop until all five runs hit 100 — see "Score variance" above for why.

Anti-patterns

See references/anti-patterns.md.

References

du même dépôt

Autres Skills

Tous les Skills
grafana
Communauté

alerting-irm

Configure Grafana Alerting, Incident Response Management (IRM), and SLOs end-to-end — provisions Grafana-managed and data-source-managed alert rules, contact points (Slack/PagerDuty/email/webhook), notification policies with hierarchical matchers, silences, mute timings, on-call schedules and escalation chains, incident-management integrations, and SLOs with multi-window burn-rate alerts. Use when configuring alerts, debugging notification routing, setting up on-call rotations, declaring or managing incidents, defining SLOs, provisioning alerting via YAML or API, picking matchers for a notification policy, building a PagerDuty/Slack webhook receiver, or troubleshooting why an alert isn't firing — even when the user says "page me on errors", "alert me when X happens", "route this to the platform team", or "set up an SLO" without naming Alerting or IRM.

installations
5
GitHub Stars
246
Mis à jour
8 sept.
grafana
Communauté

alloy

Build a unified telemetry pipeline with Grafana Alloy — one OpenTelemetry-compatible binary that collects metrics, logs, traces, and profiles and ships to Grafana Cloud / Prometheus / Loki / Tempo / Pyroscope. Covers the Alloy config language (blocks, sys.env, component refs), prometheus.scrape → remotewrite, loki.source.file + loki.process → loki.write, otelcol.receiver.otlp → otelcol.exporter.otlp, pyroscope.scrape, K8s / Docker / EC2 discovery, relabeling, modules (import.file/git/http), clustering, Fleet Management remotecfg, the Alloy UI at :12345, and alloy fmt / alloy validate. Use when writing a config.alloy, replacing Grafana Agent / OTel Collector, scraping K8s pods, parsing logs, ingesting OTLP, or debugging "Alloy isn't sending anything" — even when the user says "set up the agent", "write me a scrape config", "drop these logs before sending", or "OTel collector config" without naming Alloy.

installations
5
GitHub Stars
246
Mis à jour
8 sept.
grafana
Communauté

beyla

Auto-instrument an application's HTTP / gRPC / DB traffic with Grafana Beyla eBPF — no code changes, no SDK, no restart. Covers requirements (Linux 5.8+ with BTF, CAPSYSADMIN, host PID), language matrix (Go / Java / Python / Ruby / Node / .NET / Rust / C++ / PHP), Docker + Helm + DaemonSet install, port- / process- / Kubernetes-metadata discovery, OTLP traces + Prometheus metrics export, routes decorator (cardinality control), trace sampling, and Grafana Cloud via Alloy. Use when adding observability to a service you can't recompile, instrumenting a closed-source binary, getting RED metrics + spans onto Tempo/Mimir without touching the app, or rolling Beyla as a cluster-wide DaemonSet — even when the user says "zero-code APM", "instrument legacy app", "trace this binary", "eBPF observability", or "no SDK" without naming Beyla.

installations
5
GitHub Stars
246
Mis à jour
8 sept.
grafana
Communauté

dashboarding

Build, modify, and ship Grafana dashboards as JSON via the HTTP API — panel types (timeseries / stat / gauge / table / heatmap / logs / traces / node-graph), gridPos 24-column layout, units, thresholds, template + datasource + chained variables, transformations (organize / calculateField / filterByValue), panel + dashboard links with ${field.labels.x} / ${from}, and Loki/Prometheus annotations. Use when scripting dashboard creation, writing the dashboard JSON for a new service, adding a $job dropdown variable, computing an "Error %" column with a transformation, overlaying deploys as annotations, or pushing a dashboard via POST /api/dashboards/db — even when the user says "create a dashboard for this metric", "add a service dropdown", "show errors as percentage", "overlay our deploys", or "export the dashboard JSON" without naming the API or schema. After every API push, verify with the returned version plus a GET on the dashboard UID.

installations
5
GitHub Stars
246
Mis à jour
8 sept.