Skill Authoring
Grafana LabsOfficialPublished by Grafana Labs
- Skill
- Meta (authoring, orchestration, planning, memory)
- Agent tooling
- Apache-2.0
- No issues found
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/grafana/skill-authoring/downloadUnzip 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)
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.
Body under 500 lines — split into
references/*.mdif approaching the limit. SKILL.md is the routing layer, not the entire knowledge base.One level of nesting for references — link from SKILL.md directly, never
SKILL.md → a.md → b.md. Claude may usehead -100previews on nested chains and miss content.Imperative voice — "Run X" not "You should run X" not "It is important to run X". Explain why over heavy-handed
MUSTmarkers.Concrete examples beat prose — copy-paste-ready commands, real config snippets. Tessl's
actionabilitydimension scores this directly.No reserved words in
name—anthropicandclaudeare forbidden in skill names.No time-sensitive language in the body — "after August 2025…" rots. Use an
<details>"Old patterns" section for legacy info instead.Validate before committing —
./scripts/lint-skills.sh skills/<plugin>/<your-skill>clean + Tessl score ≥75 (runtessl 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
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 threemarketplace.jsonfiles).Estimate body length.
<200 lines of substance → single
SKILL.md, no bundle200-500 lines →
SKILL.md+references/<topic>.mdfor the long-form material500 lines → mandatory bundle split; see references/anatomy.md § Splitting strategies
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.
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 inreferences/instead (Progressive disclosure)
Register in marketplace manifests. Add the skill path to the
skillsarray in all three:.claude-plugin/marketplace.json.cursor-plugin/marketplace.json.agents-plugin/marketplace.json
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
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.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
If the skill is intentionally a routing document (like
grafana-k6/k6-docs), don't let--optimizeinline 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.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
references/descriptions.md— the pushy-description pattern + trigger-term checklistreferences/rubric.md— per-dimension scoring with Anthropic-doc citations and concrete fix patternsreferences/anatomy.md— three-level progressive disclosure, bundle layout, splitting strategiesreferences/anti-patterns.md— what NOT to do, with examples
Files
- ATTRIBUTION.mdAdded by AutoGineer850 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md7.0 KiB
- references/anatomy.md5.5 KiB
- references/anti-patterns.md7.4 KiB
- references/descriptions.md4.4 KiB
- references/rubric.md12.2 KiB
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:
| Dimension | What it checks |
|---|---|
| Specificity | Lists concrete actions the skill performs (not just "helps with X") |
| Trigger term quality | Includes natural terms users actually say (variations, synonyms) |
| Completeness | Has both what it does AND when to use — usually via "Use when..." |
| Distinctiveness / conflict risk | Clearly scoped; won't fight other skills for activation |
The pushy pattern (Anthropic-recommended)
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:
What — concrete actions, not vague "helps with". List specific outputs the skill produces.
Use when — explicit triggers. Multiple scenarios, ideally including domain-specific terms (repo names, CLI names, product names).
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
| Limit | Value | Source |
|---|---|---|
| Max length | 1024 chars | Agent Skills spec |
| Voice | Third-person | Anthropic best-practices doc |
| XML tags | Not allowed | Agent Skills spec |
Reserved words in name (NOT description) | anthropic, claude | Anthropic 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