Claude Code for Clinicians Chapter 11

Chapter 11: Slash Commands

A slash command is a shortcut you type starting with a forward slash. Type /clear instead of “please discard our conversation so far and start a clean session.” Type /cost instead of “how much have I spent in this session.” A slash command is the keyboard equivalent of the order-set buttons in the EMR: one click (one keystroke) does the thing you would otherwise have to spell out.

Some slash commands are built into Claude Code from day one. Others you write yourself, and they live in a folder inside your project. Both kinds work the same way: you type a forward slash, you pick the command from the menu that appears (or finish typing the name), you press Enter, and Claude does the thing.

After a week of using Claude Code seriously, your fingers will learn three or four of these the way they already know Ctrl-C. That is the goal.

🧠 Remember. A slash command is just a shortcut. You are not learning a new programming language; you are learning a small set of typed buttons.

The Built-In Commands Worth Knowing

There are dozens of built-in slash commands. You do not need to memorize them. Typing /help at any time will list them. Here are the ones that matter for daily work, grouped by purpose.

Figure 17
Figure 17. output of /help in Claude Code listing every available slash command, built-in and custom

Session control

Cost and model

Configuration

Productivity

🧠 Remember. The two most important built-in commands are /clear and /compact. They are the difference between a productive day and a session that slowly turns into confused mush. Use them aggressively, and especially when you switch from one unrelated task to another.

💡 Tip. /rewind is the most underused command in Claude Code. If a conversation has gone off the rails, do not argue with Claude for ten minutes trying to steer it back. Hit /rewind, pick the point right before the mistake, and try a different angle.

Custom Slash Commands: Just a Markdown File

The built-in commands are useful, but the real power is that you can write your own. There is nothing to install and nothing to register. A custom slash command is a markdown file dropped into a folder. The filename (without the .md) is the command name. The contents of the file are the instructions Claude will receive when you type that command.

That is the entire system. A file is a command.

The folder is .claude/commands/ at the root of your project. If you make .claude/commands/standup.md, you now have a /standup command. If you make .claude/commands/run-aidi-eval.md, you have /run-aidi-eval.

💡 Tip. Custom commands committed to the project’s git history are shared with the whole team. Custom commands in ~/.claude/commands/ are personal — they follow you across projects but nobody else gets them.

A Minimal Example: /commit

Here is a small custom command for making a git commit. Save this as .claude/commands/commit.md:

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*)
argument-hint: [message]
description: Create a git commit with context
---

## Context

- Current git status: !`git status`
- Current git diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

## Your task

Based on the above changes, create a single git commit.

If a message was provided via arguments, use it: $ARGUMENTS

Otherwise, analyze the changes and create a conventional commit message:
- `feat:` for new features
- `fix:` for bug fixes
- `refactor:` for code refactoring
- `test:` for adding tests
- `docs:` for documentation changes

Three things in that file are worth understanding.

The block at the top, between the --- lines, is called the frontmatter. It is configuration for the command. allowed-tools is the list of shell commands the slash command is pre-approved to run without asking you each time. argument-hint is what shows up in the menu telling the user what to type after the command name. description is what shows in the slash-command picker.

The lines with the ! prefix run as shell commands before Claude even sees the prompt. Their output gets pasted into the prompt itself. So !git status`` runs git status on your computer, and the output is included in what Claude reads. This is how you give Claude the current git diff without having to copy and paste it.

$ARGUMENTS is a placeholder. Whatever you type after the slash-command name gets substituted in. If you type /commit fix the AKI null handling, the string fix the AKI null handling ends up where $ARGUMENTS is.

🔧 Technical Stuff. The ! shell expansion and the $ARGUMENTS substitution happen on your laptop, before the prompt is sent to Claude. They are nearly free in terms of cost — the only token cost is the shell output itself, not the substitution machinery.

A KHCC Custom Command: /run-aidi-eval

Here is the command that earns its keep in AI Office work. The deceased-patient eval cohort is the gate every prompt change must pass before it ships (see Chapter 0.5 if that phrase is unfamiliar — it is the frozen reference dataset of about 1,000 deceased patients with hand-curated ground truth, and every clinical pipeline at the AI Office is graded against it). Running the eval suite by hand is several steps: trigger a Databricks job, wait for it to finish, query the results table, compare against the previous run, decide pass or fail. You do not want to type that out every time.

