The idea

A skill is a named, reusable set of instructions for an AI coding tool. It captures a procedure you use more than once: a debugging checklist, a code-review routine, or a release-note workflow. Instead of pasting the same long prompt into every chat, you keep the procedure in one place and use it when the task fits.

This is useful when your project has two kinds of guidance. Some rules matter for almost every task. Other instructions matter only for a particular job. For example, a project-wide convention may belong in CLAUDE.md for Claude Code. A detailed debugging routine can be a skill that is brought in only when you debug. Anthropic says Claude Code loads a skill’s body when the skill is used, while CLAUDE.md content is persistent context. Source: Anthropic

Plain English: A skill is a saved playbook for a recurring kind of work. It gives an AI tool more specific instructions at the moment you need them.

In Claude Code, a skill is created with a SKILL.md file containing instructions. The documentation says a skill can be used automatically when relevant or invoked directly with /skill-name. Source: Anthropic GitHub describes agent skills as folders that can contain instructions, scripts, and resources for an agent to load when relevant. Source: GitHub

The details are tool-specific. “Skill” is a useful general idea, not one universal file format or command. GitHub documents several possible project locations, including .github/skills, .claude/skills, and .agents/skills, but support depends on the Copilot surface involved. Source: GitHub

A small example

Hypothetical example: Your team often investigates frontend bugs. Each time, you paste instructions asking the AI tool to reproduce the problem, inspect the relevant code, run the project’s appropriate tests, and report what it verified.

You could create a skill named frontend-debug. Its SKILL.md could state:

  1. Start by asking for or recording reliable reproduction steps.
  2. Identify the likely component and related tests.
  3. Propose a small change and explain why it addresses the reproduction.
  4. Run only the project-approved checks named in the procedure.
  5. End with what changed, what was checked, and what remains uncertain.

The point is not that these exact steps fit every project. The point is to make your team’s existing procedure explicit. A good skill has a clear purpose, ordered steps, and a visible stopping point. It may also refer to files or scripts in its own directory where the tool supports that pattern. Source: Anthropic

Try it

Take five minutes. Find one block of instructions you have pasted at least twice. Do not automate it yet.

First, give the procedure a short name. Then write one sentence describing when it should be used. List three to five ordered steps. Add a final check such as “summarize changed files and tests run.” Finally, remove advice that is already a project-wide rule. That separation helps keep the skill focused.

If your tool supports skills, compare its documentation with your draft before choosing a directory, file format, or invocation syntax. Start with a read-only task, such as preparing a review checklist, rather than one that changes files.

Watch out

A skill is instructions, not a guarantee of correct work. Automatic selection may not happen, so direct invocation can be clearer for an important procedure. The AI tool can still misunderstand the task or produce an incorrect change.

Review generated code, scripts, and commands before accepting or running them. Treat a skill directory like other project automation: inspect what it contains and consider permissions before sharing or enabling it. Also avoid turning every tiny preference into a skill. A skill earns its place when it preserves a procedure you genuinely repeat and want to improve over time.