# Claude Code skill template

> A Claude Code skill is a folder with a SKILL.md file that tells Claude when to use it and what to do, plus any files it points to. Copy the review skill below into .claude/skills in your project, then change the description and steps to fit your own task.

Updated November 8, 2026. Canonical: https://sniptide.com/templates/claude-code-skill
Open it in the Sniptide editor: https://app.sniptide.com/new?template=claude-code-skill
Files as JSON: https://sniptide.com/templates/claude-code-skill.json

## Files

### .claude/skills/review-pr/SKILL.md

```markdown
---
name: review-pr
description: Review the current branch or a pull request against this project's checklist. Use when asked to review changes, check a PR or look over a diff before merging.
---

# Review a pull request

Review the changes against the main branch and report problems, ordered by how much they matter.

## Steps

1. Read the diff: `git diff main...HEAD`. For a pull request number, run `gh pr diff <number>`.
2. Read each changed file in full where the diff alone doesn't show the context.
3. Run the checks: `pnpm lint && pnpm typecheck && pnpm test`.
4. Go through [checklist.md](checklist.md) for every changed file.
5. Report your findings in the format below.

## Report format

For each finding, give the file and line, what is wrong, and a concrete fix:

- **Blocking**: bugs, security problems, failing checks, missing tests for new behavior.
- **Should fix**: unclear names, duplicated code, missing error handling.
- **Optional**: style and small improvements.

End with one line: ready to merge, or the number of blocking findings.
Don't change any code during a review unless asked to.
```

### .claude/skills/review-pr/checklist.md

```markdown
# Review checklist

## Correctness

- Does the code do what the pull request says, including empty, missing and very large inputs?
- Are errors handled where they happen, with a message a person can act on?
- Do new database queries use an index, and do migrations run on a table with data in it?

## Tests

- Is every change in behavior covered by a test that fails without it?
- Do tests check results rather than implementation details?

## Security

- Is all user input validated before use?
- Do new routes check that the user is signed in and allowed to see the data?
- Are secrets read from the environment, never written in code or logs?

## Readability

- Do names say what things are? Would a new teammate follow the code without the PR description?
- Is there dead code, a leftover `console.log` or a commented-out block?
```

## How the skill loads [#how-the-skill-loads]

Claude keeps only the `name` and `description` of every skill in context. When a request matches the description, or you type `/review-pr`, Claude reads the body of `SKILL.md`. Other files in the folder, such as `checklist.md`, load only when the instructions point to them. That makes a long checklist cheap to keep around.

Where you put the folder decides who gets it:

| Scope | Path | Use it for |
| --- | --- | --- |
| Project | `.claude/skills/review-pr/SKILL.md` | Workflows for this codebase. Commit it and your team gets it. |
| Personal | `~/.claude/skills/review-pr/SKILL.md` | Your own workflows, in every project on your machine. |

Skills follow the [Agent Skills](https://agentskills.io) open standard, so the same folder also works in other tools that read it.

## What each part does [#what-each-part-does]

**name** is the command you type, `/review-pr`. Use lowercase letters, numbers and hyphens. It defaults to the folder name.

**description** is what Claude reads to decide whether to use the skill. Start with what the skill does, then say when to use it in the words people actually type: "review", "check a PR", "look over a diff". A vague description is the most common reason a skill never runs.

**Steps** give the order of work with exact commands. Claude follows numbered steps closely, so put the checks it must run here rather than in prose.

**Report format** makes the output the same every time, which matters when several people read the reviews.

**checklist.md** holds the detail. Split anything long or rarely needed into its own file and link it, so the main file stays short.

## Variant: a skill only you can start [#variant-a-skill-only-you-can-start]

Add `disable-model-invocation: true` for a skill with side effects, such as a release. Claude then never runs it on its own, and it starts only when you type `/release`.

```md title=".claude/skills/release/SKILL.md"
---
name: release
description: Cut a release. Bumps the version, writes the changelog and tags the commit.
disable-model-invocation: true
---

# Release

1. Make sure the working tree is clean and `main` is up to date.
2. Run `pnpm test`. Stop if anything fails.
3. Bump the version with `pnpm version <patch|minor|major>`, as given after the command.
4. Add the merged pull requests since the last tag to `CHANGELOG.md`.
5. Push the commit and the tag: `git push --follow-tags`.
```

## Variant: background knowledge for some files [#variant-background-knowledge-for-some-files]

A skill can carry knowledge rather than a task. With `user-invocable: false` it doesn't show up as a command, and `paths` limits it to the files it is about.

```md title=".claude/skills/design-system/SKILL.md"
---
name: design-system
description: The project's UI conventions. Use when writing or changing React components or styles.
user-invocable: false
paths:
  - components/**
  - app/**/*.tsx
---

# Design system

- Use the components in `components/ui` before writing new markup.
- Colors and spacing come from the Tailwind theme. Never write hex values in components.
- Every interactive element needs a visible focus style.
```

To keep a skill's code current across many projects, the [Claude Code skills tutorial](/blog/claude-code-skills) shows how to generate the folder from a Sniptide collection.