agentleFS
jaktestowacjaktestowac/awesome-copilot-for-testers/skills/creating-skills/SKILL.md

creating-skills

Skill118 starsChanged 2 months agoMITView on GitHub

Creates GitHub Copilot skills with reusable workflows, companion resources, and validation gates. Use when packaging repeatable expertise into a `SKILL.md` folder, deciding what belongs in the skill body versus resources, or producing install-ready skill examples for a team or collection.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 27 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when reusable know-how deserves a home of its own instead of living in prompts or chat history.

    line 10
  2. Distinctive:

    Use this skill when the user asks for things like:

    line 15
  3. Very specific:

    Progressive disclosure: - keep the skill body focused.

    line 44
  4. Distinctive:

    One coherent capability: - avoid turning one skill into a junk drawer of unrelated workflows.

    line 45
  5. Distinctive:

    Default to a small bundle first.

    line 75
  6. Distinctive:

    Use these support files when building the folder:

    line 89
  7. Very specific:

    Check the final result against ./resources/skill-quality-checklist.md.

    line 103

“Common” is measured: kept by at least 6 in 10 of the 27 edited versions of this file we could read. “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

Creating Copilot Skills

Use this skill when reusable know-how deserves a home of its own instead of living in prompts or chat history. It helps create skills that are discoverable, concise, and bundled with the right supporting assets.

When to Use

Use this skill when the user asks for things like:

  • "create a new Copilot skill"
  • "package this workflow as a reusable skill"
  • "turn our team process into a SKILL.md"
  • "add templates and examples to a skill folder"
  • "fix a skill that is too long, vague, or hard to trigger"

Typical scenarios:

  • creating a brand-new skill folder
  • refactoring a bloated SKILL.md into a leaner body plus resource files
  • improving discovery quality through better naming and descriptions
  • preparing a public-ready skill with templates, examples, and a validation checklist

Outcome Standard

A strong skill contribution usually includes:

  • a name that clearly describes the activity the skill supports
  • a description that explains both what the skill does and when to use it
  • a SKILL.md body that teaches a workflow, not a persona
  • supporting resources that are loaded on demand instead of bloating the main file
  • a clear definition of done so the agent knows when to stop

Skill Design Rules

  • Activity, not topic - name the skill after the task it performs, not the subject area alone.
  • Trigger-friendly descriptions - include realistic user phrases and contexts.
  • Progressive disclosure - keep the skill body focused; move templates, examples, and detailed checklists into resources/.
  • One coherent capability - avoid turning one skill into a junk drawer of unrelated workflows.
  • Workflow first - the main body should help the agent execute the task step by step.

Workflow

Phase 0: Frame the capability

Clarify or infer:

  • the exact task the skill should help perform
  • the signals that should trigger the skill
  • the expected output or artifact bundle
  • what makes the skill distinct from nearby skills in the repository

Phase 1: Map the activation surface

Before writing:

  • inspect nearby skills for naming, tone, and scope boundaries
  • list the phrases a user would naturally use when asking for this capability
  • identify which context belongs in the body and which belongs in resources

Phase 2: Design the skill folder

Plan the folder contents before drafting:

  • SKILL.md for the activation and workflow logic
  • resources/ for templates, examples, decision guides, or checklists
  • optional scripts only when executable logic is genuinely useful

Default to a small bundle first. Add more files only when they remove ambiguity or repetition.

Phase 3: Draft the SKILL.md

Make the main file do the high-value work:

  • introduce when the skill should activate
  • explain what a good outcome looks like
  • provide a concrete workflow with phases or checklists
  • link to supporting files instead of duplicating their content
  • include a short definition of done

Phase 4: Add the artifact bundle

Use these support files when building the folder:

  • ./resources/SKILL.template.md
  • ./resources/SKILL.example.md
  • ./resources/skill-quality-checklist.md

At minimum, include:

  • one template or scaffold
  • one example showing tone and scope
  • one checklist or quality gate for final validation

Phase 5: Validate for discoverability

Check the final result against ./resources/skill-quality-checklist.md.

Pay special attention to:

  • whether the name still makes sense as a slash command
  • whether the description would help an agent choose the skill correctly
  • whether the workflow is concrete enough to execute without guesswork
  • whether supporting files are shallow, relevant, and clearly named

Common Failure Modes

  • using a noun like playwright or security as the entire skill name
  • writing a description that says what the skill is about but never says when to use it
  • turning the body into a long theory document instead of a working procedure
  • embedding templates inline until the skill becomes noisy and fragile
  • mixing multiple loosely related jobs into one skill because they feel adjacent

Resource Map

  • ./resources/SKILL.template.md - base scaffold for the main skill file
  • ./resources/SKILL.example.md - complete example of a compact, user-invocable skill
  • ./resources/skill-quality-checklist.md - final review checklist before shipping

Definition of Done

A task using this skill is complete when:

  • the folder name, frontmatter name, and skill purpose all align
  • the description is discoverable and specific
  • the body teaches a repeatable workflow rather than generic advice
  • templates, examples, and validation material exist where they reduce ambiguity
  • the final bundle passes the checklist without obvious overlap or missing context

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.