14 Claude skills examples: copy-ready SKILL.md files for real work

Below are 14 Claude skills examples, each a complete SKILL.md file you can copy as is: code review, commit message, pull request description, release notes, house writing style, write tests, API documentation, bug triage, database migration checklist, dependency upgrade, incident postmortem, codebase tour, accessibility review and meeting notes.

How to use these examples

Each example follows the open Agent Skills format, so it works in Claude Code, the Claude app and Codex.

To install one in Claude Code:

1. Create a folder named after the skill, such as ~/.claude/skills/code-review/ for all projects, or .claude/skills/code-review/ inside one repo.
2. Save the example as SKILL.md in that folder.
3. Start a new session and ask for the task in your own words, or type /code-review to run it directly.

For the Claude app, zip the folder (the folder itself at the root of the ZIP) and upload it under Customize, Skills. Anthropic's help center lists a 200-character description limit there, so shorten the longer descriptions below before you upload. For Codex, save it under ~/.agents/skills/<name>/. The Claude Skills guide covers each surface in detail.

All descriptions are written in the third person and end with a "Use when" sentence, as Anthropic's authoring best practices recommend. Edit the rules inside each skill to match your team. These are starting points, not law.

1. Code review

The everyday review: real problems first, no style nits a linter would catch.

---
name: code-review
description: Reviews a diff or pull request for bugs, edge cases, security
  issues and missing tests, and suggests the smallest fix for each. Use when
  the user asks for a code review, a PR review, or to check changes before
  merging.
---

# Code review

1. Get the changes: the diff the user gave, or git diff against the main
   branch if none was given.
2. Read the surrounding code for every changed function, including callers,
   before judging it.
3. Look for, in this order:
   - Bugs and wrong behavior
   - Unhandled edge cases: empty input, null, large input, concurrency
   - Security: injection, missing auth checks, secrets, unsafe file paths
   - Missing or weak tests for the changed behavior
4. For each finding give: file and line, severity (high, medium, low),
   why it matters in one sentence, and the smallest fix.
5. Skip formatting and naming nits unless they hide a bug.

End with a one-line verdict: "Ready to merge", "Merge after fixes" or
"Needs another pass". If there are no findings, say so in one line.

Adapt it: add your team's must-check items (logging, feature flags, metrics) under step 3, and keep the fixed output format. A predictable shape is what makes reviews quick to act on.

2. Commit message

Turns the staged diff into a Conventional Commits message.

---
name: commit-message
description: Writes a commit message from the staged changes in the
  Conventional Commits style. Use when the user asks to commit, asks for a
  commit message, or says "write the commit".
---

# Commit message

1. Read the staged diff with git diff --staged. If nothing is staged,
   say so and stop.
2. Pick one type: feat, fix, docs, refactor, perf, test, build or chore.
3. Add a scope in parentheses when one area is clearly affected:
   fix(auth): ...
4. Write the subject in the imperative, under 72 characters, no period:
   "fix(cart): handle empty cart totals"
5. If the change is not obvious from the subject, add a body after a
   blank line that explains why, not what. Wrap at 72 characters.
6. If the diff mixes unrelated changes, suggest splitting the commit and
   list the groups.

Never invent a ticket number. Add "BREAKING CHANGE:" in the footer only
when public behavior changes.

Adapt it: if your team uses ticket numbers in commits, add a step that pulls the number from the branch name, for example feature/PAY-142-refunds. In Claude Code, add disable-model-invocation: true if you'd rather Claude never commits unless you type /commit-message.

3. Pull request description

A PR body reviewers can read in a minute.

---
name: pr-description
description: Writes a pull request title and description from the branch's
  commits and diff, with summary, changes, testing notes and risks. Use when
  the user asks for a PR description, PR body, or to open a pull request.
---

# Pull request description

1. Compare the current branch with the base branch (main unless told
   otherwise). Read the commit messages and the diff.
2. Title: under 70 characters, imperative, says the outcome.
3. Body, in this order:
   - **Summary**: two or three sentences on what changes for users or
     developers, and why.
   - **Changes**: bullet list grouped by area. One line each.
   - **How to test**: numbered steps a reviewer can follow.
   - **Risks**: anything that could break, migrations, flags, rollbacks.
     Write "None known" if there are none.
