Skip to main content
Part 3 of 6
8 min read

Part 3 of 6

Workflow That Works

Plan mode, effort control, session management, and the complete daily Claude Code workflow. Connect individual commands into one system.

Claude Code, Part 3: Workflow That Works

Plan mode, effort control, session management, and the daily flow that ties everything together.


From Commands to Workflow

Parts 1 and 2 gave you individual commands. This part connects them into a system: how to start a task, how to manage sessions across days, and how to calibrate Claude Code's reasoning.


Planning & Effort

Plan Mode: Combining the Three Modes

Part 1 covered what plan mode is and how the iteration loop works. Part 3 is about mode switching: combining plan mode with auto-accept and normal mode into one working rhythm.

Plan mode (Shift+Tab until "plan" appears, or type /plan)

  • No code edits. Claude Code reads files, runs shell commands to explore, and writes a plan. Permission prompts still apply for tools that would normally prompt.
  • Use for: tasks touching 3+ files, architectural decisions, unfamiliar code.
  • The closest thing to "explore → plan → approve" enforced at tool level.

Auto-accept mode (acceptEdits, Shift+Tab once from default)

  • Auto-accepts file edits in your working directory, plus a fixed set of common filesystem Bash commands (mkdir, touch, rm, rmdir, mv, cp, sed). All other Bash still prompts. Note the implication: rm, mv, and sed -i run unprompted inside your working directory, so keep the Part 6 destructive-command deny rules active (deny rules override acceptEdits) and don't leave the mode running unattended.
  • Use for: well-understood mechanical changes after you've approved a plan
  • Watch actively. Ctrl+C to interrupt if Claude Code drifts

Default mode (default)

  • Reads run without prompts. Edits and Bash commands prompt on first use of each tool.
  • Use for: most work, especially when exploring or learning the codebase

The mental model: Default for exploration. Plan for direction. Auto-accept for execution.

The pattern:

Start in plan mode → review the plan → switch to auto-accept → let Claude Code execute

The plan is where you want control. The execution is where you want speed. Switching modes between them gives you both.

/effort: Calibrate Reasoning Depth

Controls how much thinking Claude Code puts into each response. Available in most Claude Code setups.

/effort lowquick lookups, mechanical tasks
/effort mediummost work (typical default)
/effort higharchitecture, security review, tricky bugs
/effort xhighharder reasoning when high isn't enough (Opus 4.8/4.7; others fall back to high)
/effort maxmaximum reasoning; session-only
/effort autoreset to the model default

Run /effort with no argument to open an interactive slider. Left and right arrows to pick a level, Enter to apply. Available levels depend on the model you're using.

When to switch:

  • Starting a security review → /effort high
  • Asking "what's this function do?" → /effort low
  • Normal implementation → leave at medium

The cost tradeoff: Higher effort = more tokens = better reasoning. Don't run everything on high. Save it for decisions that matter.


Session Management

/resume: Pick Up Where You Left Off

/resume              → opens a session picker (recent sessions)
claude -c            → continues most recent session (from terminal)

When to use:

  • Start of day, to continue yesterday's work
  • After a break, to return to what you were doing
  • When you need to reference a previous session's context

Pro tip: If you keep a tasks/todo.md or similar checklist in your repo, /resume plus a quick read of that file gives you instant context for where you left off.

/init: covered in Part 4

/init generates a starting CLAUDE.md from your project. Covered with the project-setup tools in Part 4: Power Tools.

/memory: Browse and Edit Memory

/memory

Opens an interface to browse and edit both your CLAUDE.md instructions and Claude Code's auto memory files. Also has a toggle to enable/disable auto memory.

What is auto memory? Claude Code automatically saves notes as it works: build commands, debugging insights, code patterns, your corrections. These persist across sessions in ~/.claude/projects/<project>/memory/MEMORY.md. The first 200 lines (or 25KB, whichever comes first) load at the start of every session.

~/.claude/projects/<project>/memory/
├── MEMORY.md          # Concise index (first 200 lines or 25KB, whichever comes first)
├── debugging.md       # Example: detailed notes (loaded on demand)
└── api-conventions.md # Example: architecture decisions (loaded on demand)

The topic files are created by Claude Code as needed. The exact files depend on what Claude Code learns during your sessions.

