Skip to content

Chapter 8 of 14 · Create · 5 min read

Write your first agent skill, step by step

AI Tool Garage editors·

The best first skill is one that captures something you already do well and are tired of explaining. In this chapter you’ll build a complete, working skill from an empty folder: a pull-request description writer that turns a branch’s changes into a clear, consistent description. Along the way you’ll learn the pieces every skill needs. You can follow the same steps for any task, from meeting notes to SEO briefs.

Step 1: choose the job

Good first skills share three traits: the task comes up often, you can tell a good result from a bad one, and the agent gets it slightly wrong without help. Before writing anything, jot down how you’d do the task and what you usually correct.

  • Task: write a pull-request description for the current branch.
  • What good looks like: a one-line summary, why the change was made, what changed, how it was tested, anything risky.
  • What the agent gets wrong without help: lists every file instead of explaining the change, invents testing it didn’t do, forgets the risks.

Step 2: create the folder

A skill is a folder whose name matches the skill’s name. Use lowercase letters, numbers and hyphens. For a personal skill in Claude Code, create it under ~/.claude/skills/; for a team skill, under .claude/skills/ in the repository.

Create the skill folder

mkdir -p ~/.claude/skills/pr-description cd ~/.claude/skills/pr-description touch SKILL.md

Step 3: write the frontmatter

The frontmatter is a YAML block at the very top of SKILL.md, between two lines of three dashes. It needs two fields. name identifies the skill. description tells the agent what the skill does and when to use it; this is what the agent reads to decide whether to load the skill, so be specific.

SKILL.md: frontmatter

--- name: pr-description description: Write a clear pull-request description for the current branch from its commits and diff. Use when the user asks to write, draft or improve a PR description, or is about to open a pull request. ---

Describe both what the skill does and when to use it, using the words people actually say: “PR description”, “pull request”, “open a PR”. Chapter 9 goes deeper.

Step 4: write the instructions

After the frontmatter comes the body, in plain Markdown. Write it like a briefing for a capable colleague who has never seen your project: clear steps in order, the rules that matter, and what to do in awkward cases. Prefer specific instructions (“run git log main..HEAD --oneline”) over general ones (“look at the changes”).

SKILL.md: body

# Pull-request description Write a description a reviewer can understand in under a minute. ## Steps 1. Find the base branch (usually main). Run `git log main..HEAD --oneline` and `git diff main...HEAD --stat` to see what changed. 2. Read the diff for the most important files. Don't describe every file. 3. Work out *why* the change was made. Use commit messages, linked issue numbers and the code itself. If the reason isn't clear, ask the user. 4. Write the description using the format below. 5. Show it to the user. Don't open the pull request unless they ask. ## Format **Summary**: one sentence, starting with a verb. **Why**: two or three sentences on the problem this solves. **What changed**: three to six bullets, grouped by behaviour, not by file. **Testing**: what was actually run. If you didn't run tests, say so. Never claim testing that didn't happen. **Risks**: anything a reviewer should look at closely, such as migrations, config changes or public API changes. Write "None known" if there are none. ## Rules - Plain language. Explain jargon or leave it out. - No file-by-file lists, no marketing tone, no emoji. - Keep it under 250 words unless the change is genuinely large.

Step 5: add an example

One good example teaches tone and level of detail better than a page of rules. Add it at the end of the body, clearly labelled as an example so the agent doesn’t copy it word for word.

SKILL.md: example section

## Example **Summary**: Add CSV export to the monthly report page. **Why**: Finance exports the report by copying the table into a spreadsheet, which breaks formatting and drops rows past the first page. **What changed**: - New "Export CSV" button on the report page - Export streams all rows, not just the visible page - Dates and currency use the user's locale settings **Testing**: Added unit tests for the CSV formatter; ran the full test suite; exported a report with 12,000 rows manually. **Risks**: Large exports run on the web server. Watch memory on the first day after release.

The complete file

Put the three parts together, frontmatter, body and example, and you have a finished skill. It’s a single file, short enough to read in two minutes, and it covers what the agent needs every time. There are no scripts or extra files yet; Chapter 10 shows when to add them.

~/.claude/skills/pr-description/ — final layout

pr-description/ └── SKILL.md # frontmatter + steps + format + rules + example

Step 6: try it

  1. Start a new session in a repository with a branch that has a few commits.
  2. Ask in your own words: “Can you write the PR description for this branch?”
  3. Watch for the skill being loaded, then check the result against your format.
  4. Try a second phrasing, such as “I’m about to open a pull request, draft the text”, to check the description triggers reliably.
  5. Try an awkward case: a branch with no clear reason for the change. Does the agent ask, as instructed?

If the skill never seems to load, check three things: SKILL.md sits directly inside the skill folder, the frontmatter starts on the first line with three dashes, and the YAML is valid. A stray tab or an unquoted colon in the description can break it, so wrap the description in quotes if it contains a colon.

Step 7: refine

Your first version won’t be perfect, and that’s fine. Each time the agent does something you’d correct, decide whether it’s a missing rule, an unclear step or a weak example, and fix that one thing. Keep the file focused. When it starts growing past what every use needs, move detail into separate files. Chapter 11 covers testing and iteration properly.

Common first-skill mistakes

  • Writing a description that says what the skill is but not when to use it.
  • Restating generic advice the model already follows, which costs context and adds nothing.
  • Making one skill do several unrelated jobs. Split it.
  • Using vague verbs such as “handle”, “manage” or “deal with” instead of concrete actions.
  • Forgetting to tell the agent what not to do, such as claiming tests it didn’t run.

Key takeaways

  • A skill is a folder named after the skill, containing SKILL.md.
  • Frontmatter needs name and a specific description covering what and when.
  • The body is a clear briefing: steps, format, rules and one example.
  • Test with several phrasings and an awkward case, then refine one thing at a time.

Put it into practice

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Written by the AI Tool Garage editors. Tool details link to their catalogue pages, which are refreshed weekly; spotted something out of date? Tell us.