agentleFS
skill-toolsskill-tools/skill-tools-plugin/skills/skill-quality/SKILL.md

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

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. adhi-jp/agent-skills★ 1same name
    2. amandeepmittal/expo-docs-skills★ 1same name
    3. 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
  1. Distinctive:

    Every quality issue traces back to one of these two jobs failing.

    line 20
  2. Distinctive:

    Start with what the skill *does* (a specific verb, not "manages" or "handles")

    line 46
  3. Distinctive:

    Add "Use when..." to spell out the trigger conditions

    line 47
  4. Distinctive:

    If you don't tell the agent how to handle failures, it will either retry forever or give up silently.

    line 69
  5. Very specific:

    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.

    line 85
  6. Distinctive:

    No absolute paths: Use relative paths or environment variables.

    line 101
  7. Distinctive:

    Run the quality tools to catch issues before they bite you:

    line 106

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Gets selected — The agent reads the description to decide whether this skill matches what the user asked for. If the description is vague, the agent skips it.
  2. 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 --yes

The 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 examples

The 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.md

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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.