A slash command is a Markdown file whose body becomes a prompt. It is the simplest way to stop retyping the same request — a review, a release check, a summary in the shape your team expects — and the least fussy thing in the whole configuration surface. The one place it goes wrong is arguments. Everything typed after the command name arrives as one placeholder, the individual words as numbered ones, and a body that never references either of them ignores whatever the user passed while still advertising that it takes something. This builder writes the file, offers the placeholders as buttons, and flags that mismatch in both directions.
Features
Placeholders inserted from buttons rather than remembered
Warns when an argument is advertised but the prompt never uses it
Warns when the prompt takes an argument but nothing tells the user what to pass
Optional tool allow-list and model override
Name checked as a filename, since that is what it becomes
Project or personal scope with the matching path
A live preview of how the command will be typed
Downloads as a ready-to-use .md file
How to use the Slash Command Builder
Name the command — that becomes both /name and the filename
Write the prompt, inserting $ARGUMENTS or $1 where the input goes
Add an argument hint so the user knows what to pass
Pick a scope and download the file
Example
Input
argument-hint: <pr-number>
Output
Review pull request #$1.
The hint and the placeholder have to agree, or one of them is a lie.
Common errors & troubleshooting
The command ignores what I typed after it. — The body has to reference the input. $ARGUMENTS is everything typed; $1, $2 and $3 are the individual words.
The command does not appear in the list. — The filename is the command name, so it has to be lowercase and hyphenated, and the file has to be in the commands directory for the scope you chose.
The description is missing from the list. — It comes from the description field in the frontmatter. Without it the command appears unlabelled.
$1 and $ARGUMENTS seem to overlap. — They do — $ARGUMENTS includes everything, $1 is the first word of it. Use one or the other unless you genuinely want both.
Frequently asked questions
What is the difference between $ARGUMENTS and $1?
$ARGUMENTS is the whole string typed after the command name. $1, $2 and $3 are the individual whitespace-separated words. Use the numbered ones when the command takes a fixed set of inputs, and $ARGUMENTS when it takes open-ended text.
Do I need an allowed-tools list?
No, and most commands do not. It is worth setting when a command should be able to run something specific without asking each time, or when you want the command to be unable to do something the session otherwise could.
Where does a command file live?
A project command lives in the repository so the whole team gets it; a personal one follows you between projects. The exact path is shown and updates with the name.
Can a command call tools or run shell commands?
The body is a prompt, so it can ask for anything the session could do anyway. The allowed-tools list narrows or widens what runs without a prompt; it does not grant anything new.
When should this be a command rather than a skill?
A command is invoked deliberately by typing it. A skill is matched automatically when a task looks relevant. If you want to choose when it happens, write a command; if you want it to happen on its own, write a skill.
Related tools
Skill Builder — Write a SKILL.md with the frontmatter checked as you type.
Subagent Builder — Build a subagent definition file with its tools and model set.
Hooks Builder — Build settings.json hooks and catch the matchers that never fire.