4. Mention screenshots are needed if UI files changed.
5. Link the issue only if its number appears in a commit or branch name.

Keep the whole body under 250 words.

Adapt it: paste your real PR template into the skill in place of the section list, and the output will match what reviewers already expect.

4. Release notes

Groups merged work into user-facing notes.

---
name: release-notes
description: Drafts release notes from pull requests merged since the last
  tag, grouped as Breaking, New, Improved and Fixed. Use when the user asks
  for release notes, a changelog, or what shipped since the last release.
---

# Release notes

1. Find the last tag (git describe --tags --abbrev=0) and list merged pull
   requests or commits since then. If there is no tag, ask where to start.
2. Drop internal work users won't notice: refactors, CI, test-only changes,
   dependency bumps without user impact.
3. Group the rest under Breaking, New, Improved and Fixed. Leave out empty
   groups.
4. Write one line per change from the user's point of view, starting with
   a verb: "Add CSV export to reports."
5. Under Breaking, say exactly what users must change.

Output Markdown with the version and today's date as the heading.

Adapt it: change the groups to match your changelog. Many teams also add a rule like "mention the customer or issue that asked for it" to make notes more useful for support.

5. House writing style

Keeps docs, emails and UI copy in one voice. Replace the rules with yours.

---
name: writing-style
description: Applies the team's writing style to docs, READMEs, emails,
  announcements and UI text. Use when the user asks to write, edit, rewrite
  or proofread text, or to make something clearer or shorter.
---

# Writing style

Apply these rules to any text you write or edit:

1. Lead with the point. The first sentence says what the reader needs.
2. Short sentences. Aim for under 20 words. One idea per sentence.
3. Plain words: "use" not "utilize", "help" not "facilitate".
4. Active voice: "We fixed the bug", not "The bug was fixed".
5. Address the reader as "you". Refer to the company as "we".
6. No hype words: revolutionary, seamless, cutting-edge, game-changer.
7. Numbers as digits (3 files, 10 minutes). Dates as 23 October 2026.
8. Sentence case for headings.

When editing, return the revised text first, then at most five bullets on
the biggest changes. Don't change facts, names or technical terms.

Adapt it: this one works best with your own rules, not ours. Pull ten rules from your style guide, and move the full guide into references/style.md if it's long.

6. Write tests

Adds tests that match the project's existing style.

---
name: write-tests
description: Writes unit tests for a function, module or change, following
  the project's existing test framework and patterns. Use when the user asks
  for tests, more test coverage, or to test a function or bug fix.
---

# Write tests

1. Find the existing tests closest to the code under test. Copy their
   framework, file naming, folder layout and helper usage.
2. List the behaviors to cover before writing code:
   - The main success path
   - Edge cases: empty, zero, null, very large, unicode
   - Error paths: invalid input, failed dependencies
   - The exact bug, if this is a bug fix (the test must fail without the fix)
3. One behavior per test. Name tests after the behavior:
   "returns zero for an empty cart".
4. Mock only what crosses a boundary: network, clock, randomness,
   filesystem. Don't mock the code under test.
5. Run the tests. Fix failures caused by the tests themselves. If a test
   reveals a real bug, stop and report it instead of changing the code.

If no test framework is set up, ask before adding one.

Why it works: step 1 makes Claude copy your existing conventions instead of inventing new ones, and step 5 stops it from "fixing" code to make a bad test pass.

7. API documentation

Documents endpoints in one consistent shape.

---
name: api-docs
description: Writes reference documentation for REST API endpoints from the
  route handlers and types, with parameters, request and response examples,
  and errors. Use when the user asks to document an API, an endpoint or a
  route.
---

# API docs

For each endpoint, read the handler, its validation and its types, then
write:

1. **Heading**: method and path, for example `POST /v1/invoices`.
2. **Summary**: one sentence on what it does.
3. **Auth**: what is required, or "None".
4. **Parameters**: table with name, where (path, query, body), type,
   required, and description. Include defaults and limits from the code.
5. **Example request**: a curl command with realistic values.
6. **Example response**: the success JSON, trimmed to the important fields.
7. **Errors**: table of status code, error code and when it happens.

Only document behavior you can see in the code. If something is unclear,
such as a rate limit, add a "To confirm" note instead of guessing.

