50 Best Claude Code Skills in 2026: Copy-Paste Templates
The highest-ROI Claude Code skills are: commit-message, pr-description, code-review, write-tests, write-migration, api-endpoint, security-audit, and changelog-entry. These 8 skills cover the most frequent developer tasks and save 15-30 minutes per task on average.
Skills compound over time. The first skill you write saves hours over the next month. The tenth skill you write works better because you've learned what makes descriptions effective, instructions specific, and examples useful. These 50 skills represent the collective experience of teams that have been using Claude Code since its launch.
Engineering skills (1-15) cover the daily coding workflow: writing tests, API endpoints, database migrations, code reviews, and refactoring. These are the highest-frequency tasks and pay back the 30 minutes of skill-writing time within a few uses. Start here.
Git and PR skills (16-22) encode your team's conventions for commit messages, PR descriptions, changelogs, and release notes. These are especially valuable for teams with style guides — instead of explaining your commit message format in every session, encode it once in a skill and Claude follows it perfectly every time.
Documentation skills (23-30) handle inline documentation, README generation, API docs, and architecture decision records. Claude writes documentation well when given good examples — the skill is where those examples live.
Testing and quality skills (31-40) go beyond 'write a test' to encode your team's specific testing patterns: mocking strategies, test data builders, integration test setup, E2E scenarios. These are the skills that turn Claude from a test writer into a test architect.
DevOps and deployment skills (41-50) handle CI configuration, Docker setup, infrastructure-as-code, monitoring queries, and runbook generation. These are high-value because they involve institutional knowledge that's hard to encode in documentation but easy to encode in a skill that Claude reads.
Examples
# Skill: Write Commit Message
## Description
Write a conventional commit message for staged changes.
Use when asked to commit, write a commit message, or summarize changes.
## Instructions
1. Run `git diff --staged` to see what's staged
2. Identify the primary change type: feat, fix, docs, style, refactor, test, chore, perf
3. Identify the scope (component, module, or file affected)
4. Write the commit message following the format below
## Format
```
<type>(<scope>): <short summary in present tense>
<optional body — explain WHY, not WHAT>
<optional footer — BREAKING CHANGE: or Closes #issue>
```
## Examples
```
feat(auth): add OAuth2 login with GitHub
Users can now authenticate via GitHub OAuth. Requires GITHUB_CLIENT_ID
and GITHUB_CLIENT_SECRET environment variables.
Closes #142
```
```
fix(api): handle null user_id in payment webhook
Webhook handler crashed when payment gateway sent events without user_id.
Now returns 200 with a warning log instead of 500.
```
## Rules
- Summary line ≤72 characters
- Use present tense: 'add' not 'added'
- Never mention file names in the summary — use the scope instead
- Breaking changes MUST have a BREAKING CHANGE footer# Skill: Write Unit Tests
## Description
Write Vitest unit tests for TypeScript functions and React components.
Use when asked to add tests, increase coverage, or write tests for new code.
## Context
- Test framework: Vitest
- React testing: @testing-library/react
- Mocking: vi.mock(), vi.fn(), vi.spyOn()
- Test files: alongside source files as `*.test.ts` or `*.test.tsx`
## Instructions
1. Read the source file to understand exports, types, and dependencies
2. Identify all exported functions/components and their edge cases
3. Write tests covering: happy path, edge cases, error cases
4. Mock external dependencies (database, API calls, file system)
5. Run `pnpm test [filename]` to verify tests pass
## Structure
```typescript
import { describe, it, expect, vi, beforeEach } from 'vitest'
import { functionUnderTest } from './module'
describe('functionUnderTest', () => {
beforeEach(() => {
vi.clearAllMocks()
})
it('returns expected result for valid input', () => {
expect(functionUnderTest(validInput)).toEqual(expectedOutput)
})
it('throws on invalid input', () => {
expect(() => functionUnderTest(null)).toThrow('Expected ...')
})
})
```
## Rules
- One describe block per exported entity
- Test names describe the behavior, not the implementation
- NEVER test implementation details — test observable behavior
- Mock at the module boundary, not inside the module## Engineering (1-15)
1. write-tests — unit/integration test generation
2. api-endpoint — scaffold new REST/tRPC endpoint
3. write-migration — database schema migration
4. code-review — structured review checklist
5. refactor-function — safe refactoring with test verification
6. add-types — add TypeScript types to JS code
7. error-handling — add proper error handling + logging
8. performance-audit — identify and fix performance issues
9. security-audit — OWASP-based security checklist
10. accessibility-audit — WCAG 2.1 accessibility review
11. component-scaffold — new React component with tests
12. api-client — generate typed API client from schema
13. seed-data — generate realistic seed/fixture data
14. feature-flag — add feature flag to existing code
15. deprecation-path — migrate deprecated API usage
## Git and PRs (16-22)
16. commit-message — conventional commits format
17. pr-description — structured PR description template
18. changelog-entry — Keep a Changelog format entry
19. release-notes — user-facing release announcement
20. branch-name — kebab-case branch name from task description
21. git-blame-summary — summarize who changed what and why
22. merge-conflict-resolve — explain and resolve merge conflicts
## Documentation (23-30)
23. jsdoc — add JSDoc to exported functions
24. readme-section — add a new README section
25. api-docs — OpenAPI/Swagger spec from route handlers
26. adr — architecture decision record template
27. runbook — operational runbook for a service
28. onboarding-doc — new developer onboarding guide
29. code-comment — explain complex logic with inline comments
30. storybook-story — write Storybook story for component
## Testing (31-40)
31. e2e-test — Playwright E2E test scenario
32. test-data-builder — builder pattern for test fixtures
33. mock-server — MSW mock server handler
34. load-test — k6 load test script
35. snapshot-test — component snapshot test
36. contract-test — Pact consumer contract test
37. test-refactor — improve existing brittle tests
38. coverage-gap — find and fill test coverage gaps
39. regression-test — reproduce and test a bug
40. property-test — fast-check property-based test
## DevOps (41-50)
41. dockerfile — production-optimized Dockerfile
42. github-action — new GitHub Actions workflow
43. k8s-manifest — Kubernetes deployment manifest
44. terraform-module — Terraform resource module
45. monitoring-query — Grafana/Prometheus query
46. alert-rule — alerting rule with runbook link
47. env-vars — environment variable documentation
48. cicd-debug — diagnose failing CI pipeline
49. dependency-audit — outdated/vulnerable dependency report
50. cost-estimate — cloud resource cost estimationTips
- →Start with commit-message, write-tests, and code-review — these three skills cover the tasks most developers do multiple times per day.
- →Share your best skills across the team by committing `.claude/skills/` to git — new team members get working skills immediately on clone.
- →Build skills iteratively: write a first draft, use it on 3 real tasks, note where it produces suboptimal output, and refine. Don't try to write the perfect skill on the first attempt.
- →Name skills as verb-noun pairs (write-tests, review-code, add-types) — the naming convention makes them easy to invoke and remember.
- →For skills that involve running commands, add a 'verify' step at the end (run tests, typecheck, lint) so Claude confirms the output is correct before declaring the task done.
- →When a skill is used for a complex task and produces excellent output, save that output as an example in the skill file for future reference.
FAQ
How many skills should I start with?+
Start with 3-5 skills for your most frequent tasks. More than 10 skills in your initial setup means you've spent time writing skills that you won't use often enough to see a return. Build the library gradually as you identify recurring tasks.
Should I write skills for one-off tasks or only recurring ones?+
Only recurring tasks — a skill you use once doesn't pay back the time to write it. Good signal that a skill is worth writing: you've done the same type of task 3+ times and each time you've explained the same constraints to Claude.
Can I find community-contributed skills somewhere?+
The Claude Code community shares skills on GitHub (search 'claude-code skills') and in the Anthropic developer Discord. Many are framework-specific (Next.js, Django, Rails, Go). Check community sources before writing from scratch — you may find a skill that's 80% of what you need.