Plan Mode and Slash Commands: How Senior Devs Use Claude Code

The two features that separate prompt-typers from production-grade engineers. Set up in under ten minutes.

This is Part 4 of a series on building a professional AI coding stack. Earlier parts: Skills, AGENTS.md, Hooks. Those covered what your agent knows and can’t ignore. This one covers how it thinks and how you stop thinking about the same thing twice.

---

I once burned four hours undoing a refactor that started with a thirty-second prompt.

The prompt was reasonable. The agent’s plan was reasonable. The execution was fast. What I didn’t realize until two hours in: the agent had decided to “consolidate” three unrelated modules into a shared abstraction. It made the diff smaller and the architecture worse. By the time I caught it, half the test suite was rewritten to match the new shape.

That was the day I learned Plan Mode.

It’s also the day I started building slash commands - because once I’d figured out the right way to brief the agent for that kind of refactor, I never wanted to figure it out again.

This article is about those two features. They’re built into Claude Code. They’re free. Most developers don’t use them. And the ones who do tend to ship two to three times faster than the ones who don’t.

Here’s why.

---

1) The Mental Model: Discovery, Then Codification

Most developers think of speed in AI coding as “how fast can the agent produce code.” That’s the wrong frame.

The actual bottleneck is everything before the code runs:

• Understanding what to build

• Mapping which files are affected

• Catching the edge cases that will bite you

• Choosing the right pattern from the codebase

• Briefing the agent precisely enough that it doesn’t guess

When you skip any of these, you don’t go faster. You just shift the cost to later - to debugging, to reverts, to “wait, why did it do that.”

Plan Mode is the feature that forces you to do the upfront work. Slash Commands are how you make sure you only do it once.

The loop:

Plan Mode is for the first time you encounter a problem.
Slash Commands are for every time after that.

Discovery and codification. Two halves of the same workflow.

---

2) Plan Mode: The Discovery Phase

Plan Mode is a permission state in Claude Code where the agent can read files, search the codebase, and analyze structure - but cannot modify anything. No file edits. No commits. No state-changing commands. The agent observes, thinks, and produces a plan. You review the plan. Only then does anything change.

It’s documented officially at code.claude.com/docs/en/permission-modes, alongside three other permission states: default, acceptEdits, and bypassPermissions. Plan Mode is the most cautious of the four - and the most underused.

How to activate

Two ways:

Mid-session toggle: Press Shift+Tab. The status bar cycles through permission modes. Press it twice and you’re in Plan Mode. The bottom of the terminal shows the active state.

At startup: Launch the session in Plan Mode directly:

claude --permission-mode plan

This is the better workflow for anything non-trivial. If you know you’re going to plan first, start in the right mode. No friction, no second-guessing.

You can switch out of Plan Mode at any point. Conversation context is preserved. The plan you developed remains on the page when you transition to execution.

What Plan Mode can and can’t do

Available tools in Plan Mode:

• Read - any file in your codebase

• LS - directory listings

• Glob - file pattern searches

• Grep - content searches across the project

Blocked in Plan Mode:

• Creating, modifying, or deleting files

• Running commands that change state

• Git commits

• Package installs

• MCP tool calls that mutate external systems

When Claude wants to exit Plan Mode and start executing, it calls a built-in tool called exit_plan_mode. This surfaces the proposed changes for your explicit approval. Nothing happens until you say yes.

The four-phase workflow

Anthropic’s own best-practices documentation recommends a specific structure for non-trivial tasks. It’s the pattern the Claude Code team uses internally:

Phase 1 - Read. Have the agent read the relevant code before proposing anything. Specify the directories, the existing patterns to study, the conventions to match. The agent should understand your current architecture before suggesting changes to it.

Phase 2 - Plan. Ask for a detailed plan. Files to change. Edge cases to handle. Tests to add. Decisions that have trade-offs. The agent writes the plan; you read it; you push back where it’s wrong.

