Claude Code Skills in Practice: 10 Skills That Actually Help and How to Create Your Own

What a skill is, in plain terms

A skill is not a plugin, a model or a separate program. It is instructions, stored as a folder, that Claude Code reads when it needs them. The folder contains a SKILL.md file with a name, a short description of when to use the skill, and the steps to follow. Claude Code loads only the name and description at first, to save context, and loads the full instructions when you ask for a matching task.

That design is the point. A long, generic prompt in every session costs context and drifts over time. A skill is a reusable, versioned workflow: the same checklist, the same output format, the same quality bar, every time. It works best for tasks with clear steps and a checkable result, and worst for vague tasks where the right answer changes every time.

Skills can live in a personal folder, a project folder, or a shared collection. Project skills travel with the repository, so a team shares the same workflow. Personal skills follow you across projects. Start with project skills for team workflows, and personal skills for habits only you use.

Ten skill types that actually help

The list below is organised by task type, not by product name. Each entry is one skill idea with one concrete use, so you can copy the pattern and adapt it to your project. The value is not in collecting skills, but in using one skill for one repeated task until it is reliable.

1. Code review

Use: review a change against a checklist before it is merged. Example: ask for a review of a pull request, and the skill checks readability, error handling, tests and security-sensitive inputs, then lists findings by severity with file and line references.

2. Test-driven development

Use: turn a requirement into a failing test first, then the smallest change that passes it. Example: describe a function, and the skill writes the test, runs it, confirms it fails, implements the function, and runs the test again.

3. Commit messages

Use: write consistent, useful commit messages from a diff. Example: after staging changes, the skill summarises what changed and why in one short subject line plus a brief body, instead of a vague message.

4. Documentation

Use: keep docs in step with code. Example: after changing a function, the skill updates its docstring and the relevant guide section, and flags any example that no longer matches the code.

5. Debugging

Use: follow a repeatable fault-finding sequence. Example: given an error message, the skill reproduces it, narrows the failing input, checks recent changes, and reports the smallest reproduction before proposing a fix.

6. Refactoring

Use: restructure code without changing behaviour. Example: the skill extracts a long function into smaller ones, runs the existing tests after each step, and stops if a test fails, so behaviour stays the same.

7. Security review

Use: scan a change for common risky patterns. Example: the skill checks user input handling, authentication checks and secrets in code, and lists anything that needs a human decision instead of silently fixing it.

8. Explaining a codebase

Use: onboard faster with a guided tour. Example: ask how authentication works, and the skill traces the flow through the relevant files and explains it in order, with links to the code it mentions.

9. Release notes

Use: turn merged changes into readable release notes. Example: given a range of commits, the skill groups them by user-visible change, bug fix and internal work, and drafts notes a non-developer can read.

10. API client generation

Use: build a small client from an API description. Example: given an endpoint specification, the skill generates typed request functions, error handling and one example call per endpoint, then checks the examples against the specification.

How to create your own skill, step by step

First, pick one repeated task and write down its steps on paper, in order, including the checks you already do by hand. If you cannot list the steps, the task is not ready to become a skill yet. A skill that says "do it well" teaches nothing; a skill that says "check this, then this, then this" does.

Second, create a folder for the skill and a SKILL.md file inside it. Give the skill a short name, then a description that says when to use it, in the terms you would actually use when asking. The description is how Claude Code decides to load the skill, so write it as a trigger: "Use this when reviewing a pull request", not "A helpful coding assistant".

my-skill/
  SKILL.md

# Inside SKILL.md:
# Name: code-review
# Description: Use when reviewing a pull request or a code change.
# Steps: 1. Read the diff. 2. Check readability and naming.
# 3. Check error handling and tests. 4. List findings by severity.

Third, write the body as steps, not prose. Each step should be one action, with the expected output. Add the checks that matter most, and the mistakes to avoid, because those are the parts a generic prompt usually misses. Keep it as short as it can be while still working: a skill that is too long will be skimmed, by a human or by the model.

Fourth, test it on a real task, not a toy example. Run it, read the result, and fix what it got wrong: a missing step, a vague instruction, a check that came too late. Iterate twice on real work before calling the skill done, and keep the skill in version control so improvements are shared and reversible.

Finally, activate it by placing the folder where Claude Code looks for skills, either in your project or in your personal skills folder, and invoke it by describing the matching task. If it does not trigger, the description is usually the problem: make the trigger wording match how you actually ask for the task.

Rules that keep skills useful

One skill, one job. A skill that tries to review code, write tests and deploy will do all three badly. Split it, and let each skill do its job well. Keep skills short and specific, and delete a skill that is no longer used: stale instructions are worse than none, because they are followed with confidence.

Never put secrets, passwords or API keys in a skill file. Skills are instructions, and they may be shared, copied or read by others. Reference a secret by name and let the environment provide it, the same way you would in code. And do not write a skill that hides a decision a human should make: a security finding, a destructive command or a data migration should be reported for approval, not executed silently.

Measure a skill by its output, not by its length. If a skill saves you from repeating the same explanation and produces a result you would accept without rework, it works. If you rewrite its output every time, the skill needs a clearer step, a better example, or a narrower job.

Choosing your first skill

Do not start with ten skills. Start with the task you explain most often, and build exactly one skill for it. The test is simple: if you have explained the same workflow three times, it is worth a skill. If you have done a task once, it is not, because you do not yet know which steps matter and which ones you skip every time.

A good first skill is also a safe one. Code review, commit messages and documentation are good first choices, because their output is easy to check and easy to undo. A skill that runs destructive commands, migrates data or publishes something is a bad first skill, even if you use it often, because its mistakes are expensive. Earn trust with safe skills first, then expand to riskier ones with approval steps built in.

When the first skill works, the second one becomes obvious: it is the task you now explain while the first skill runs. That is how a useful library grows, one proven skill at a time, instead of a folder of untested instructions that nobody trusts.

A complete example: a code review skill

Below is a complete, small skill file for reviewing a code change. It shows the pattern every skill should follow: a name, a trigger description, ordered steps, and explicit checks. Adapt the checklist to your project, and keep the file short enough that you would actually read it before approving a review.

# code-review
# Description: Use when reviewing a pull request or a code change.
#
# Steps:
# 1. Read the full diff, not just the changed lines, so context is clear.
# 2. Check naming and readability: could a new team member follow this?
# 3. Check error handling: what happens with empty, invalid or missing input?
# 4. Check tests: is the new behaviour covered, and do existing tests pass?
# 5. Check for secrets, credentials or debug output left in the code.
# 6. List findings by severity (must fix, should fix, suggestion),
#    each with the file and line it refers to.
# 7. Do not merge, push or modify the code: report findings for approval.

Notice what the skill does not do. It does not claim the code is correct, it does not fix anything on its own, and it does not hide findings behind praise. A review skill that only says the code looks good is not a review skill at all. The severity list is the output that matters, because it turns a vague impression into decisions a human can act on.