Where Does a /review Shortcut Live? Claude Code Slash Commands

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 27)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your team keeps typing the same three-paragraph prompt into Claude Code before every pull request: check the diff, flag missing tests, call out anything that touches auth. Someone finally says “can’t we just make this a command?” That question — turned into a reusable /review — is exactly the kind of thing Domain 3 of the Claude Certified Architect exam tests, because it is exactly the kind of thing you do in a real repo every week.

The one-sentence version: A custom slash command is a markdown file in .claude/commands/ — the filename becomes the command name, and the file’s contents become the prompt Claude Code runs when you type it.

The question

Your team wants a reusable /review shortcut. Where does it live?

• A) Hardcoded in the app
• B) A markdown file in .claude/commands/
• C) In CLAUDE.md
• D) An MCP server

Pause the video (or stop scrolling) and pick your answer before you keep reading.

The answer

The correct answer is B — a markdown file in .claude/commands/.

Create .claude/commands/review.md and it becomes /review. Everything Claude Code does when you invoke the command comes from what you write in that one file — the filename gives you the command name, the file body gives Claude the instructions to execute.

.claude/
└── commands/
    └── review.md          →  registers the command  /review
                                (filename = command name, sans .md)

┌─────────────────────────────────────────────┐
│ review.md                                    │
│                                               │
│ Review the current diff for:                 │
│ - missing test coverage                      │
│ - changes that touch auth or permissions     │
│ - any TODO left unresolved                   │
│                                               │
│ Report findings as a bulleted list.          │
└─────────────────────────────────────────────┘
                     │
                     ▼
        you type:  /review
                     │
                     ▼
   Claude Code loads review.md as the prompt
   and runs it against the current context

The scope of that file matters just as much as its content. Where you put it decides who gets the shortcut:

That split is the same shared-vs-personal pattern that runs through the rest of Domain 3: a project file is a team convention, a home-directory file is a habit that follows you around. Commit the project version so /review shows up for anyone who checks out the repo; keep your own experimental commands in the user-level folder so you’re not forcing half-finished shortcuts on your teammates.

One more mechanism detail worth knowing for the exam: slash commands can take arguments. A command file that references $ARGUMENTS (or numbered placeholders, depending on the current syntax — verify in the docs) lets you write /review src/auth/ and have that path substituted into the prompt. That’s what turns a static shortcut into a parameterized one, without touching any application code.

Why the other options fail

• A) Hardcoded in the app — There is no “app” to hardcode into. Claude Code is a CLI/agent harness that reads configuration from the filesystem; it doesn’t have a compiled command list you’d patch and redeploy. Baking /review into “the app” isn’t a real mechanism here — it describes building your own separate tool, not using the feature the exam is asking about.
• C) In CLAUDE.md — CLAUDE.md is always-on memory: standing context and conventions that get loaded into every conversation, not a registry of invokable shortcuts. You could describe your review process in prose there, but nothing makes /review typeable — there’s no filename-to-command mapping, and the content isn’t scoped to only load when you ask for it. That’s the same distinction covered in Instructions or a Hook — CLAUDE.md vs Hooks: CLAUDE.md is context Claude reads, not a mechanism it executes on command.
• D) An MCP server — MCP servers expose tools — typed functions Claude can call, usually backed by a live system (an API, a database, a search index). A code-review checklist isn’t a tool call with parameters and a return value; it’s a prompt. Reaching for an MCP server here is over-engineering a problem that a plain markdown file already solves. See MCP Explained on One Diagram for what MCP is actually for.

The concept behind it

Zoom out and slash commands are one of three distinct ways Claude Code lets you package repeatable behavior, and the exam consistently tests whether you can tell them apart by who or what triggers them and what they’re made of.

        WHO INVOKES IT?              WHAT IS IT MADE OF?
        ────────────────             ────────────────────
/name   →  YOU, explicitly    →      one markdown file
           (you type /review)        (the prompt itself)

