How to create Claude skills in Claude Code

Where a skill lives decides who gets it

From the Claude Code docs, read 5 November 2026. When two locations hold a skill with the same name, an enterprise-managed one wins over a personal one, and a personal one over the project's.

A worked example: a release-notes skill

Illustration: a made-up business. A six-person product team writes customer-facing release notes every two weeks. The product manager writes them from the merged pull requests, and the tone varies with whoever is on duty. They add a project skill:

.claude/skills/release-notes/SKILL.md

---
name: release-notes
description: Writes customer-facing release notes from merged changes since the last tag. Use when someone asks for release notes, a changelog for customers, or "what shipped".
---

## Changes since the last release
!`git log --oneline $(git describe --tags --abbrev=0)..HEAD`

## Instructions
1. Group changes as New, Improved, Fixed. Skip internal-only changes
   (tests, refactors, CI).
2. One line per change, written for a customer: what they can do now.
3. Never mention ticket numbers or internal names.
4. End with "Questions? Reply to this email."

The !`...` line runs the command and puts its output into the skill before Claude reads it, so the skill starts from the real list of changes. Now anyone on the team types "release notes for this sprint" and gets the same structure. Committing the folder shares it; the next git pull updates it for everyone.

Create and test yours

1. Make the folder: mkdir -p .claude/skills/release-notes (or under ~/.claude/skills/ for a personal one).
2. Write the header: a description that leads with the main use and lists the words people type; name is optional and defaults to the folder name.
3. Write the steps as numbered actions with the fixed wording spelled out. Keep SKILL.md under 500 lines; move long reference material into files beside it.
4. Test automatic use: ask for the task in three different phrasings. If Claude doesn't pick it, improve the description.
5. Test direct use: type /release-notes.
6. Commit it when it works, so the team gets the same version.

Next step: sharing beyond the repository

A project skill reaches the people working in that repository. For skills the whole engineering team uses across repositories, a plugin marketplace on GitHub is the usual next step, and colleagues who never open Claude Code need yet another route. How to share Claude skills on GitHub compares the options. If teammates also use Codex, Cursor or OpenCode, syncing skills across coding agents covers that.

The AI skill below writes the SKILL.md for you from a prompt or doc that works: a valid name, a description that says when to use it, numbered steps, a template, an example and checks.

Questions

Where do I put a skill in Claude Code?

In ~/.claude/skills//SKILL.md for a skill you use in all your projects, or in .claude/skills//SKILL.md inside a repository for a skill the whole team gets when they clone it.

How do I run a skill in Claude Code?

Either ask for the task and let Claude match it to the skill's description, or type /skill-name. Add disable-model-invocation: true to a skill with side effects, such as a deploy, so it only runs when you type its name.

Do I have to restart Claude Code after editing a skill?

No. Claude Code watches the skill folders, so an edit to SKILL.md takes effect in the current session.