Adapt it: if you publish docs in a specific format, such as an OpenAPI file or a docs site with front matter, describe that format in step 7 or add a template file.

8. Bug triage

Turns a vague report into an actionable issue.

---
name: bug-triage
description: Triages a bug report into a clear issue with steps to
  reproduce, expected and actual behavior, likely cause, severity and owner
  area. Use when the user pastes a bug report, error, crash log or customer
  complaint and asks what is wrong or to file it.
---

# Bug triage

1. Restate the problem in one sentence.
2. Pull out or ask for: steps to reproduce, expected result, actual
   result, environment (version, browser or OS), and how often it happens.
3. Search the codebase for the error message, route or component named in
   the report. Name the most likely file and function, and say how sure
   you are.
4. Set severity:
   - Critical: data loss, security, or the main flow is down for everyone
   - High: a core feature is broken with no workaround
   - Medium: broken with a workaround, or affects few users
   - Low: cosmetic
5. Output a ready-to-file issue: title, the fields above, likely cause,
   and a suggested first step to fix.

Never mark something Critical without saying which rule it meets.

Adapt it: replace the severity levels with the ones your tracker uses, and add your team or component names so Claude can suggest an owner.

9. Database migration checklist

A careful process for schema changes. In Claude Code you might add disable-model-invocation: true to the header so it only runs when you type /db-migration.

---
name: db-migration
description: Plans and reviews a database schema migration with a safety
  checklist covering locking, backfills, rollbacks and deploy order. Use when
  the user is adding, changing or removing tables, columns or indexes, or
  asks to write or review a migration.
---

# Database migration

Work through this checklist and report each item as OK, Risk or N/A:

1. **Locking**: will this lock a large table? Prefer adding indexes
   concurrently and adding nullable columns first.
2. **Backwards compatibility**: can the currently deployed code run against
   the new schema? If not, split into expand and contract steps.
3. **Backfill**: is data being moved or filled? Do it in batches, outside
   the migration, and make it safe to re-run.
4. **Defaults and NOT NULL**: add the column, backfill, then add the
   constraint in a later migration.
5. **Rollback**: write the down migration, or explain why it is one-way.
6. **Deploy order**: list the steps in order, for example
   migrate, deploy, backfill, then constrain.
7. **Data loss**: flag any drop or type change that loses data, and ask
   for confirmation before writing it.

Then write the migration in the project's existing migration tool.

Why it works: this is a low-freedom skill. Migrations are where a skipped step causes an outage, so the checklist forces every item to be answered.

10. Dependency upgrade

Upgrades one package without surprises.

---
name: dependency-upgrade
description: Upgrades a package or framework to a newer version by reading
  its changelog, finding affected code, making the changes and running the
  tests. Use when the user asks to upgrade, update or bump a dependency, or
  to fix deprecation warnings.
---

# Dependency upgrade

1. Note the current and target versions. If no target is given, use the
   latest stable release.
2. Read the changelog or migration guide for every major version in
   between. List the breaking changes that could affect this project.
3. Search the codebase for each affected API and list the files.
4. Upgrade the package with the project's package manager and update
   the lockfile.
5. Fix each affected call site. Keep changes minimal: no unrelated
   refactors.
6. Run the type checker, linter and tests. Fix what the upgrade broke.
7. Summarize: versions, breaking changes handled, files changed, and
   anything left to check by hand.

Upgrade one major version at a time if the jump spans more than one.

Adapt it: name your package manager and test commands, such as pnpm and pnpm test, so Claude doesn't have to guess.

11. Incident postmortem

A blameless write-up from notes, logs and chat.

---
name: incident-postmortem
description: Writes a blameless incident postmortem from notes, timelines,
  logs and chat transcripts, with impact, root cause and action items. Use
  when the user asks for a postmortem, incident report, incident review or
  RCA.
---

# Incident postmortem

Write these sections:

1. **Summary**: what happened, in three sentences or fewer.
2. **Impact**: who was affected, for how long, and how badly. Use numbers
   from the source material only.
3. **Timeline**: times with time zone, one line each, from first signal to
   full recovery.
4. **Root cause**: the technical chain of events. Keep asking why until you
   reach something the team can change.
