Back to Learn
Skills
9 min read

How to Use Claude Skills: A Complete Guide

clauderules.net

What Are Claude Skills?

Claude Skills are reusable slash commands that you define as Markdown files in .claude/commands/. Each skill encodes a multi-step workflow, expert prompt, or repeatable task that you can invoke with a single /skill-name command.

Think of skills as macros for Claude. Instead of typing the same detailed instructions every session — "review this PR for security issues, performance regressions, and missing tests" — you write it once as a skill and invoke it in seconds.

Skills are especially powerful because they live in your repository. Your whole team gets access to the same skills automatically, with no setup required beyond cloning the repo.

Discovering Built-in Skills

Claude Code ships with a set of built-in skills. To browse them, type / in Claude Code and press Tab (or just type /help to list available commands). You'll see the full list of built-in skills plus any custom skills defined in your project.

The community has also created hundreds of skills for common workflows. You can browse them at clauderules.net/agents — skills for code review, commit message generation, test writing, documentation generation, and more.

Type / followed by any letters to fuzzy-search available skills. Claude Code will autocomplete as you type.

Running a Skill

Running a skill is as simple as typing its name with a leading slash. Some skills accept arguments that let you customize their behavior:

bash
# Run a skill with no arguments
/review-pr

# Run a skill with arguments
/commit -m "fix authentication bug"

# Run a skill with a URL or file path as argument
/review-pr https://github.com/myorg/myrepo/pull/123

# Run the built-in compact skill to compress context
/compact

When you invoke a skill, Claude reads the skill's Markdown file, substitutes any $ARGUMENTS placeholders with what you typed after the skill name, and then executes the resulting prompt.

Creating Your Own Skills

Creating a skill is as simple as creating a Markdown file. Skills live in the .claude/commands/ directory, and the filename (without extension) becomes the slash command name.

bash
# Create the commands directory if it doesn't exist
mkdir -p .claude/commands

# Create a skill file
touch .claude/commands/review-pr.md

The contents of the file become the prompt. Use $ARGUMENTS as a placeholder for whatever the user types after the skill name:

.claude/commands/review-pr.md
Review the pull request at $ARGUMENTS. Check for:

- **Security vulnerabilities**: SQL injection, XSS, authentication bypasses, insecure dependencies
- **Performance issues**: N+1 queries, missing indexes, large bundle additions, unoptimized loops
- **Missing tests**: new code paths without coverage, edge cases not handled
- **Code style consistency**: naming conventions, patterns that deviate from the project's CLAUDE.md

Provide a structured report organized by severity: Critical, Major, Minor, and Suggestions.
For each issue, cite the specific file and line number and explain the recommended fix.

Now invoke it with: /review-pr https://github.com/org/repo/pull/42

Project vs User Skills

Skills can be scoped to a project or to your personal environment:

Project Skills — .claude/commands/

Committed to git. Available to everyone on the team who clones the repository. Best for team workflows, project-specific conventions, and shared automation.

Personal Skills — ~/.claude/commands/

Stored in your home directory. Available in every project on your machine. Best for personal preferences, communication style overrides, and tools you always use.

When both a project and personal skill share the same name, the project skill takes precedence. This lets teams override personal defaults where consistency matters.

Practical Skill Examples

Here are some high-value skills that teams commonly create:

.claude/commands/write-tests.md
Write comprehensive tests for $ARGUMENTS.

Requirements:
- Cover the happy path, edge cases, and error conditions
- Test null/undefined inputs, empty arrays, and boundary values
- Use the project's existing test framework (check package.json)
- Follow the naming convention: describe('functionName', () => { it('should...') })
- Do not mock internal modules — only mock external API calls and I/O

Output the test file with a suggested file path at the top.
.claude/commands/explain.md
Explain $ARGUMENTS to a developer who is new to this codebase.

Include:
1. What the code does at a high level
2. Why it exists (the problem it solves)
3. How it fits into the overall architecture
4. Any non-obvious decisions or gotchas
5. What to watch out for when modifying it

Keep the explanation concise but complete — no padding.

Best Practices for Skills

One task per skill. Skills are most reliable when they do one thing. A "review-pr" skill and a "write-tests" skill are better than a single "do-everything" skill.

Descriptive names. The skill name is the command. Choose names that describe the action: generate-changelog, audit-security, document-api.

Include examples in the prompt. Show Claude the format you want the output in. "Format the output as a Markdown table with columns: File, Issue, Severity, Fix" produces much more consistent results than "format it nicely."

Version control project skills. Your .claude/commands/ directory should be committed to git. This ensures the whole team benefits from improvements and that skills evolve with the codebase.

Browse community-contributed skills at clauderules.net/agents. You can use them as-is or adapt them for your project's specific conventions.

Get the Claude Code Starter Pack

Top CLAUDE.md rules for Next.js, TypeScript, Python, Go, and React — delivered free to your inbox.