Generated banner for Skill Authoring
Generated logo for Skill Authoring

Skill Authoring

Grafana LabsOfficialPublished by Grafana Labs

  • Skill
  • Meta (authoring, orchestration, planning, memory)
  • Agent tooling
  • Apache-2.0
  • No issues found

From the author

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). Applies the canonical SKILL.md structure (YAML frontmatter + body + references/ + scripts/ + assets/), the "pushy description" trigger pattern, the three-level progressive-disclosure model, and the validate-fix-rerun feedback loop. Use when creating a new skill in this repo, when reviewing a skill PR, when a skill's Tessl review score is below 75 (the merge gate), when a skill's description isn't getting picked up by agents, when restructuring a long SKILL.md into a bundle, or when the user asks how to write, improve, optimize, audit, or fix a skill - even if they don't say "skill" explicitly (e.g. "this isn't triggering", "Tessl scored this 72", "split this doc").
— the description by Grafana Labs

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to creating and maintaining agent skills within the Grafana ecosystem. It defines a canonical structure for SKILL.md files, including YAML frontmatter, progressive disclosure patterns, and a validation feedback loop. It is designed to help developers align their skills with specific rubrics covering conciseness, actionability, workflow clarity, and progressive disclosure, ensuring they pass automated CI gates and trigger effectively for users.

What it does

  • Provides a rubric for auditing and scoring skill documentation.
  • Defines the canonical SKILL.md structure and bundle layout.
  • Implements a validate-fix-rerun feedback loop for skill optimization.
  • Offers guidance on progressive disclosure and splitting strategies for large documentation.
  • Details trigger patterns to ensure skills are correctly identified by agents.
  • Lists common anti-patterns to avoid during skill development.

When to use it

  • When creating a new skill within the repository.
  • When reviewing a skill pull request.
  • When a skill fails the CI merge gate or receives a low review score.
  • When a skill is not triggering as expected during agent interactions.
  • When restructuring long documentation into a bundle.
  • When seeking advice on optimizing or fixing existing skill files.

Advantages

  • Standardizes skill development across the repository.
  • Provides actionable feedback based on automated review scores.
  • Reduces token usage through progressive disclosure strategies.
  • Ensures consistent trigger behavior via pushy description patterns.
  • Facilitates easier maintenance through modular bundle layouts.

Usage examples

“How do I improve my skill's review score?”
The agent will guide you through the Tessl review process, identifying specific dimensions like conciseness or actionability that need improvement based on the rubric.
“My skill isn't triggering when I ask for help. What should I do?”
The agent will audit your skill's description against the pushy-description pattern and suggest updates to ensure it includes the necessary trigger terms.
“How should I split a long SKILL.md file?”
The agent will provide strategies for splitting content into references/ files based on domain, depth, or format to maintain the three-level loading model.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/grafana/skill-authoring/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip skill-authoring.zip -d .agents/skills

Documentation by Grafana Labs

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).

  2. Estimate body length.

  3. 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.

  4. 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)

  5. 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

  6. Validate locally.

    # 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):

    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.

  2. 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

  3. 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.

  4. 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

Files

references/descriptions.md

Writing skill descriptions that actually trigger

The description field is the only part of a skill always loaded into the agent's context. Everything else — the SKILL.md body, the bundle files — is only read after the agent decides this skill applies. If the description is weak, none of the rest of your work matters.

The four scoring dimensions (Tessl descriptionJudge)

Each rated 0-3, normalized to a 0-1 final score:

DimensionWhat it checks
SpecificityLists concrete actions the skill performs (not just "helps with X")
Trigger term qualityIncludes natural terms users actually say (variations, synonyms)
CompletenessHas both what it does AND when to use — usually via "Use when..."
Distinctiveness / conflict riskClearly scoped; won't fight other skills for activation

From Anthropic's skill-creator SKILL.md:

Claude has a tendency to "undertrigger" skills — to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit "pushy". So for instance, instead of "How to build a simple fast dashboard to display internal Anthropic data.", you might write "How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'"

The pushy clause forces the agent to consider the skill across phrasings users actually say.

Anatomy of a strong description

description: <concrete-actions-the-skill-performs>. Applies <specific-conventions/methodologies>, generates <specific-outputs>, and validates <specific-checks>. Use when <task-A>, <task-B>, <task-C>, or when the user asks to <verb-1>, <verb-2>, <verb-3> - even if they don't explicitly say "<the-narrow-canonical-term>".

Three parts:

  1. What — concrete actions, not vague "helps with". List specific outputs the skill produces.

  2. Use when — explicit triggers. Multiple scenarios, ideally including domain-specific terms (repo names, CLI names, product names).

  3. Pushy clause — the "even if they don't explicitly say…" part. This catches the user phrasings that miss the canonical term.

Strong vs weak examples

Weak
# Vague "what", no "when", no trigger variations
description: Helps with k6 documentation.

# First-person, no "when"
description: I help you write k6 docs and TypeScript types.

# "When" is too narrow; missing trigger variations and pushy clause
description: Use when writing or reviewing k6 documentation across TypeScript types, user docs, and release notes.
Strong (k6-docs from this repo, score 1.0/1.0 after rewrite)
description: >
  Write or review k6 documentation across the three k6 repositories - k6-DefinitelyTyped (TypeScript types),
  k6-docs (user documentation), and k6 (release notes / changelog). Applies k6 doc style conventions,
  generates TypeScript type definitions, drafts release notes, and validates examples by running them
  against k6@master. Use when working on k6 documentation, the k6 changelog, the k6 release notes,
  k6 API reference, k6 TypeScript types, load testing docs, or when the user asks to write, edit, or
  review anything in the k6, k6-docs, or k6-DefinitelyTyped repos - even if they don't explicitly
  say "documentation".

Why it works:

  • Specific outputs: TypeScript type definitions, release notes, example validation

  • Trigger variations: changelog, release notes, API reference, repo names, "load testing docs"

  • Pushy clause: catches users editing the underlying repos without saying "documentation"

Hard limits

LimitValueSource
Max length1024 charsAgent Skills spec
VoiceThird-personAnthropic best-practices doc
XML tagsNot allowedAgent Skills spec
Reserved words in name (NOT description)anthropic, claudeAnthropic best-practices doc

Checklist before opening a PR

  • [ ] Third-person ("Processes X" not "I process X" or "You can process X")

  • [ ] Explicit "Use when..." clause

  • [ ] Pushy clause at the end ("even if they don't say…")

  • [ ] At least 4-5 trigger-term variations users naturally say

  • [ ] ≤1024 chars

  • [ ] No reserved words in name

  • [ ] Concrete actions, not "helps with"

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Grafana Labs
Publisher
Grafana Labs (Official)
Source
grafana/skills · skills/grafana-core/skill-authoring · commit 8fb72a5
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Grafana Labs.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download skill-authoring.zip