Phase 3 - Implement. Switch out of Plan Mode. Let the agent execute against the agreed plan. Because the planning was thorough, the execution is mechanical.

Phase 4 - Commit. Have the agent write a descriptive commit message that references the plan. Optionally open a PR with the plan attached as context.

The compounding benefit is invisible until you try it: when execution is purely mechanical, you stop reviewing every diff line-by-line. You verify the plan was followed. That’s a different kind of review - faster, cheaper, and more aligned with how senior engineers actually work.

The 80/20 rule

There’s a quietly repeated observation across the Claude Code community: the developers shipping fastest spend roughly 80% of their session in Plan Mode and 20% in execution. Most newcomers do the opposite.

It sounds wrong because it feels slow. Sitting in read-only mode, asking the agent to explain the existing architecture, having it propose three different approaches before picking one - that doesn’t feel like progress.

But the math works out. Ten minutes of planning prevents an hour of rework. An hour of planning prevents a day of rework. The ratio holds up to a point - then it inverts and you’re over-planning trivial tasks. Calibration matters.

When to use Plan Mode

• Multi-file changes. Anything touching more than two files.

• Architecture decisions. Adding a new pattern, replacing one, or making a choice that locks in design.

• Refactors. Especially the kind that reorganize boundaries between modules.

• Security-sensitive code. Auth, permissions, payment flows, anything where a quiet mistake costs real money.

• Unfamiliar codebases. Client work, open-source contributions, code you didn’t write.

• Tasks where you’re not 100% sure what you want. If you can’t write a clear spec, plan first.

When NOT to use Plan Mode

• Bugfixes where the cause is obvious and the fix is one line.

• Adding a console.log.

• Renaming a variable.

• Typo fixes.

• Pure boilerplate generation where the agent’s defaults are fine.

Over-planning trivial tasks burns time the same way under-planning complex ones does. The skill is knowing which is which.

---

3) Slash Commands: The Codification Phase

Plan Mode helps you figure out how to do something for the first time. Slash Commands make sure you never have to figure it out again.

A slash command is a markdown file. The filename becomes the command name. The contents become the prompt sent to Claude when you invoke it. That’s the entire mechanism.

The rule, stolen from the Claude Code community:

If you run the same task more than twice, codify it as a slash command.

Where they live

Two scopes:

Project commands - .claude/commands/ inside the repo. Version-controlled, shared with your team, available only in that project. These show up as “(project)” in /help.

Personal commands - ~/.claude/commands/ in your home directory. Available across every project on your machine. Your personal toolbox.

For team work, project commands win. They live in git, they get reviewed in PRs, they evolve with the codebase. For personal workflows that span every project (release scripts, git hygiene, recurring audits), personal commands win.

The simplest possible command

Create a file. Write a prompt. That’s it.

mkdir -p .claude/commands
echo "Analyze this code for performance issues and suggest optimizations." > .claude/commands/optimize.md

Now /optimize works in any session in that project.

Frontmatter: where commands get powerful

YAML frontmatter at the top of the file adds metadata and constraints. The full spec:

---
description: Brief description shown in /help
argument-hint: [arg1] [arg2]
allowed-tools: Read, Bash(git status:*), Edit
model: claude-sonnet-4-20250514
disable-model-invocation: false
---

What each field does:

• description - what shows in /help. Also what Claude reads to auto-invoke the command when a prompt matches.

• argument-hint - autocomplete guidance for the user.

• allowed-tools - restricts what the command can do. A code review command might only need Read. A release command needs Bash(git ...) and Edit.

• model - lock the command to a specific model. Use Haiku for cheap repetitive tasks, Opus for high-stakes reasoning.

• disable-model-invocation - prevent Claude from auto-invoking this. Useful for destructive or expensive commands you only want triggered explicitly.

Arguments

Slash commands accept user input. Two ways:

Positional: $1, $2, $3 for specific arguments.