5. **What went well** and **what went poorly**: short bullets.
6. **Action items**: table of action, owner, and priority. Each one must
   prevent a repeat, speed up detection, or reduce impact.

Describe systems and decisions, never blame people. If a fact is missing,
write "Unknown" rather than guessing.

Adapt it: if your company has a postmortem template, paste its headings in place of these. Keep the blameless rule and the "Unknown" rule either way.

12. Codebase tour

Onboards someone to an unfamiliar repo.

---
name: codebase-tour
description: Gives a guided tour of an unfamiliar codebase, covering what it
  does, how it is laid out, how a request flows through it, and how to run it.
  Use when the user is new to a repo or asks how the code is organized,
  where something lives, or to explain the project.
---

# Codebase tour

1. Read the README, the package or build files, and the top-level folders.
2. Explain, in this order:
   - What the project does, in two sentences
   - The stack: languages, frameworks, database, hosting
   - The folder layout: one line per important folder
   - One real request or job traced end to end, naming each file it
     passes through
   - How to install, run and test it locally
   - Where to start for a typical first change
3. Name files with their paths so the user can open them.

Stay under 500 words unless the user asks for more. Say when you are
inferring something rather than reading it from the code.

Adapt it: commit this one to a repo's .claude/skills/ folder and new teammates get a consistent tour on day one.

13. Accessibility review

Catches the common UI accessibility misses.

---
name: accessibility-review
description: Reviews UI code such as React, Vue or HTML components for
  accessibility problems against WCAG basics, with fixes. Use when the user
  asks for an accessibility or a11y review, or to check a component, form
  or page for screen reader and keyboard support.
---

# Accessibility review

Check the changed UI code for:

1. **Semantics**: buttons are button elements, links are a elements,
   headings are in order, lists use list elements.
2. **Names**: every input has a label, every icon-only button has an
   accessible name, images have useful alt text or empty alt if decorative.
3. **Keyboard**: everything clickable is reachable with Tab and works with
   Enter or Space. Focus is visible. Dialogs trap and return focus.
4. **Color**: text contrast meets 4.5:1 (3:1 for large text). Color is not
   the only way information is shown.
5. **Motion**: animations respect prefers-reduced-motion.
6. **Forms**: errors are announced and tied to their field.

For each issue give the file and line, who it affects, and the fix as a
code snippet.

Adapt it: add the components from your design system that already handle focus and labels, so Claude knows which patterns are safe.

14. Meeting notes

Not every skill is about code.

---
name: meeting-notes
description: Turns a meeting transcript or rough notes into short notes with
  decisions, action items with owners, and open questions. Use when the user
  pastes a transcript or notes and asks for a summary, minutes, recap or
  action items.
---

# Meeting notes

Write, in this order:

1. **Title and date**, taken from the source if present.
2. **Summary**: up to three sentences.
3. **Decisions**: bullets, each a full sentence.
4. **Action items**: checklist with owner and due date, for example
   "- [ ] Maya: send the revised quote by Friday". Write "Owner: unclear"
   when no one was named.
5. **Open questions**: anything raised but not settled.

Leave out small talk. Keep names exactly as written in the source. Do not
add decisions or deadlines that weren't stated.

Adapt it: set the action item format to match your task tool so you can paste the list straight into it.

Make the examples your own

The examples work out of the box, but the best skills carry your team's specifics. A few ways to adapt them:

• Swap in your real rules. Your commit types, your severity levels, your writing rules. Generic rules give generic output.
• Add an example of good output. If format matters, a short sample inside the skill beats a paragraph describing it.
• Move long lists to their own file. If the code review checklist grows to 60 items, put it in references/checklist.md and link it from SKILL.md.
• Tighten the description if a skill fires too often, or broaden it with more trigger words if it never fires.

The full rules for names, descriptions and structure are in how to write a SKILL.md. For skills other people maintain, see the best Claude Code skills.

Turn your own prompts into skills

Most of the skills above began as prompts that got pasted one too many times. If you have prompts like that, the free SKILL.md generator turns one into a valid skill in your browser, and the code review prompts page has more starting points.

Kipt keeps prompts and skills together in a private GitHub repo you own. Save a prompt by pasting it, find it with ⌘K, and choose Promote to skill when it's ready to become a SKILL.md. Every skill in your library then installs into Claude Code or Codex with one npx skills add command.