Claude Code Custom Slash Commands: 15 Copy-Paste Examples for Real Work

A custom slash command is the simplest extension Claude Code has: a markdown file in .claude/commands/ whose filename becomes the command and whose body becomes the prompt. No registration, no build step — save the file, type / and it's there. What most people are missing isn't syntax, it's a starting library. Here are fifteen commands you can paste today, organized by the work they do.

The 60-second syntax primer

---
description: Find and fix a GitHub issue by number
argument-hint: <issue number>
---

Fix GitHub issue #$ARGUMENTS.
1. Read the issue with `gh issue view $ARGUMENTS`
2. Locate the relevant code and reproduce the problem
3. Implement a fix, add a regression test, run the suite
4. Commit with message "fix: <summary> (#$ARGUMENTS)"

$ARGUMENTS captures everything typed after the command (/fix-issue 421);$1, $2 grab positional arguments individually. Lines starting with ! run shell commands and inject their output into the prompt, and @path/to/file pulls a file in as context. The frontmatter is optional but the description shows up in the command menu, so write it.

Code quality (1–4)

1. /review — "Review the current diff (!git diff HEAD) for correctness bugs first, style second. For each finding: file, line, what breaks, and a concrete fix. Rank by severity. If nothing is wrong, say so — do not invent findings."

2. /refactor — "Refactor $ARGUMENTS without changing behavior. Tests must stay green — run them before and after. List each change and why it improves the code. If a change would alter behavior, stop and report instead."

3. /test — "Write tests for $ARGUMENTS following this repo's existing test patterns. Cover the happy path, edge cases, and one failure mode. Run them and fix failures before finishing."

4. /explain — "Explain how $ARGUMENTS works: entry points, data flow, key invariants, and anything surprising. Audience: a developer new to this codebase. No code changes."

Git and shipping (5–8)

5. /commit — "Stage and commit the current changes. Group unrelated changes into separate commits. Messages follow conventional commits; the subject line explains why, not just what."

6. /pr — "Create a pull request for this branch: summarize the diff against main, list notable decisions and trade-offs, add a test plan, and open it with gh pr create."

7. /changelog — "Update CHANGELOG.md from commits since the last release tag (!git log $(git describe --tags --abbrev=0)..HEAD --oneline). Group by Added/Changed/Fixed. Write for users, not committers."

8. /release-check — "Pre-release audit: run tests, typecheck, and build; check for TODOs and console.logs in the diff; verify version bumps are consistent. Output a go/no-go verdict with a checklist."

Debugging and maintenance (9–12)

9. /debug — "Debug this: $ARGUMENTS. Reproduce first. State your hypothesis before changing anything, add instrumentation to confirm it, then fix the root cause — not the symptom — and prove the fix with a test."

10. /deps — "Audit dependencies: flag outdated packages, known vulnerabilities (!npm audit), and anything unmaintained. Recommend upgrades in order of risk, and note breaking changes from changelogs."

11. /todo-sweep — "Find every TODO/FIXME/HACK in src/. For each: still relevant? If trivially fixable, fix it. Otherwise output a prioritized list with file and line references."

12. /dead-code — "Find unused exports, unreachable branches, and orphaned files. Verify each candidate is truly unused (check dynamic imports and string references) before listing it for deletion."

Documentation and beyond (13–15)

13. /docs — "Update documentation for $ARGUMENTS: check README and docs/ against the current behavior of the code, fix drift, and flag anything undocumented that a new user would need."

14. /onboard — "Give me a tour of this codebase: purpose, stack, the five most important files, how data flows through a typical request, and what I should read first. Then suggest three good first tasks."

15. /standup — "Summarize what changed in this repo in the last 24 hours (!git log --since=yesterday --oneline): what shipped, what's in progress, anything blocked. Three bullets, written for a standup."

Patterns that separate good commands from noise

• Encode the checklist, not just the ask. "Review my code" is a wish. Numbered steps with an output format is a workflow that runs the same way every time — that consistency is the entire value of a command.
• Inject fresh context with !. A command that pulls the actual diff, log, or audit output grounds Claude in reality instead of memory.
• Define "done". End with the verification step — run the tests, show the output, produce the verdict. Commands without a finish line produce plausible-looking half-work.
• Commit them to the repo. Project-level commands are shared team workflows in git. Your best reviewer's checklist, everyone's /review.

FAQ

Keep reading