---
description: Fix a GitHub issue with priority
argument-hint: [issue-number] [priority]
---
Fix issue #$1 with priority $2. Follow these steps:
1. Read the issue description
2. Identify the affected files
3. Propose a fix in Plan Mode first
4. Run the existing test suite after applying the change

Invoked as /fix-issue 123 high, this becomes “Fix issue #123 with priority high.”

Bulk: $ARGUMENTS captures the entire trailing string.

Review the file at $ARGUMENTS for consistency with our patterns.

Invoked as /review src/api/users.ts, this becomes “Review the file at src/api/users.ts for consistency with our patterns.”

Inline bash and file references

Two more tricks worth knowing:

Bash execution: prefix a command with ! to run it and embed the output in the prompt.

---
allowed-tools: Bash(git status:*), Bash(git diff:*)
description: Generate a commit message from the current diff
---
## Current state
- Status: !`git status`
- Diff: !`git diff HEAD`

Write a commit message that describes these changes following our convention: type(scope): description.

When you run /commit, the agent sees the actual current git status and diff embedded directly in the prompt. No copy-pasting. No stale context.

File references: @path/to/file includes file contents.

Generate a new React component named $1 matching the conventions in @src/components/Button.tsx and @src/components/Input.tsx.

The referenced files are loaded into context automatically. The agent reads your patterns before writing new code.

Namespacing

Subdirectories create namespaced commands. A file at .claude/commands/frontend/component.md becomes /project:frontend:component. Useful when you have a lot of commands and want to organize them by domain.

---

4) The Loop: Discovery → Codification

Here’s how the two features compound.

You hit a new problem - say, shipping an iOS build to TestFlight in a way that fits your specific pipeline. You don’t know the right sequence yet, so you enter Plan Mode and work it out with the agent. Read the build config. Check the existing scripts. Identify the version-bump pattern. Decide which metadata gets touched. Build the plan.

You execute. It works.

You ship the build.

That’s a one-time success. Without codification, the next time you ship - tomorrow, next week, three months from now - you do the same discovery work again. Maybe you remember most of it. Maybe you don’t.

The codification step is what makes the next time free.

You take the prompt that worked - the one Plan Mode helped you develop - and you save it as .claude/commands/ship-testflight.md. You add frontmatter to lock down the tools. You parameterize the version bump with $ARGUMENTS. You add an inline !`git status` so the agent always sees current state.

Now /ship-testflight 1.4.2 is one command. The forty minutes of discovery becomes a fifteen-second invocation.

Multiply this across every recurring task in your workflow:

• Release pipelines

• Code review templates

• Bug triage protocols

• New feature scaffolding

• Documentation generation

• Migration scripts

• Test failure diagnostics

Every one of these starts as Plan Mode work. Every one of these ends as a slash command. The first time costs you an hour. The hundredth time costs you nothing.

This is what compounding looks like in a real coding workflow.

---

5) The Updated Stack

With Plan Mode and Slash Commands, the architecture from the previous three articles gains its operational layer:

Policy - AGENTS.md / CLAUDE.md - advisory rules, always present at session start.

Procedures - SKILL.md files - on-demand workflows, loaded by description match.

Automation - Hooks in .claude/settings.json - deterministic guardrails on lifecycle events.

Discovery - Plan Mode - read-only analysis, activated via Shift+Tab or --permission-mode plan.

Codification - Slash commands - reusable prompts, invoked explicitly with /command.

The mental model:

• AGENTS.md tells the agent what to think about always.

• Skills tell the agent how to perform specific procedures.

• Hooks tell the agent what it cannot do.

• Plan Mode tells the agent to think before doing.

• Slash Commands turn proven thinking into one-line invocations.

Five layers. Five concerns. Each addresses a different failure mode of working with an AI coding agent. Together they’re what people mean when they describe their setup as “production-grade.”

---

6) Three Slash Commands to Install Today

Here are three commands that earn their keep across every project I work on. Copy them. Modify them. Ship them.

/plan - structured discovery

