Claude Code Skills: Build Custom Slash Commands That Actually Work (2026 Guide)

mkdir -p ~/.claude/skills/pr-describe

---
name: pr-describe
description: Generate a pull request description from staged or recent changes. Use when the user asks to write a PR description, prepare a PR, or describe their changes.
---
Generate a pull request description by analyzing the current changes:
1. Run `git diff --staged` (or `git diff HEAD~1` if nothing is staged)
2. Identify the type of change: feature, bugfix, refactor, docs, or chore
3. Write the PR description in this format:
## What
One sentence summary of what changed.
## Why
Brief context on why this change was needed.
## Changes
- Bullet list of specific changes, grouped by file or area
- Include new dependencies, config changes, or migration steps
## Testing
How to verify this works. Include specific commands if applicable.
## Notes
Anything reviewers should pay attention to.

/pr-describe

---
name: my-skill          # Required. Becomes the /slash-command name
description: |          # Required. Tells Claude when to auto-invoke
  What this skill does and when to use it.
  Be specific — vague descriptions lead to false triggers.
invocation: user        # Optional. "user" = only via slash command
                        #           "agent" = only auto-invoked (default: both)
subagent: true          # Optional. Run in isolated context window
---

---
name: review
description: Review code changes against team standards. Use when the user asks for a code review, CR, or to check their changes.
---
Review the staged changes (or recent commits if nothing staged) against these standards:
**Must check:**
- Error handling: Are errors caught, logged, and handled gracefully?
- Input validation: Is user input validated before use?
- Security: SQL injection, XSS, auth checks, secret exposure
- Performance: N+1 queries, unnecessary loops, missing indexes
- Types: Are types correct and specific (no unnecessary `any`)?
**Style checks:**
- Functions under 50 lines
- Descriptive variable names (no single-letter except loop counters)
- Comments explain "why", not "what"
**Output format:**
For each issue found:
- 🔴 **Critical** — Must fix before merge
- 🟡 **Warning** — Should fix, not a blocker
- 🟢 **Suggestion** — Nice to have
End with a summary: total issues by severity, overall assessment (approve / request changes), and one thing done well.

---
name: gen-tests
description: Generate tests for a file or function. Use when the user asks to write tests, add test coverage, or test a specific function.
---
Generate tests for the specified file or function:
1. Read the source file and identify all exported functions/methods
2. For each function, create tests covering:
   - Happy path (expected inputs → expected outputs)
   - Edge cases (empty inputs, null, undefined, boundary values)
   - Error cases (invalid inputs, network failures, timeouts)
3. Use the project's existing test framework (check package.json, pytest.ini, etc.)
4. Follow existing test patterns in the codebase (check the test directory)
5. Include setup/teardown if the function has side effects
6. Name tests descriptively: "should [expected behavior] when [condition]"
Run the tests after writing them. Fix any failures.

---
name: explain
description: Explain how a codebase, file, or function works with diagrams and analogies. Use when the user asks how something works, wants an overview, or is onboarding to a project.
---
When explaining code:
1. **Start with the big picture**: What does this code accomplish in one sentence?
2. **Draw a diagram**: Use ASCII art to show data flow, component relationships, or the call chain
3. **Walk through it**: Explain step by step, referencing specific line numbers
4. **Highlight the clever parts**: What design decisions were made and why?
5. **Flag the gotchas**: What would confuse someone reading this for the first time?
Use analogies from everyday life. "This middleware is like a bouncer checking IDs before letting requests into the club."
Adjust depth to scope: a single function gets a focused explanation, a full codebase gets an architecture overview with links to key files.

---
name: audit-deps
description: Audit project dependencies for security issues, outdated packages, and unused imports. Use when the user asks to check dependencies, audit packages, or clean up imports.
---
Audit the project's dependencies:
1. **Security**: Run the package manager's audit command (`npm audit`, `pip audit`, `cargo audit`, etc.)
2. **Outdated**: Check for packages more than one major version behind
3. **Unused**: Scan source files for imports and cross-reference with installed packages. Flag packages in the dependency file that are never imported.
4. **Duplicates**: Check for multiple versions of the same package in the lock file
5. **License**: Flag any packages with non-permissive licenses (GPL, AGPL) if the project uses MIT/Apache
Output a summary table:
- 🔴 Security vulnerabilities (with severity)
- 🟡 Outdated packages (current → latest)
- ⚪ Unused packages (safe to remove)
- 📋 License concerns
End with recommended actions, prioritized by risk.

---
name: migrate
description: Plan and execute a code migration. Use when the user asks to migrate, upgrade, convert, or transition from one technology to another.
---
When asked to migrate code:
1. **Assess scope**: How many files are affected? Run a search for imports/usage of the source technology.
2. **Create a plan**: Break the migration into phases that can be merged independently. Each phase should leave the codebase in a working state.
3. **Identify risks**: What could break? Are there runtime behaviors that differ between source and target?
4. **Write a checklist**: Numbered steps with estimated file counts per step
5. **Ask before executing**: Present the plan and wait for approval before making changes
During execution:
- Migrate one file/module at a time
- Run tests after each change
- Keep a running log of decisions and edge cases encountered
- If a pattern repeats more than 3 times, create a helper function
After completion, summarize what changed, what was skipped, and any manual steps remaining.

---
name: gen-docs
description: Generate or update documentation for code. Use when the user asks to document, add docs, write a README, or update API docs.
---
Generate documentation based on what is requested:
**For a README:**
- Project name and one-line description
- Prerequisites and installation steps (test that they work)
- Quick start example (working code)
- Configuration options (from env vars, config files)
- Available scripts/commands
- Contributing guidelines (if CONTRIBUTING.md does not exist)
**For API documentation:**
- Every endpoint: method, path, description
- Request parameters with types and examples
- Response format with example JSON
- Error codes and their meanings
- Authentication requirements
**For inline documentation:**
- JSDoc/docstrings for all exported functions
- Parameter descriptions with types
- Return value description
- Usage example for complex functions
- Note any side effects
Always read existing docs first. Update rather than overwrite. Match the existing documentation style.

~/.claude/skills/pr-describe/
├── SKILL.md
├── templates/
│   ├── feature-pr.md
│   ├── bugfix-pr.md
│   └── breaking-change-pr.md
└── examples/
    └── good-pr-example.md

Use the appropriate template from the `templates/` directory based on the change type.
Refer to `examples/good-pr-example.md` for the expected quality level.

---
name: deploy
description: Deploy the application to production
invocation: user  # Only runs when you explicitly type /deploy
---

---
name: deep-review
description: Thorough code review with full codebase context
subagent: true
---

---
name: project-standards
description: Team coding standards and conventions
context: true
---
## Our Standards
- Use TypeScript strict mode
- All API routes must have input validation with Zod
- Database queries go through the repository pattern
- Error responses follow RFC 7807 (Problem Details)

~/.claude/skills/
├── review/          # Code review
├── gen-tests/       # Test generation
├── gen-docs/        # Documentation
├── pr-describe/     # PR descriptions
├── explain/         # Code explanations
├── audit-deps/      # Dependency audit
├── migrate/         # Migration planner
└── deploy/          # Deployment (user-only)