Create a skill

Good skills come from real, repeated work. If you explain the same thing to your agent every week, it should be a skill.

1. Pick one job#

A skill does one thing well: "write release notes", "add an API endpoint the way this repo does it". If you need "and", you probably need two skills.

2. Create the folder#

mkdir -p .claude/skills/release-notes

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

---
name: release-notes
description: Drafts release notes from the merged pull requests since the last tag. Use when preparing a release or when the user asks for release notes.
license: MIT
version: 1.0.0
use_when:
  - Preparing a release
avoid_when:
  - The project generates notes automatically in CI
---

# Release notes

1. Find the last tag: `git describe --tags --abbrev=0`.
2. List merged PRs since then: `git log <tag>..HEAD --merges --oneline`.
3. Group them into Features, Fixes and Internal …

The name must match the folder. Keep the body focused: steps, rules, one or two examples.

3. Add resources only when needed#

Long reference material belongs in separate files that the skill links to (reference.md, templates/). Scripts are possible, but every script is something the agent runs — keep them small, readable and free of downloads (see Writing secure skills).

4. Test it with your agent#

Start a fresh session and ask for the task without naming the skill. If the agent does not pick it up, sharpen the description. If it does the job differently than you want, make the steps more explicit or add an example.

5. Check it against the rules#

Read the verification rules once: they list every security pattern with an example, how context (code block, prose, negated example) changes its severity, and the structure limits. After publishing, the report on the package page shows every finding with file and line — fix them and push again; each push creates a new, re-verified version.

6. Publish#

Push the folder to a public GitHub repository with a LICENSE file, then publish it on Denofy. Denofy imports the folder, verifies it, pins it to the commit and shows the report. With the GitHub webhook every push creates a new version automatically. Details: Publishing.