One Claude Code Tip a Day: Turn Repeated Prompts Into Slash Commands

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: your best prompt lives only in chat history

A useful Claude Code workflow usually starts as a messy paragraph. You ask it to review a pull request like a maintainer, check the diff against the issue, refuse drive-by refactors, run the focused test, and explain any hunk that does not map back to the failure. The first time, that paragraph is fine. The third time, it becomes a liability: you forget one constraint, a teammate phrases it differently, and Claude starts treating a review pass like an implementation task.

Today's habit is to promote repeated prompts into project slash commands. Not because slash commands are cute shortcuts, but because they turn a fragile ritual into a repeatable development instrument. A command like `/review-pr` can carry the same checklist, the same shell evidence, and the same edit boundaries every time the team uses it.

Build the command from a real session, not a fantasy process

Do not start by designing a perfect command library. Start after a real task exposes repetition. Imagine you are fixing a React checkout bug. Claude patched the component, the focused Playwright check passes, and now you want a review pass before committing. You catch yourself typing the same instruction you used yesterday: read the diff, identify behavior changes, call out risky CSS or state changes, and only suggest fixes that can be verified.

That is command material. Create `.claude/commands/review-pr.md` in the repo and encode the workflow you actually trust:

```markdown --- allowed-tools: Read, Grep, Glob, Bash(git diff *), Bash(git status *) description: Review the current diff against the task and verification evidence argument-hint: [task-summary] --- Task: $ARGUMENTS Current status: !`git status --short` Changed files: !`git diff --name-only` Review the diff as a maintainer. First summarize the intended behavior change. Then list risks by priority: correctness, tests, security, accessibility, and docs. Do not edit files. If a recommendation needs a patch, name the exact file and the verification command that would prove it. ```

The boring front matter matters. `allowed-tools` keeps the command in review mode instead of quietly wandering into edits. The argument hint reminds users to pass the task context. The embedded shell snippets make the diff and status part of the prompt, so Claude is reacting to the working tree, not to your memory of it.

Run it at the handoff point

The right moment to use the command is after the first working patch, not before Claude has read the code. For the checkout bug, the session might look like this:

`/review-pr checkout discount code should remain visible after mobile drawer closes`

A good response should not merely say “looks good.” It should group the diff by intent, point out that the CSS change affects both mobile drawer and desktop sidebar, notice that the Playwright test only covers the mobile viewport, and suggest either a desktop check or a narrower selector. That is the same TonBisa-style loop in a reusable wrapper: prompt, inspect, find the gap, correct, verify.

Inspect the command itself like production code

Custom commands can fail in subtle ways. The most common mistake is smuggling a vague mega-prompt into a file and calling it automation. If `/review-pr` says “review everything and fix issues,” you have not created a workflow; you have created a permission slip for scope creep. A better command says what evidence to read, whether editing is allowed, how to rank findings, and what verification must accompany each recommendation.

After writing the command, test it on a small, known diff. If Claude misses an important risk, patch the command, not just the chat. For example, suppose it reviews a frontend change but never mentions the browser viewport where the bug appeared. Add a line: `If the task is UI-related, name the viewport, browser check, and selector evidence required before approval.` Then run `/review-pr` again on the same diff. The second pass should be visibly sharper.

Use arguments for the unstable part

The stable part of a command is the process. The unstable part is the task. Keep them separate. Put the checklist, tool limits, and output shape in `.claude/commands/review-pr.md`; pass the task as arguments when you run it. For issue triage, the command might be `/triage-issue 184 checkout drawer regression`. For release checks, it might be `/release-gate staging deploy for billing dashboard`.

This separation prevents prompt drift. You can improve the review process once and reuse it across many tasks. You can also commit the command to the repo so teammates inherit the same guardrails instead of reverse-engineering your best chat transcript.

Failure modes

Do not make a slash command for a workflow you have not performed manually. You will encode guesses and give them authority. Do not allow broad Bash access just because it is convenient; specify the commands the workflow needs, such as `git diff`, `git status`, or the focused test pattern. Do not shadow a built-in command name unless you intend to replace that behavior for the project. And do not treat a command as a substitute for reading the output. Claude can still over-prioritize style comments, miss an environment assumption, or recommend a patch that does not map back to the task.

Also avoid building commands that hide destructive actions behind friendly names. A command that commits, pushes, migrates, or deploys should have a much stricter gate than a read-only review command. Start with read-only commands; earn automation later.

Rule of thumb

When a prompt becomes a habit, turn it into a slash command. Keep the command narrow, evidence-driven, and mostly read-only until it proves itself. The command should preserve what made the manual session work: exact context, bounded tools, inspection before edits, a second-pass correction path, and verification tied to the original task. If the command cannot make Claude read the right evidence every time, it is not a shortcut yet; it is just another place for prompt drift to hide.