Claude Code Slash Commands Examples and Templates

---
description: Explain how a file, function, or symbol works
allowed-tools: Read, Grep, Glob
---
Explain the following code or concept: $ARGUMENTS

If $ARGUMENTS names a file, function, or symbol, find it first with Grep/Glob, then read it.

Walk through it in this order:
1. One-sentence summary of what it does and why it exists.
2. The inputs it takes and the outputs/side effects it produces.
3. A step-by-step trace of the main path, in plain language.
4. Edge cases, error handling, and anything surprising or easy to misuse.
5. How it connects to the rest of the codebase (callers and dependencies).

Keep it concrete. Quote the specific lines you are describing. Do not restate the code line-by-line, explain the intent.

Grounding the explanation in a Grep/Glob lookup stops Claude from guessing about code it has not actually read.

---
description: Refactor code for clarity without changing behavior
allowed-tools: Read, Edit, Grep, Glob
---
Refactor: $ARGUMENTS

Rules:
- Preserve external behavior exactly. This is a refactor, not a rewrite.
- Read the target and its callers before editing so you do not break the contract.
- Make small, safe, reviewable changes: rename for clarity, extract functions, remove dead code, reduce nesting, kill duplication.
- Match the file's existing style and conventions.
- Do NOT change public signatures, add dependencies, or introduce new abstractions unless they clearly reduce complexity.

After editing, list each change as a one-line bullet and explain in one sentence why it is behavior-preserving. If tests exist for this code, note which ones cover it.

The explicit behavior-preserving constraint plus a callers check is what separates a safe refactor from an accidental rewrite.

---
description: Find and fix performance problems in a file or function
allowed-tools: Read, Edit, Grep, Glob, Bash
---
Optimize for performance: $ARGUMENTS

Do NOT micro-optimize blindly. Work in this order:
1. Read the code and identify the actual hot path and the dominant cost (algorithmic complexity, N+1 queries, repeated work, unnecessary allocations, sync I/O in a loop).
2. State the single biggest bottleneck and the Big-O or cost before change.
3. Propose the change and the expected improvement.
4. Apply it, keeping behavior and output identical.
5. If a benchmark or test exists, run it with Bash to confirm; otherwise describe how to measure.

Prefer the algorithmic win over clever tricks. Never trade correctness for speed.

Forcing Claude to name the dominant cost before touching anything prevents pointless micro-optimizations that do not move the needle.

---
description: Code review of the current git diff
allowed-tools: Bash(git diff:*), Bash(git status:*), Read
---
Review the current changes.

Run git diff HEAD (and git status) to see what changed. If $ARGUMENTS is provided, scope the review to those files or that concern.

Review like a senior engineer who has to maintain this. Group findings by severity:
- BLOCKER: bugs, security holes, data loss, broken contracts.
- SHOULD-FIX: correctness risks, missing error handling, race conditions, unclear edge cases.
- NIT: naming, style, small clarity wins.

For each finding give: file:line, what is wrong, and the concrete fix. Quote the offending line. Call out anything missing (tests, validation, docs), not just what is present. If the diff is clean, say so plainly instead of inventing problems.

Reviewing the real git diff HEAD rather than the whole repo keeps the feedback focused on exactly what the developer is about to ship.

---
description: Generate tests for a file or function
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
---
Write tests for: $ARGUMENTS

Steps:
1. Read the target code and find the existing test suite (framework, folder layout, naming, assertion style) with Grep/Glob. Match it exactly, do not introduce a new framework.
2. Cover: the happy path, boundary values, empty/null inputs, and each error branch. One clear assertion focus per test.
3. Give tests descriptive names that state the expected behavior.
4. Avoid brittle tests, do not assert on incidental formatting or internal implementation details.
5. Run the new tests with Bash and iterate until they pass. If a test reveals a real bug, stop and report it instead of writing the test to match the bug.

Report which behaviors are covered and which are still untested.

Detecting the existing framework first and refusing to encode bugs makes the generated tests fit the project and actually catch regressions.

---
description: Reproduce a bug, find root cause, then fix it
allowed-tools: Read, Edit, Grep, Glob, Bash
---
Debug this: $ARGUMENTS

Follow reproduce-then-fix. Do NOT patch symptoms.
1. REPRODUCE: write or run the smallest thing that triggers the bug and confirm you see the failure. If you cannot reproduce it, say so and ask for the exact steps/inputs.
2. ISOLATE: trace from the symptom back to the source. Read the relevant code and data flow. Form one hypothesis and test it with a print/log/assert or a quick Bash run before believing it.
3. ROOT CAUSE: state in one sentence why it actually breaks.
4. FIX: make the minimal change that addresses the root cause.
5. VERIFY: re-run the reproduction and confirm it now passes, plus check you did not break nearby cases.

Report the root cause, the fix, and the evidence it works.

Requiring a confirmed reproduction before any edit stops the classic failure mode of confidently fixing the wrong thing.

---
description: Diagnose and fix a failing CI or test run
allowed-tools: Read, Edit, Grep, Glob, Bash
---
Fix the failing build/CI: $ARGUMENTS

1. Get the failure. If a log or command is in $ARGUMENTS use it; otherwise reproduce locally by running the test/lint/build command (check package.json scripts, Makefile, or the CI config).
2. Read the actual error, find the first real failure, not the noisy cascade after it.
3. Locate the offending code or config, understand why it fails, and apply the minimal fix. Fix the cause (a real bug, a bad import, a version mismatch), not the test, unless the test itself is genuinely wrong.
4. Re-run the same command with Bash and confirm it now passes green.

Report: the root failure, the fix, and the passing run output. If the fix needs a dependency or env change, state it explicitly.

Anchoring on the first real failure and re-running the exact command turns a wall of red CI output into one concrete, verified fix.

---
description: Write a conventional-commit message from staged changes
allowed-tools: Bash(git diff --staged:*), Bash(git status:*), Bash(git log:*)
---
Write a commit message for the staged changes.

Run git diff --staged to see what is staged (and git status to confirm). If nothing is staged, say so and stop. Peek at git log --oneline -10 to match the repo's existing style.

Produce a Conventional Commits message:
- Subject: type(scope): summary in imperative mood, lowercase, no trailing period, under about 72 chars. Types: feat, fix, refactor, docs, test, chore, perf, build, ci.
- Body (only if the change is non-trivial): what changed and WHY, wrapped at about 72 cols.
- Footer for breaking changes (BREAKING CHANGE:) or issue refs from $ARGUMENTS.

Base the message ONLY on what is actually staged. Output the message in a plain code block, ready to paste. Do not run git commit yourself.

Reading only the staged diff and copying the repo's own log style yields a commit message that matches history instead of a generic one.

---
description: Draft a pull request description from the branch changes
allowed-tools: Bash(git diff:*), Bash(git log:*), Bash(git status:*), Read
---
Draft a PR description for this branch. Target branch: $ARGUMENTS (default: main).

Gather context: git diff target...HEAD for the full change, git log target..HEAD --oneline for the commits. Read key changed files if the intent is unclear.

Output this markdown, ready to paste:
## Summary
2-4 sentences: what this PR does and why it exists.
## Changes
Bulleted list of the meaningful changes (skip trivia like formatting).
## Testing
How it was verified, tests added/run, manual steps, commands.
## Notes for reviewers
Risk areas, follow-ups, anything needing a closer look. Omit if none.

Be accurate to the diff, do not claim work that is not in the changes. Keep it skimmable.

Building the summary from the branch diff and commit log keeps the PR description honest about what actually changed.