Slash commands as your team's internal CLI
Slash commands are a tiny abstraction that compounds fast. Build them for the workflows you repeat weekly, keep them parameter-light, and commit them to the repo so the team finds them.
If you've used Claude Code for more than a month, you've already typed the same prompt at least ten times. That's a slash command. The cost to make one is a folder and a markdown file; the saving compounds every week.
My rule for what becomes a slash command: anything I've typed twice in a week. /review for PR reviews against our internal style guide. /codemod for the boring AST-to-AST transforms that come up every refactor. /lint-explain for when the linter is yelling and I want a one-paragraph explanation, not a fix. None of them are clever; all of them save the typing tax.
Two things I'd skip: heavy parameters and conditionals. Keep slash commands flat. If a workflow needs branching logic, that's a skill, not a command. The reason: slash commands run as a prompt insertion. Branching means writing if/else in markdown, and markdown isn't a programming language no matter how hard you squint.
The underrated piece is sharing them. A `.claude/commands/` folder committed to the repo is how a team member gets your workflow for free on day one. Don't keep slash commands in your dotfiles. Commit them, document them in CLAUDE.md, and the team's productivity floor moves up together.