Save this as .claude/commands/run-aidi-eval.md:

---
allowed-tools: Bash(databricks jobs run-now:*), Bash(databricks jobs get-run:*)
argument-hint: [pipeline-name]
description: Run the deceased-patient eval suite against a pipeline and report results
---

## Context

- Pipeline under test: $ARGUMENTS
- Eval cohort: `aidi_catalog.dbo.eval_cohort` (frozen deceased-patient set)
- Results table: `aidi_catalog.dbo.eval_runs`

## Your task

1. Trigger the Databricks eval job for the pipeline `$ARGUMENTS`. Use the job ID
   mapped in `docs/eval-jobs.json`.
2. Poll the run until it completes (status `TERMINATED`).
3. Query `aidi_catalog.dbo.eval_runs` for the latest run of `$ARGUMENTS` and
   compare against the previous run on the same pipeline:
   - Accuracy delta
   - Precision/recall delta
   - Any new failure cases (rows where `prev_pass = true AND new_pass = false`)
4. Report:
   - Pass/fail summary
   - Regressions (must be zero to ship)
   - Any new wins
5. Do NOT modify any prompt or pipeline code. This command is read-only.

## Acceptance

If there are any regressions, the output must start with `EVAL FAILED`.
If zero regressions, start with `EVAL PASSED`.

Now anyone on the team types /run-aidi-eval pathology-v6 and gets back a clean pass-or-fail with a diff against the previous run. The whole workflow — which job to trigger, which table to query, what counts as a regression, how the output should be formatted — lives inside the command. Nobody has to remember the details.

⚠️ Warning. Custom commands that run shell commands are powerful, which means they can also be dangerous. Always set allowed-tools to the narrowest list possible. A command that allows Bash(*) (any shell command at all) can do rm -rf on your repository when Claude takes a creative interpretation of your prompt. Be specific.

Two More Examples Worth Stealing

A /optimize command that reviews code for performance:

---
description: Analyze code for performance issues and suggest optimizations
---

# Code Optimization

Review the file(s) I just shared for the following, in priority order:

1. **Performance bottlenecks**: O(n²) operations, inefficient loops, repeated work.
2. **Memory issues**: unreleased resources, large intermediate copies.
3. **Algorithm improvements**: better data structures, vectorization opportunities.
4. **Caching opportunities**: repeated computations that could be memoized.

For each finding, output:
- Severity (Critical / High / Medium / Low)
- Location (file:line)
- Explanation
- Recommended fix, with a code example

A /standup command that summarizes what you did yesterday:

---
allowed-tools: Bash(git log:*)
description: Summarize yesterday's work for the morning standup
---

## Context

Recent commits: !`git log --since=yesterday --oneline --author="$(git config user.email)"`

## Your task

Summarize the work above in three to five bullets suitable for a morning
standup. Lead with what shipped, follow with what is in progress, end with
any blockers I should raise.

Notice that none of these involve any new programming. They are just prompts saved to a file. The file is the command.

💡 Tip. The fastest way to learn custom commands is to copy good ones from open repositories. The community has converged on a small set — commit, pr, optimize, standup, review — and they are easy to adapt. Find one close to what you want, change a few lines, save it under .claude/commands/.

Where Custom Commands Live

If a project-level command and a personal one share a name, one shadows the other — in current versions the personal file wins, but do not build on that; give them different names. The convention is: team workflows go in the project; your personal shortcuts go in your home folder. (Newer versions of Claude Code treat custom commands and skills — Chapter 12 — as one system under the hood; your .claude/commands/ files keep working either way.)

Try This

  1. Type /help inside Claude Code and read the list. Pick three built-in commands you did not know existed. Try them once each.
  2. Run /cost after your next hour of work. Note the number. Run /clear. Notice how the next prompt feels different on a clean session.
  3. Make .claude/commands/standup.md using the example above. Run it tomorrow morning and see what comes back.
  4. Adapt the /commit example for your project’s commit message style. Use /commit for the next week instead of typing commit messages by hand.

Watch Out