Claude Code Skills: 10 Real Examples (2026)

What is a Claude Code skill, exactly?

A Claude Code skill is a directory that contains a required SKILL.mdfile — a Markdown document with a YAML frontmatter block at the top and instructions in the body below. Only two frontmatter fields are required: name (lowercase, numbers and hyphens, up to 64 characters) and description (up to 1024 characters, written in the third person, stating both what the skill does and when to use it). The description is the most important line you will write, because Claude reads it to decide whether a request should auto-trigger the skill.

Skills live in one of two main places: ~/.claude/skills/<name>/SKILL.md for personal skills available across every project, or .claude/skills/<name>/SKILL.md committed to a repo so the whole team shares them. Keep the body under 500 lines and rely on progressive disclosure: metadata is always loaded (about 100 tokens per skill), the full body loads only when the skill triggers, and any bundled scripts or reference files load on demand — with scripts executed via bash so their code never enters the context window. For the complete mechanics, see the Claude Code skills guide.

Every example below follows that shape. The frontmatter is minimal on purpose — name and descriptiononly — and the body is summarized to one line so you can scan all ten quickly. In a real skill, that body is where the full checklist or procedure lives, and Claude Code never loads it until the description matches what you asked for. That is the whole point of progressive disclosure: a library of fifty skills costs almost nothing at rest, because only the one-line metadata is in context until a skill is actually needed. Read the descriptionfield in each block as the trigger contract — the “what” tells Claude the skill exists, and the “when” tells it the moment to reach for it.

1. Code review

A senior-engineer review pass that surfaces real problems instead of bikeshedding — hardcoded secrets, N+1 queries, race conditions, and the patterns that actually break in production.

---
name: code-review
description: Reviews code for correctness, security, performance, and
  maintainability before merge. Use when the user asks to review a diff, a
  pull request, or a file, or says "review this".
---

# Code Review
Walk the diff and flag issues by severity (CRITICAL/HIGH/MEDIUM/LOW):
secrets, injection, N+1 queries, race conditions, missing error handling.

When it triggers: when you ask Claude to review a diff, a pull request, or a specific file.

2. Commit conventions

Enforces Conventional Commits and atomic-PR discipline so the history stays readable and every changelog generator gets the format it expects.

---
name: commit-conventions
description: Writes Conventional Commit messages (feat/fix/refactor/etc) and
  keeps pull requests atomic. Use when the user is committing, staging
  changes, or opening a pull request.
---

# Commit Conventions
Format: <type>(<scope>): <subject>. One logical change per commit;
imperative mood; body explains why, not what.

When it triggers: when you commit, stage changes, or open a pull request.

3. TypeScript strict

Treats the type system as the primary correctness tool — no any, no unguarded assertions, exhaustive switches, and parse-don’t-validate at the boundaries.

---
name: typescript-strict
description: Enforces type-first TypeScript with no any, exhaustive
  discriminated unions, and parse-don't-validate. Use when writing or
  reviewing TypeScript code.
---

# TypeScript Strict
Forbid any, enums, and React.FC. Prefer branded IDs, narrow at boundaries,
and make every switch over a union exhaustive.

When it triggers: when you write or review TypeScript.

4. Security review

An OWASP-aligned vulnerability checklist for the code that handles auth, payments, and user input — the surfaces where bugs become incidents.

---
name: security-review
description: Audits code for OWASP-aligned vulnerabilities across auth,
  injection, secrets, crypto, and dependencies. Use when adding
  authentication, handling user input, or touching payment or sensitive code.
---

# Security Review
Check authn/authz, injection, secret handling, crypto, dependency CVEs,
and logging. Flag each finding CRITICAL/HIGH/MEDIUM/LOW with a fix.

When it triggers: when you add authentication, handle user input, or work on payment or otherwise sensitive code.

5. TDD workflow

Red, green, refactor — enforced. No production code without a failing test that demands it, and every bug becomes a permanent regression net.

---
name: tdd-workflow
description: Enforces test-driven development (RED then GREEN then REFACTOR)
  for new features and bug fixes. Use when implementing a feature or fixing
  a bug.
---

# TDD Workflow
Write a failing test first. Add the minimal code to pass. Refactor.
Never write production code without a test that demands it.

When it triggers: when you implement a new feature or fix a bug.

6. Accessibility (WCAG 2.2 AA)

Semantic HTML first, ARIA only where needed — covering keyboard navigation, focus management on route change, contrast, form errors, and the screen-reader pitfalls that fail audits.

---
name: accessibility-a11y
description: Reviews and builds UI to WCAG 2.2 AA — keyboard, focus, screen
  readers, contrast, and motion. Use when building or reviewing frontend
  components or markup.
