Use Plan Mode to Think Through Complex Tasks Before Making Any Changes
When a task is complex enough that you'd want to think before coding, Claude should too. Plan mode makes Claude research, analyze, and propose an approach — without editing files or running commands — so you can review the strategy before any code changes happen.
> /plan refactor the authentication system to use JWT tokens instead of session cookies
Claude reads through your codebase, identifies every file involved, maps out the dependencies, and presents a structured plan: which files to change, in what order, what new code to write, and what tests to update. No files get touched until you approve.
You can also toggle plan mode on and off during a conversation using Shift+Tab:
[Shift+Tab to enter plan mode]
> how should we restructure the database schema to support multi-tenancy?
Claude analyzes the codebase and proposes a migration strategy...
[Shift+Tab to exit plan mode]
> ok, execute step 1 of the plan
This two-phase workflow — plan then execute — prevents the most expensive kind of mistake: Claude confidently making sweeping changes in the wrong direction. With a plan, you catch bad assumptions before they become bad code.
Plan mode is especially valuable for:
- Architectural changes — moving to a new pattern, restructuring directories, changing how modules communicate
- Multi-file refactors — when changes cascade across many files and the order matters
- Unfamiliar codebases — let Claude explore and map the territory before making changes
- Risky operations — database migrations, API contract changes, anything hard to undo
Once you approve the plan, Claude executes it step by step, and you can interrupt or adjust at any point.
Plan first, code second — the five minutes you spend reviewing a plan can save hours of undoing the wrong approach.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.