Claude Code Custom Slash Commands for Client Work: Build Once, Trigger On Demand
- A custom slash command is a markdown file in a commands folder. The filename becomes the command name, and the body is the prompt Claude runs when you type /that-name, with anything typed after it available inside the prompt as $ARGUMENTS.
- Where you save it decides who gets it: a command in a client's own project folder ships with that repo and travels with the delivery; a command in your personal folder follows you to every project and stays yours.
- Slash commands are for the actions you want to trigger yourself, on purpose, by typing them. That is the opposite of a Skill, which Claude decides to use on its own, and a hook, which fires automatically on an event you never type.
What a Custom Slash Command Actually Is
Open a plain markdown file, write out the instructions you want Claude to follow, save it with a short filename, and that filename becomes a command. Save `qa-pass.md` and you now have `/qa-pass`. Type it in any session in that project (in the desktop app, on the web, or in the terminal if that is how you work) and the body of that file runs as your prompt, exactly as written, every time.
The point is not that this saves typing, though it does. The point is that it saves drift. A client task you do from memory changes slightly every time you describe it: a step gets skipped under deadline pressure, a phrase gets reworded and Claude reads it differently. A command is written once and run the same way every time you type it, on this client and the next one.
Where They Live: Project vs Personal
A command saved inside a client's own project folder is scoped to that project and, if you commit it, ships with the repo. Anyone else who opens that codebase, a teammate, a future contractor the client hires, inherits the same command. That is worth knowing before you write one: a project-level command is effectively part of the delivery, not just a personal shortcut.
A command saved in your own personal commands folder, outside any single project, follows you to every client instead. That is where your own repeatable process belongs: the pre-delivery check you run on every build, the way you always want a status update phrased, the habits that make you faster regardless of which client's repo you happen to be sitting in.
| Location | Who gets it | Good fit for |
|---|---|---|
| Client's project folder | Ships with the repo; anyone who opens the project later inherits it | Client-specific workflows, delivery checklists you want documented in the codebase itself |
| Your personal commands folder | Follows you across every project; private to you | Your own repeatable process: QA passes, update formats, habits that are not this client's business |
Where a command lives changes who inherits it
How to Write One
The body of the file is the prompt, written in plain language exactly as you would type it into a session. Above that, a short block of frontmatter can add a description (what shows up when you are choosing which command to run) and a list of tools the command is allowed to use without asking you again each time.
Anything you type after the command name is available inside the prompt as $ARGUMENTS, so a single command can flex to the situation instead of being locked to one hardcoded case. `/changelog since last Tuesday` and `/changelog for the invoicing feature` can run off the same file, with the specifics filled in by whatever you typed.
- Write the prompt as a numbered set of steps if the task has a real order to it. Claude follows a clear sequence more reliably than a paragraph of loosely connected asks.
- Add a description in the frontmatter even if it feels redundant with the filename. It is what you and anyone else on the project see when scanning available commands later.
- Only grant a command tools it actually needs. A command meant to generate a client update should not carry the same standing permission as one meant to run tests and commit.
- Test the command on a low-stakes case before you rely on it mid-delivery. A prompt that reads clearly to you can still be ambiguous to Claude in a way you only catch by running it.
Three Commands Worth Building for Client Work
| Command | What it does | Where it belongs |
|---|---|---|
| /qa-pass | Runs your standard pre-delivery checklist: check for console errors, broken links, unhandled edge cases, before you ever say a build is done | Personal, your own delivery standard across every client |
| /handoff-notes | Turns the session's changes into a short, plain-language note explaining what changed and why, written for the client, not for another developer | Personal, but the output often gets pasted into the client's own update thread |
| /client-update | Summarizes recent commits or session activity into a short status update in your usual tone, ready to send | Personal, tuned to how you like to write to clients |
Start with the tasks you already repeat on every client
None of these are complicated to write. The value is entirely in the fact that you stop reconstructing them from scratch under deadline pressure, on the client where you are least likely to write a careful prompt.
Slash Commands vs Skills vs Hooks vs Subagents
These four sound similar because they all live in the same `.claude` folder structure, but they answer different questions about who decides when something runs.
| Tool | Who decides to run it | Good fit for |
|---|---|---|
| Slash command | You, by typing it | A task you want to trigger deliberately, on your own timing |
| Skill | Claude, automatically, when it judges the task matches | A task Claude should recognize and apply on its own without you remembering to ask |
| Hook | The system, automatically, on a defined event (before a tool runs, after a session ends) | Guardrails and side effects that should never depend on you remembering to trigger them |
| Subagent | You or Claude, to delegate a bounded sub-task to a separate context | Work you want isolated from the main conversation's context, like a focused review pass |
Four tools, four different triggers
If you already keep a [Claude Code skill](/blog/claude-code-skills-for-client-work) for a task, you probably do not also need a slash command for the same thing; the skill fires on its own. A slash command earns its place when you specifically want to decide the moment it runs, not have Claude infer it. And [hooks](/blog/claude-code-hooks-for-client-work) are the right layer under both, for the safety net that has to fire no matter which of the two you were using.
A Habit for Building Commands on Client Work
- The second time you catch yourself typing out the same request to Claude on a different client, that is the signal to turn it into a command, not the first time.
- Write it once, run it immediately on the task in front of you, and fix anything that reads wrong before you move on. A command you never tested is a command you will not trust later.
- Keep a short list of your personal commands somewhere you will actually look at it. A command you forget exists provides zero value over one you never wrote.
- Revisit a command the first time it produces a bad result. Update the file, do not just work around the bad output that one time and move on.
Common Mistakes
- Saving a personal workflow habit inside a client's project folder, so it ships with the delivered repo and raises questions you did not mean to invite.
- Writing a command once and never testing it, then discovering mid-session that the prompt reads differently to Claude than it did in your head.
- Granting a command broad tool access out of convenience instead of only what the task needs.
- Building a command for a task you have only done once. Save that instinct for the second repeat, not the first.
Inside the Claude Code Profit Room, builders trade the actual commands they run on client work, the ones that earned their place and the ones that turned out to be a personal Skill in disguise. It's $9 a month at https://www.skool.com/claudecodeprofitroom/about, come compare notes on what you have automated.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What is a custom slash command in Claude Code?
A markdown file saved in a commands folder. The filename becomes the command name, and the file's contents become the prompt Claude runs when you type /that-name in a session. Anything typed after the command name is available inside the prompt as $ARGUMENTS.
Where should I save a custom slash command for client work?
Save it in the client's own project folder only if it should ship with that codebase and be inherited by anyone who opens the project later. Save it in your personal commands folder if it is your own repeatable process that should follow you to every client instead.
What is the difference between a slash command and a Claude Code Skill?
You decide when a slash command runs by typing it. Claude decides when a Skill runs, applying it automatically when it judges the task matches. Build a command for something you want to trigger deliberately; build a Skill for something Claude should recognize on its own.
Do custom slash commands work in the Claude Code desktop app?
Yes. Custom commands are read from the same commands folders regardless of whether you are running Claude Code in the desktop app, on the web, or from the terminal, so a command you build once is available wherever you open that project.
How do I pass information into a custom slash command?
Type it after the command name. Everything you type following /command-name is available inside the prompt as $ARGUMENTS, so one command file can handle different specifics each time you run it instead of being locked to a single hardcoded case.
Last reviewed August 31, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