---

# Accessibility (WCAG 2.2 AA)
Semantic elements before ARIA. Manage focus on route change. Verify
contrast, label every control, and respect prefers-reduced-motion.

When it triggers: when you build or review frontend components and markup.

7. API docs writer

Generates and updates reference docs from your endpoints — request and response shapes, status codes, and example calls — in the format your docs site already uses.

---
name: api-docs-writer
description: Documents HTTP API endpoints with request/response schemas,
  status codes, and example calls. Use when adding or changing a route or
  when the user asks to document an API.
---

# API Docs Writer
For each endpoint: method, path, params, request body, response shape,
error codes, and a copy-paste example. Match the existing docs format.

When it triggers: when you add or change a route, or ask Claude to document an API.

8. Database migration safety

Guards schema changes against the destructive defaults — no unguarded column drops, expand-then-contract for renames, and a tested rollback for every forward migration.

---
name: db-migration-safety
description: Reviews and writes database migrations to avoid destructive
  or locking changes. Use when creating, editing, or reviewing a schema
  migration.
---

# Database Migration Safety
Prefer additive changes. Use expand-then-contract for renames. Avoid
table-locking operations on large tables. Every migration ships a rollback.

When it triggers: when you create, edit, or review a schema migration.

9. React component scaffold

Stamps out new components to your house style — typed props, the right file layout, colocated tests, and the accessibility basics already wired in.

---
name: react-component-scaffold
description: Scaffolds new React components with typed props, colocated
  tests, and accessible defaults. Use when the user asks to create a new
  component.
---

# React Component Scaffold
Generate the component, its types, and a colocated test. Forward refs,
type all props, and include keyboard and focus handling by default.

When it triggers: when you ask Claude to create a new React component.

10. Conventional PR

Turns a branch into a clean pull request — a structured summary, a test plan, and a title that matches your commit convention — from the actual diff, not a guess.

---
name: conventional-pr
description: Drafts pull request titles and descriptions with a summary
  and test plan from the branch diff. Use when the user is opening a pull
  request or asks to write a PR description.
---

# Conventional PR
Read the full diff (not just the last commit). Write a Conventional-style
title, a what/why summary, and a checkable test plan.

When it triggers: when you open a pull request or ask Claude to write a PR description.

The ten skills at a glance

Here is the full set in one place — what each skill enforces and the moment it kicks in. The first six are installable templates; the last four are patterns you adapt to your own stack.

How to adapt these to your own repo

Copy any of the blocks above into .claude/skills/<name>/SKILL.md and Claude Code will pick it up on the next session. The two things to get right are the same two required fields. Make the name a clear, hyphenated noun phrase, and write the descriptionin the third person so it reads as “does X; use when Y.” That second clause is what makes auto-triggering reliable — a vague description means Claude either over-fires the skill or never reaches for it.

Resist the urge to dump everything into the body. If a skill needs a long checklist, a config sample, or a script, put those in separate files in the skill directory and reference them — progressive disclosure loads them only when needed, and scripts run via bash without spending context tokens. A good rule of thumb is to keep the body itself a short, opinionated procedure under 500 lines and let bundled resources carry the bulk. Names follow a convention too: lowercase, hyphenated, and gerund or noun-phrase where it reads naturally, with no use of “anthropic” or “claude” in the name itself.

Skills are not the only way Claude Code reads your conventions, though. Always-on facts that belong in every session — your stack, your directory layout, the commands you run — live better in CLAUDE.md, while procedures that only matter sometimes belong in skills. The trade-off between those two, and how every other tool handles the same job, is broken down in our comparison of AI coding rules files.

The catch: one skill, every project, every tool

A skill written in .claude/skills/ works in exactly one place: that repo, in Claude Code. Drop the same convention into a second project and you copy the directory again. Decide your team should also run Cursor or Copilot, and now the same standard has to be rewritten as a .cursor/rules/*.mdc file and a .github/copilot-instructions.md— none of those formats read each other. Fix a rule in one and the others silently drift.

That is the gap Skillwright closes. You keep one canonical libraryof your skills and rules, author each one once, and compile it to every target format — SKILL.md for Claude Code, .cursor/rulesfor Cursor, Windsurf rules, and Copilot instructions — then deploy to every project from a single source. The six free templatesbehind examples 1–6 are built to seed exactly that library, and you add your own (like the four above) alongside them.

If you run more than one AI coding tool, start with how to manage AI coding rules across tools — the skills you write today should outlast whichever editor you happen to be using next year.

Frequently asked questions