How to write reusable slash commands for AI coding agents

You've typed this prompt before. Probably forty times.

"Review the diff on this branch: look for missing tests, unhandled errors and anything that doesn't match the conventions in the repo. Don't fix anything, just list what you find, worst first."

The first version was careful. The one you typed this morning was a tired paraphrase, and the agent handed you a tired paraphrase of an answer back.

That's the quiet tax of prompting from memory: your best prompt exists exactly once, in a terminal you've already closed.

A slash command is just a prompt with a filename

Most coding agents now let you save a prompt to a file and invoke it by name. In Claude Code you drop a Markdown file into .claude/commands/ and it becomes /review-diff. Other agents have their own equivalent (the folder and the file format differ, so check your tool's current docs), but the idea is identical: a prompt you refined once, stored where the whole repo can reach it.

There's nothing clever in the mechanism. The file's contents get sent as your message. What changes is which version runs: the careful one, every time, including at 6pm on a Friday.

Find your commands in your history, don't invent them

Scroll back through a week of sessions and look for prompts you've typed more than twice. That list is your command library, already written. The usual suspects:

• Procedures with a step you keep forgetting. Cutting a release. Adding a migration. The thing where you always miss the changelog.
• Chores with a fixed shape. Triaging a bug report, writing the PR description, checking a dependency bump for breaking changes.
• The prompt that finally worked. After three tries you found the phrasing that made the agent reproduce the bug instead of guessing. Save that one.

If it's shaped the same way every time and only the subject changes, it's a command.

What separates a good command from a saved paragraph

• One job. /write-tests beats /do-the-thing. Commands you can chain stay useful; commands that do everything get edited every time you run them, which defeats the point.
• Steps, in order. "First reproduce it with a failing test. Then find the root cause. Then fix it. Then re-run the suite." Agents follow a numbered procedure far more reliably than a wish.
• Where to look. Naming the two directories that matter saves the agent a scavenger hunt through your repo, and saves you the tokens it burns doing it.
• A definition of done. Run the formatter, update the tests, keep the change scoped. Otherwise "finished" means whatever the model felt like.
• A slot for the variable part. Most agents support an argument placeholder, so /fix-issue 412 passes the ticket number straight through. Check your tool's syntax; the concept is universal.
• The don'ts. "Don't refactor anything you weren't asked to touch" is worth more than another paragraph of encouragement.

Write them like short procedures, not essays. Ten to twenty lines is plenty.

What not to turn into a command

Standing rules. Anything true on every task (your test command, your naming conventions, the folders that are off limits) belongs in an AGENTS.md file, not in each command. Context your agent always needs should be loaded once, not pasted into fifteen files that all drift apart.

The split is simple: AGENTS.md is who you are, a command is what to do now.

One-offs. If you'll run it twice, just type it. A library of forty commands you can't remember is worse than five you actually use.

Work you can't check. A command makes an agent consistent, not correct. Codify a sloppy procedure and you get sloppy output on a schedule, faster, and harder to notice.

The honest catch: commands rot

A command that references a script you renamed will confidently do the wrong thing, with no error to warn you. Saved prompts are code: commit them, let teammates fix them, and delete the ones you stopped running. Once the same commands live in three repos, package them as a Claude Code plugin so a fix in one place reaches all of them.

They improve the same way. Every time an agent misreads a command, fix the wording instead of working around it in chat. Six weeks of that and the file encodes what your project actually needs, not what you assumed on day one.

Where a command wants to become a routine

Sooner or later you notice most of your commands are things you run on a schedule, not on a whim: the Monday triage, the nightly test-flake sweep, the dependency check nobody enjoys.

That's the workflow SanuDesk is built around. It's a desktop app where your Claude Code, Codex and Gemini sessions tile into one grid, each workspace pointed at a project folder, with a Kanban board the agents take their work from. A saved command and a card on the board do the same job from different angles: one is a procedure you invoke, the other is a brief you deploy, and Loops are the version that runs itself, firing the same brief on a schedule with nobody watching.

It drives the agent subscriptions you already pay for, so nothing here is metered by us, and the free tier is a real one. The payoff shows up fastest when several agents are running at once: shared commands are how a fleet stays consistent instead of inventing four different ways to write a test.

Start with the one you typed twice today

Don't plan a library. Open the prompt you retyped this morning, paste it into a file, name it after the job, and use it tomorrow. Fix the wording the first time it disappoints you.

Ten minutes, and the best version of your thinking stops living in scrollback, which is also the first step toward the chores running without you.

Download SanuDesk free and point a workspace at your repo, or see how the grid, the board and Loops fit together on the features page.