The distinction: CLAUDE.md contains explicit instructions you maintain. Auto memory stores learned project notes Claude Code writes and reuses across sessions. /memory lets you inspect both what's loaded and what Claude Code has remembered.

Why this matters: When you correct Claude Code, it may save that correction to auto memory for future sessions. Next time, it already knows. The system learns from your corrections without you manually updating CLAUDE.md. (What gets saved depends on Claude Code's judgment about what's worth keeping across sessions.)

When to use /memory: To review what Claude Code has learned, edit incorrect auto-memories, clear/reset memory for a fresh start, or toggle auto memory on/off.

Quick Tips That Save Context

/btw: ask a side question without adding to conversation history. The answer appears in a dismissible overlay and never enters context. Use while Claude Code is working to check a detail without derailing the task. Note: /btw has no tool access. Claude Code answers only from what's already in context, so it can't read new files or run commands to answer your question.

@file: reference files directly with @src/auth/middleware.ts. Claude Code resolves it instantly instead of searching the codebase. Saves tokens and gives Claude Code exactly the context you want.

2 failed corrections → /clear. If you've corrected Claude Code twice and it's still off, don't correct a third time. /clear and write a new prompt incorporating what you learned. Continuing a broken thread multiplies confusion.


The Complete Daily Flow

Here's how everything from Parts 1-3 connects into a typical work session:

SESSION START
/contextcheck the gauge
/resume or /clearcontinue or fresh start
BEFORE A TASK
Shift+Tabenter plan mode
/effort highif task is complex
Describe taskreview the plan
Approveswitch to auto-accept
DURING IMPLEMENTATION
!any cli commandinject live output
/contextwhen session feels heavy
BETWEEN PHASES
/compacttrim noise, keep task
/diffreview changes so far
BEFORE COMMIT
/difffinal review
/simplifycatch redundancies
/diffverify simplify changes
Review promptstructured analysis
Fix issuescommit → /clear

This is the workflow. Parts 1 and 2 gave you the building blocks. This is how they fit together.


Common Workflow Recipes

Starting a new feature

/clear
Shift+Tab (plan mode)
"I need to add [feature]. Don't change anything yet. Explore and propose a plan."
→ Review plan → Approve
→ Implementation with /compact between phases
→ /diff + /simplify + /diff + review before commit
→ Commit → /clear

Debugging a bug

/clear
/effort high
"Users are getting 500 errors on the checkout page.
Here's the stack trace: [paste].
Don't fix anything yet. Give me 3 hypotheses."

Claude Code responds:

Hypothesis 1 (most likely): Cart service doesn't handle
  empty discount array, null reference at line 42.
Hypothesis 2: Stripe API key expired in production env.
Hypothesis 3: Database connection timeout under load.

Which should I investigate first?

You pick hypothesis 1:

"Investigate hypothesis 1. Search the cart service for
null handling on discounts."
→ Claude Code finds the bug, proposes minimal fix
→ /compact (drop investigation noise, keep the fix)
→ Fix → test → /diff → commit → /clear

Quick fix (single file, obvious change)

"Fix [specific thing] in [specific file]"
→ Review diff in conversation (no /diff needed for tiny changes)
→ Commit → /clear

Not every task needs the full workflow. Quick fixes stay quick.


Safety Valves

When things go wrong mid-session:

  • Ctrl+C: stops Claude Code mid-response. Use the moment you see it heading in the wrong direction.
  • Escape + Escape: when the prompt is empty, opens the rewind menu with options to restore code, conversation, or both to a previous point. You can also summarize from a selected message. Useful for undoing Claude Code's changes when an approach doesn't work out. (With text in the prompt, Escape+Escape clears the draft instead.)

The One Rule

The workflow is: plan → build → review → commit → clear.

Plan mode gives you control. /compact keeps context clean between phases. /diff → /simplify → /diff → review catches issues before commit. /clear resets for the next task. The rest of the series adds specific tools to that loop; the loop itself is the thing.

This lesson is from the Claude Code Field Guide, a free companion to Claude and the Code. The book teaches the thinking behind the commands.

You've completed 3 of 6 lessons.

Want the complete methodology?

The Field Guide teaches commands. The book teaches thinking.