skill-quality
Skill1 starsChanged 9 months agoMITView on GitHub
Guide for writing high-quality SKILL.md files. Use when creating, improving, or debugging Agent Skills — covers descriptions, instructions, and common pitfalls.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- adhi-jp/agent-skillstheir own version, first seen Oct 20, 2026
- Valeriy1980/claude-skillstheir own version, first seen Oct 13, 2026
- amandeepmittal/expo-docs-skillstheir own version, first seen Aug 31, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- adhi-jp/agent-skills★ 1same name
- amandeepmittal/expo-docs-skills★ 1same name
- Valeriy1980/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Every quality issue traces back to one of these two jobs failing.
- Distinctive: line 46
Start with what the skill *does* (a specific verb, not "manages" or "handles")
- Distinctive: line 47
Add "Use when..." to spell out the trigger conditions
- Distinctive: line 69
If you don't tell the agent how to handle failures, it will either retry forever or give up silently.
- Very specific: line 85
If your SKILL.md is getting long (over ~2,000 words), the agent has to process a lot of context to find what it needs.
- Distinctive: line 101
No absolute paths: Use relative paths or environment variables.
- Distinctive: line 106
Run the quality tools to catch issues before they bite you:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Writing Good Skills
This guide helps you write SKILL.md files that agents actually pick up and use well. It focuses on why things matter, not just what the spec says.
The Two Jobs of a Skill File
A SKILL.md does two things:
- Gets selected — The agent reads the
descriptionto decide whether this skill matches what the user asked for. If the description is vague, the agent skips it. - Guides execution — Once selected, the agent follows the markdown body as instructions. If the instructions are ambiguous, the agent guesses (badly).
Every quality issue traces back to one of these two jobs failing.
Frontmatter That Works
---
name: deploy-vercel
description: >-
Deploy web applications to Vercel. Use when the user wants to publish,
ship, or deploy a site. Runs vercel CLI, configures project settings,
and reports the live URL.
---Name
Kebab-case, 1–64 characters. Think of it as a function name — short, specific, no ambiguity.
Description — The Most Important Field
The description is how agents decide whether to load your skill. Write it as if you're answering: "When should an agent reach for this?"
Think about it this way: An agent sees dozens of skills. It scans descriptions looking for a match. Your description needs to win that split-second decision.
What works:
- Start with what the skill does (a specific verb, not "manages" or "handles")
- Add "Use when..." to spell out the trigger conditions
- Include the vocabulary your users would actually type ("publish", "ship", "deploy" — not just "deploy")
What doesn't work:
- "Manages deployment workflows" — vague, no trigger, agents can't distinguish this from ten other skills
- "Helps with Vercel" — what kind of help? Agents need to know the action
Instructions That Guide Well
Show, Don't Just Tell
Agents learn from examples much better than from abstract rules. Every skill should include at least one concrete example — a code block, a numbered walkthrough, or a before/after comparison.
vercel --prod --yesThe agent now knows the exact command shape, flags, and style — that's much more useful than a paragraph explaining what vercel does.
Cover What Goes Wrong
If you don't tell the agent how to handle failures, it will either retry forever or give up silently. Include a section on common failure modes:
- What errors the user might see
- Which ones are retryable vs. need user intervention
- What to check first (credentials? network? config?)
Heading Hierarchy
Headings must not skip levels. This isn't just pedantry — parsers use heading hierarchy to understand document structure, and skipped levels break that.
Valid: H1 → H2 → H3 or H1 → H2 → H3 → H2 → H3 (going back up is fine).
Invalid: H1 → H3 skips H2. The fix is to either demote the H3 to H2 or add the missing H2 between them.
Keeping Skills Focused
If your SKILL.md is getting long (over ~2,000 words), the agent has to process a lot of context to find what it needs. Split reference material into a references/ subdirectory and keep the main file focused on the core workflow:
my-skill/
├── SKILL.md # Core instructions (~1,000 words)
└── references/
├── api-details.md # Detailed API reference
└── examples.md # Extended examplesThe main SKILL.md can tell the agent to read a references file for the full parameter list — this keeps the primary instructions scannable.
Security Basics
Two rules that lint enforces and that matter:
- No absolute paths. Use relative paths or environment variables. Hardcoded paths like a home directory break for everyone else.
- No secrets. API keys, tokens, passwords — none of these belong in a skill file. Use environment variables or tell the agent to ask the user.
Checking Your Work
Run the quality tools to catch issues before they bite you:
# Quick spec check — does the file parse correctly?
npx --yes skill-tools@latest validate ./my-skill/SKILL.md
# Quality lint — description, examples, error handling, headings
npx --yes skill-tools@latest lint ./my-skill/SKILL.md
# Full picture — validate + lint + score in one pass
npx --yes skill-tools@latest check ./my-skill/SKILL.mdOr use the slash commands: /skill-tools:validate, /skill-tools:lint, /skill-tools:score, /skill-tools:check.
Common Fixes
"Description uses vague verbs" — Replace "manages" or "handles" with the actual action: deploy, test, build, create, analyze, review, format, lint.
"No trigger keywords" — Add "Use when..." and include synonyms of the action verb that users would naturally type.
"No examples" — Add a code block showing the key command or a numbered walkthrough of the workflow.
"No error handling" — Add a short section listing 2–3 common failure modes and what the agent should do about each.
"Heading level skipped" — Insert the missing heading level. If you have # Title followed by ### Section, add a ## Parent Section between them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

