ABHIJAT
← Back to Writing

Developer Tools

Custom slash commands for the workflows I run every day

Claude Code's slash commands stop being a novelty once you write your own. Notes on which repetitive workflows are actually worth automating this way.

Abhijat2026-076 min read4 views

Last updated September 17, 2026

The first few times you ask an agent to do something, typing it out fresh feels fine. By the tenth time you're re-explaining "review this diff for the same three things I always care about," it stops feeling fine. That's the signal a slash command is worth writing.

What makes a good candidate

Not every repeated prompt deserves a command. The ones that pay off share three traits: the instructions are stable (they don't change per-task, only the target does), the task has a clear success shape (a commit message, a review comment, a status check), and you run it often enough that the setup cost amortizes. A one-off "explain this algorithm to me" prompt doesn't need a command. "Write a commit message in our house style" does.

Commands worth having

A commit-message command is the easiest win — point it at the staged diff, give it your team's conventions (Conventional Commits, ticket-number prefixes, whatever you actually use), and stop re-typing the same three constraints every time. A close second is a PR-description command that reads the branch's full diff and commit history rather than just the latest commit, since that's the difference between a PR description that captures intent and one that just lists file changes.

The other one I reach for constantly is a narrow code-review command — not "review this," but "review this for the specific categories of bug we keep shipping." Off-by-one errors in pagination, missing null checks on optional API fields, whatever your team's actual recurring failure mode is. Generic review prompts produce generic findings; a command that encodes your specific blind spots produces findings that are actually worth reading.

Where it stops being the right tool

Slash commands are prompts with a name, not programs. Once a workflow needs real branching logic, needs to call multiple tools in a specific sequence with error handling between them, or needs to run unattended on a schedule, you've outgrown a command and want an actual script, or a subagent with a narrower tool surface. The tell is when you find yourself writing conditionals into the command's instructions ("if the diff touches migrations, also check X") — at that point you're programming in prose, and prose is a worse programming language than the one you already know.

The honest upside isn't that commands make you faster on any single run. It's that they make the repeated task cheap enough that you actually do it consistently, instead of skipping the review step when you're in a hurry.

Tags

Claude CodeDeveloper ToolsAutomation