A Claude Code Slash Command Library

The basic template

---
description: One-line summary that shows up in /help
argument-hint: <what-arguments-look-like>
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

The prompt body goes here. Use $ARGUMENTS to insert whatever the user
typed after the command name. Use $1, $2, $3 for positional args.

1. /review

---
description: Review the current diff for bugs, security, and style issues
argument-hint: [optional file or commit range]
allowed-tools: Read, Grep, Glob, Bash(git diff:*, git log:*)
model: sonnet
---

You are a senior code reviewer with 15 years of experience shipping production systems.

Review the following changes:
- If $ARGUMENTS is provided, review `git diff $ARGUMENTS`
- Otherwise, review `git diff HEAD`

Focus on:
1. Bugs and edge cases the author missed
2. Security issues (injection, auth bypass, exposed secrets)
3. Performance regressions
4. Breaking changes to public APIs

Output:
- Critical (must fix): file:line and a one-sentence fix
- Important (should fix): same format
- Nitpicks (optional): same format

Never approve code with critical issues. Be direct. No vague "consider refactoring."

2. /test

---
description: Write tests for the file or function that follows
argument-hint: <file-or-function-name>
allowed-tools: Read, Write, Edit, Bash
model: sonnet
---

Write tests for: $ARGUMENTS

Steps:
1. Read the target file and identify all branches, edge cases, and error paths
2. Read existing test files for conventions, match them
3. Write tests that fail when the implementation is wrong, not tests that mirror it

Priorities: edge cases > error paths > happy path. Skip trivial getter/setter tests.
Run the test suite after writing to confirm everything passes.

3. /migrate

---
description: Migrate code from one pattern, library, or version to another
argument-hint: <from> to <to> (e.g., "axios to fetch")
allowed-tools: Read, Edit, Grep, Glob, Bash
model: sonnet
---

Migration: $ARGUMENTS

Steps:
1. Use Grep to find every file using the old pattern
2. List the files first. Show me the plan before changing anything.
3. After approval, edit one file at a time. Run the test suite after each.
4. If a test breaks, stop and explain what happened.

Never do a bulk find-and-replace. Each file needs its own context.

4. /audit

---
description: Security audit of the file or path that follows
argument-hint: <file-or-path>
allowed-tools: Read, Grep, Glob, Bash
model: opus
---

Audit target: $ARGUMENTS

Check for:
- Hardcoded secrets, API keys, credentials
- SQL injection, command injection, path traversal
- Auth bypass, missing permission checks, IDOR
- Unvalidated user input flowing into dangerous sinks
- Secrets being logged, returned in errors, or sent to third parties

Output every finding with:
- file:line
- Severity (critical/high/medium)
- The attack scenario in one sentence
- The fix in one sentence

Be paranoid. Assume the input is hostile.

5. /doc

---
description: Update docs to match the current code
argument-hint: [optional path]
allowed-tools: Read, Edit, Grep, Glob, Bash(git diff:*)
model: haiku
---

Update docs to match code changes in: $ARGUMENTS (defaults to current diff)

Steps:
1. Run `git diff` to see what changed
2. Search the docs folder and README for references to changed symbols
3. Update only the sections that are now wrong
4. Do not rewrite, restructure, or "improve" anything else

If a feature has no docs at all, flag it. Don't invent new doc files unless told to.

6. /triage

---
description: Triage a bug report or issue
argument-hint: <issue-description-or-link>
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

Bug to triage: $ARGUMENTS

Steps:
1. Read the issue. Extract: expected behavior, actual behavior, repro steps.
2. Try to reproduce locally if possible.
3. Identify the file and probable line of the bug.
4. Rate severity: critical / high / medium / low
5. Suggest a fix approach. Do not write the fix yet.

Output:
- Root cause in one sentence
- Affected file:line
- Severity and reasoning
- Proposed fix in 1-3 bullet points

7. /refactor

---
description: Refactor the target with a safety-first approach
argument-hint: <file-or-function> [goal]
allowed-tools: Read, Edit, Bash
model: sonnet
---

Refactor target: $ARGUMENTS

Rules:
1. Enter plan mode first. Show me the plan before any edit.
2. Never touch more than the explicit target without asking.
3. Run the tests before refactoring to capture the baseline.
4. Run the tests after every change.
5. If a test breaks, stop and explain. Do not proceed until I approve.

Goal: maintain behavior, improve readability and maintainability.
If you can't do that without changing behavior, stop and ask.