Can I use these SKILL.md examples as they are?

Yes, they are complete and pass the format checks, but each encodes one way of doing a task. Read the rules and the example and change anything that does not match how you work, especially file paths and tool names in the data example, which are placeholders.

Do these examples work in claude.ai as well as Claude Code?

Yes. They use only the six fields in the Agent Skills specification, which is what claude.ai uploads and the Skills API accept. Add Claude Code-only fields such as model or paths only to a copy you keep in Claude Code.

Why is there no version field?

The specification has no version field in the frontmatter, and some validators reject unknown top-level fields. If you want to record a version, put it under metadata, which is a map made for exactly that.

How do I turn one of these into a skill with scripts?

Add a scripts folder beside SKILL.md, reference each script with a forward-slash relative path, and say whether Claude should run it or read it. The data example shows the pattern. How to structure a SKILL.md file covers the folder layout in full.

SKILL.md Examples and Templates

By Rehan Shah, Published October 12, 2026

The fastest way to understand the SKILL.md format is to read a few finished files. These five SKILL.md examples are complete, pass the format checks, and use only the six frontmatter fields in the Agent Skills specification, so each works in Claude Code, claude.ai, and the API. Copy the one nearest your task and change the specifics.

The short answer

Every example below has the same bones: frontmatter with a name that matches the folder and a description that says what the skill does and when to use it, then a body with steps, one example, and the edge cases. That is the whole format. The differences are in how much structure the task needs.

1. A minimal SKILL.md template

Start here for a skill that is mostly instructions. Replace every line in brackets. The folder must be named exactly what the name field says.

---
name: skill-name
description: [What the skill does, in third person.] Use when [the words a request would contain].
---

## Steps
1. [First thing Claude should do.]
2. [Second thing.]
3. [Check the result against the rules below before answering.]

## Rules
- [A rule that matters, phrased firmly.]
- [Another.]

## Example
Input: [a realistic request]
Output: [exactly what a good answer looks like]

## Edge cases
- [What to do when the input is missing something.]

2. Release notes from pull request titles

A writing skill with a fixed output shape. The description names both the task and the trigger phrases, and the example pins the style.

---
name: writing-release-notes
description: Turns a list of merged pull request titles into end-user release notes grouped under Added, Changed, and Fixed. Use when the user asks for release notes or a changelog for a version.
---

## Steps
1. Read every title in the list.
2. Drop internal-only changes: refactors, test-only changes, CI, dependency bumps.
3. Rewrite each remaining title for an end user. No ticket numbers, no code identifiers.
4. Group under Added, Changed, Fixed. Omit a heading with no items.

## Rules
- One line per change, no trailing period.
- Say what the user can now do, not what the code does.
- Never invent a change that is not in the list.

