Slash Command Generator

What a custom slash command is

A custom slash command in Claude Code is just a markdown file whose contents become a reusable prompt. Save a file at .claude/commands/review.md and you can type /review to run whatever instructions that file holds. The command name comes from the filename; the body is the prompt Claude Code executes. That is the whole idea - you are turning a prompt you keep re-typing into a single keystroke. The generator above assembles a valid command file for you: the frontmatter, the argument handling, and the body, formatted exactly the way Claude Code expects.

Slash commands are the cheapest, highest-leverage customization in Claude Code. Every workflow you repeat - reviewing a diff, writing a commit message, scaffolding a component, running your test-and-fix loop - is a candidate. Once it is a command, it is consistent, shareable, and one keystroke away.

Project commands vs personal commands

• Project commands live in .claude/commands/ inside the repo. They are committed to version control, so everyone on the team gets the same commands. Use these for shared workflows: the team's review command, the team's commit style, the project's scaffolding.
• Personal commands live in ~/.claude/commands/ in your home directory. They follow you across every project. Use these for your own habits: your personal explain command, your own refactor prompt, your quick-note command.
• The filename is the command name. review.md becomes /review. Names should be short, lowercase, and hyphenated.
• You can organize commands into subdirectories, which namespaces them - a file in a subfolder shows up under a grouped name in the command list.

Passing arguments into a command

Commands become far more powerful when they take input. Anything you type after the command name is available inside the prompt body as $ARGUMENTS. So /review src/auth passes 'src/auth' into the body wherever you wrote $ARGUMENTS. If you need individual positional arguments rather than the whole string, you can reference them by position ($1, $2, and so on). The argument-hint field in the frontmatter is purely cosmetic - it tells you and your teammates what the command expects when it appears in the command list. The generator wires $ARGUMENTS in for you if you enable arguments and forget to reference it.

The frontmatter fields that matter

• description - a one-line summary that appears in the slash-command list so you remember what it does. Always worth setting.
• argument-hint - a hint about the arguments the command expects, shown next to the command in the list.
• allowed-tools - restricts which tools the command may use. Scoping a command to only the tools it needs (for example a git-diff review command to Bash(git diff:*) and Read) is a good safety habit.
• model - optionally pin the command to a specific model. Leave it blank to run on whatever model the session is using. Reach for a heavier model only when the command needs deep reasoning.

Running shell context inside a command

A command body is a normal prompt, so it can instruct Claude Code to run tools as part of its work - for example, telling it to run git diff and analyze the result. Pairing that with a tight allowed-tools list gives you a command that does real work while staying inside a safe, predictable set of actions. This is the pattern behind most genuinely useful commands: gather some context with a tool, then reason over it toward a specific deliverable.

Commands worth building first

1. /review - run git diff on the staged changes and report bugs, security issues, and style problems grouped by severity.
2. /commit - draft a commit message in the repo's style from the staged diff, without committing.
3. /explain - explain the file or symbol passed in $ARGUMENTS at a level a new teammate could follow.
4. /test - run the test suite, read the failures, and propose the smallest fix for each.
5. /scaffold - generate a new component or module following the project's existing conventions, named by $ARGUMENTS.
6. /pr - summarize the branch's changes into a pull request title and description.

Keeping commands maintainable

Treat commands like small pieces of code. Give them one clear job each - a command that tries to do five things is hard to trust. Keep the body specific about the output you want, because a vague command produces vague results. Review your project commands the same way you review code, since they run with real tools. And when a command starts drifting from what you actually need, edit the markdown file directly - it is just text, and changes take effect the next time you invoke it.