---
description: Enter Plan Mode and structure analysis for a non-trivial task
argument-hint: [task description]
---
You are entering Plan Mode for this task: $ARGUMENTS

Follow this structure:

1. **Read** - identify and read all relevant files. List them.
2. **Constraints** - identify constraints, edge cases, and trade-offs.
3. **Approaches** - propose 2-3 distinct approaches with pros/cons.
4. **Recommendation** - pick one and explain why.
5. **Plan** - write a step-by-step implementation plan with files to touch.

Do not modify anything. Do not call exit_plan_mode until I approve.

This formalizes the Plan Mode workflow into a single command. You invoke it with your task description and the agent walks the structure every time.

/commit - context-aware commit messages

---
description: Generate a commit message from current changes
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log -5:*)
---
## Current state
- Status: !`git status`
- Diff: !`git diff HEAD`
- Recent commits for style reference: !`git log -5 --oneline`

Write a commit message matching the convention of the recent commits above.
Format: type(scope): description (max 72 chars on the first line).
If the change is non-trivial, add a body with 2-3 bullets explaining why.
Output only the commit message. No commentary.

No more thinking about commit messages. The agent reads your style from recent commits and matches it.

/review - read-only code review

---
description: Code review of specific files, no modifications
allowed-tools: Read, Grep, Glob
argument-hint: [file path or directory]
---
Perform a senior-level code review of $ARGUMENTS.

Check for:
- Correctness and edge cases
- Consistency with existing patterns in the codebase (use Grep to compare)
- Security issues (auth, input validation, secrets)
- Performance concerns
- Test coverage gaps

Output structured feedback:
1. **Critical** - must fix before merge
2. **Important** - should fix
3. **Minor** - optional improvements

Do not modify any files. This is review only.

Restricts the agent to read-only tools via allowed-tools, so it physically cannot edit files during a review. The review structure produces consistent output every time.

---

7) The Meta-Pattern

Once you internalize the discovery-codification loop, you start seeing it everywhere.

Every time you write a prompt longer than two paragraphs, you’re doing discovery. The question is whether you’re going to throw that work away when the session ends, or whether you’re going to capture it.

Slash commands are the cheapest capture mechanism available. A file. Some markdown. Optional frontmatter. That’s it.

The cost of saving a slash command is roughly thirty seconds. The savings compound forever. There’s no version of this math that doesn’t favor codification.

What this looks like over time:

• Month 1: You write three slash commands. They feel like overkill.

• Month 3: You have a dozen. You realize you haven’t written a fresh deploy prompt in weeks.

• Month 6: You’ve got a personal library that travels with you. New projects bootstrap faster because half your workflow is already encoded.

• Month 12: People ask why your output looks so polished. You don’t have a great answer except “I use slash commands.”

The compounding is invisible until you compare against someone who isn’t doing it. Then it’s enormous.

---

The Stack Continues

Four articles. Five layers. One coherent system for working with AI coding agents.

The next article in the series is on MCP servers - how to extend your agent’s reach beyond the codebase to GitHub, Postgres, Figma, Sentry, and the rest of your stack. Then Agent Teams: how to run multiple Claudes in parallel without them tripping over each other.

For now, do three things this week:

1. Use Plan Mode for your next non-trivial task. Shift+Tab twice. Watch how different the agent’s output is when it can’t immediately start typing.

2. Save one prompt as a slash command. Any prompt you’ve written more than twice. The thirty seconds it takes is the cheapest investment in your workflow.

3. Start your next session with claude --permission-mode plan instead of typing your prompt directly. The friction is in your habits, not the tool.

Speed in AI coding isn’t about prompting faster. It’s about thinking better and then never thinking the same thought twice.

The agent will do the typing. Your job is the design.

---

If you found this useful, the previous articles in the series are Skills, Not Prompts, AGENTS.md: The File Nobody Writes Well, and Hooks: The Guardrails Your Agent Can’t Ignore. Follow @13doots for more practical AI coding workflows.