## Example
Input:
- feat(export): allow CSV export of filtered views (#412)
- fix: date picker ignored timezone on Safari
- chore: bump eslint

Output:
## Added
- Export a filtered view as CSV

## Fixed
- Dates picked in Safari now respect your timezone

## Edge cases
- If every change is internal, output one line: "No user-facing changes in this release."

3. Commit messages from a diff

The examples pattern from Anthropic's authoring guide: three input and output pairs teach the style better than a paragraph about it.

---
name: generating-commit-messages
description: Writes a conventional commit message from staged changes or a diff. Use when the user asks for a commit message or runs git commit without one.
---

## Steps
1. Read the diff. Identify the one primary change; secondary changes go in the body.
2. Pick a type: feat, fix, docs, refactor, test, chore.
3. Write the subject in the imperative, under 72 characters, no period.
4. Add a body only when the why is not obvious from the subject.

## Examples
Diff adds a JWT check to the login route:
feat(auth): validate JWT on login

Diff fixes a timezone bug in report dates:
fix(reports): use UTC when formatting report dates

Diff updates lodash and tidies error handling:
chore: update lodash and standardise error responses

## Edge cases
- Mixed unrelated changes: suggest splitting the commit and write the message for the largest change.

4. A pull request review checklist

A procedure with a feedback loop. The checklist is written so Claude can copy it into the reply and tick items off, which Anthropic recommends for multi-step work.

---
name: reviewing-pull-requests
description: Reviews a pull request against a fixed checklist and reports findings by severity. Use when the user asks for a code review, a PR review, or to check a branch before merging.
---

## Process
Copy this checklist into your reply and complete every line:

- [ ] Behaviour: does the change do what the PR description says?
- [ ] Tests: is new behaviour covered? Do existing tests still pass?
- [ ] Errors: are failure paths handled, not swallowed?
- [ ] Security: any input reaching a shell, a query, or HTML unescaped?
- [ ] Naming and structure: consistent with the surrounding code?

## Report format
For each finding: file and line, what is wrong, why it matters, a concrete fix.
Order findings by severity: blocking, should fix, nit.
End with one sentence: merge, merge after fixes, or do not merge.

## Rules
- Quote the code you are commenting on.
- Do not restate the diff. Only report what should change.

## Edge cases
- A PR with no description: ask for one before reviewing behaviour, then continue with the other checks.

5. A data skill with reference files

Progressive disclosure in practice. The body stays short and points at one reference file per area, so a question about sales loads sales.md and nothing else. The compatibility field is used because the skill needs a tool the environment may not have.

---
name: querying-sales-data
description: Answers questions about revenue, pipeline, and product usage by writing SQL against the warehouse schemas in this skill. Use when the user asks for sales numbers, pipeline reports, or usage metrics.
compatibility: Requires access to the warehouse through the BigQuery MCP server
---

## Before writing any query
1. Identify the area: revenue, pipeline, or product usage.
2. Read only that area's reference file:
   - Revenue and billing: references/finance.md
   - Opportunities and pipeline: references/sales.md
   - API usage and features: references/product.md
3. Always exclude test accounts: WHERE account.is_test = false

## Running the query
Use the BigQuery:bigquery_query tool. Validate first with
scripts/validate_query.py, which checks table names against the schema
and fails with a message naming the unknown table.

## Output
A short answer first, then the query in a code block, then caveats.

## Edge cases
- The question spans two areas: read both files, join on account_id.
- A metric is not defined in any reference file: say so and ask, do not guess a definition.

What every example has in common

A name that is a valid folder name: lowercase, hyphens, under 64 characters, no reserved words.
A description in third person that says what and when, with the nouns a request would contain. This is the line Claude matches against.
Steps before rules, one example, then edge cases. The order Claude reads in.
Only specification fields in the frontmatter, so the same file uploads to claude.ai and the API. Claude Code extras such as disable-model-invocation can be added for a Claude Code-only copy.
Under 100 lines each. None needs the 500-line limit.

How to adapt one

Copy the example into a file named SKILL.md inside a folder with the same name as the name field. Change the description first, since it decides whether the skill triggers, then the steps, then the example. Paste the result into the SKILL.md Generator's check mode to confirm the frontmatter still passes, and test it with a real request as described in how to create a Claude skill. If you would rather start from a description than a template, the same page generates a draft in this shape.

Common questions

Can I use these SKILL.md examples as they are?: Yes, they are complete and pass the format checks, but each encodes one way of doing a task. Read the rules and the example and change anything that does not match how you work, especially file paths and tool names in the data example, which are placeholders.
Do these examples work in claude.ai as well as Claude Code?: Yes. They use only the six fields in the Agent Skills specification, which is what claude.ai uploads and the Skills API accept. Add Claude Code-only fields such as model or paths only to a copy you keep in Claude Code.
Why is there no version field?: The specification has no version field in the frontmatter, and some validators reject unknown top-level fields. If you want to record a version, put it under metadata, which is a map made for exactly that.
How do I turn one of these into a skill with scripts?: Add a scripts folder beside SKILL.md, reference each script with a forward-slash relative path, and say whether Claude should run it or read it. The data example shows the pattern. How to structure a SKILL.md file covers the folder layout in full.

Try it yourself

SKILL.md GeneratorDescribe a task to get a SKILL.md draft for Claude, or paste one to check it against the published format.

These live under Developer tools, alongside the rest of the claude skills & skill.md guides on the guides page.