Skill   →  CLAUDE, implicitly →      a folder: SKILL.md +
           (model decides             scripts/resources
            it's relevant)            (progressive disclosure)

CLAUDE.md → always loaded    →       standing project/user
           (no invocation)           context, no invocation

The generalizable rule: a slash command is a you-invoked shortcut made of a single file. You decide the moment it runs by typing its name. That’s different from an Agent Skill, which the model reaches for on its own when it judges the task relevant, and which typically bundles more than one file — instructions plus scripts or reference material the model loads progressively as needed. It’s also different from CLAUDE.md, which isn’t invoked at all; it’s just always there, shaping every response like standing instructions.

This is worth internalizing because the exam (and real Claude Code work) will keep asking “where does X live” in a way that’s really asking “who or what decides X runs, and what shape does X take.” Slash commands: you decide, one file. Skills: the model decides, a folder. CLAUDE.md: nobody decides, it’s just context. Hooks — covered elsewhere in this series — are the fourth pattern: the harness decides, deterministically, on a lifecycle event, which is why they’re the answer whenever a question says “guaranteed” or “every time” instead of “when relevant.”

Practically, this also tells you when not to reach for a slash command. If the behavior needs to run unconditionally on every file edit regardless of what you type, that’s a hook, not a command — nobody has to remember to type /lint if a PostToolUse hook already runs the linter automatically. If the “shortcut” secretly needs several files and reference material the model should pull in only when relevant, that’s an Agent Skill wearing a slash-command disguise — see Slash Command or Skill? When to Use Each for the fuller comparison. Slash commands earn their keep specifically for the middle case: a prompt you want to fire off by name, on demand, without retyping it.

FAQ

Can a slash command call other tools, like running a script or checking git status? Yes — a command file’s prompt can instruct Claude to use its existing tools (Bash, Read, Edit, and so on) just like any other conversation turn would. The command file itself is just the starting prompt; from there Claude Code’s normal agent loop and tool access apply. What the file gives you is a name and reusable instructions, not a new execution engine.

Do project and personal slash commands ever conflict if they have the same name? This is exactly the kind of precedence detail Domain 3 loves to test, and it’s also exactly the kind of thing that can change between Claude Code releases. The durable takeaway: project-level and user-level commands live in separate directories, and Claude Code has a defined resolution order between them — verify the current behavior in the official docs rather than assuming.

Is a slash command the same thing as a “custom command” in other AI coding tools? Conceptually yes — many agentic coding tools have converged on “a markdown file becomes a reusable prompt shortcut.” The concept transfers even if the exact directory name and file format differ across tools. What’s specific to Claude Code, and worth knowing cold for the exam, is the .claude/commands/ path and the project-vs-user split.

What happens if I put instructions in both a slash command and CLAUDE.md? They’re not mutually exclusive — CLAUDE.md’s content loads as standing context on every turn, and a slash command’s content loads only when you invoke it, added on top of whatever’s already in context. In practice, keep durable team conventions (“we use conventional commits”) in CLAUDE.md, and keep one-off, deliberately-triggered workflows (“run the full review checklist right now”) as slash commands.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is Domain 3 (Claude Code Configuration & Workflows, 20% of the exam) — the domain that tests whether you know where a piece of behavior lives and what guarantees it comes with, not exact syntax that can shift between releases. If you haven’t already, start with the Claude Certified Architect Exam Guide for all five domains on one diagram.

From here, the natural next stop is telling slash commands apart from their closest cousin in Slash Command or Skill? When to Use Each in Claude Code. If you’re still fuzzy on why CLAUDE.md isn’t the answer to “where does this live,” see Where Does a Team Convention Live? Project CLAUDE.md Explained and Instructions or a Hook — Which Runs Every Time? for the advisory-vs-enforced distinction that keeps coming back across this domain. For the personal-vs-shared pattern that also governs where a command file should live, see A Rule for You, Not Your Team: Local vs Shared Claude Code Settings.

Browse all tutorials for the full CCA prep series and everything else on The Stack Underflow.