Shift+Tab — Plan mode

What it does

Plan mode (Shift+Tab or /enter-plan) puts you in a structured planning phase where you sketch out an implementation strategy before writing code. While in plan mode, you can't edit files or run destructive Git commands — the tool harness blocks them. Plan mode forces explicit decision-making: you design the approach, get user sign-off, and only then exit into implementation. It's a circuit breaker that prevents you from building the wrong thing.

When to use it

Enter plan mode for any task that requires more than two files to change, or whenever the right approach isn't obvious. Examples: "add a new payment flow", "refactor authentication", "merge three semi-related bugs into one solution", "build a feature with architectural tradeoffs". Use it when the user asks a design question ("how should we approach X?", "what's the right pattern here?"). Also use it preemptively when you notice yourself starting to code without a mental model — pause, enter plan mode, think aloud, and propose a concrete strategy before touching files.

For small, routine tasks (fixing a typo, adjusting a colour token, a one-liner bug fix), plan mode is overkill — just implement and ask to commit.

Try it yourself

Press Shift+Tab in the terminal or type /enter-plan to see what a structured planning phase looks like. You'll be in a mode where you can ask the user clarifying questions, propose multiple approaches, and get feedback before committing to an implementation. Once the plan is solid, exit plan mode with ExitPlanMode and implement it.

Gotchas

Plan mode is not a promise. Proposing a 10-step plan doesn't mean you must follow all 10 steps — plans change as you discover edge cases. If you're mid-implementation and realize the approach won't work, exit plan mode, explain the blocker to the user, and ask whether to revise. The discipline is thinking first, not rigid adherence.

Don't ask permission to plan. If a task is genuinely complex and you haven't drafted an approach yet, enter plan mode without asking. The user can always say "skip the plan, just build it" — but at least you'll have thought through the problem.

Exit promptly. Once the user approves a plan, call ExitPlanMode immediately and implement. Don't use plan mode as a procrastination shelter. The longer you stay in, the more likely the plan becomes stale or the user gets impatient.

Use it for user-facing decisions, not code cleanup. Plan mode is for "which architecture?", "what files should exist?", "should we refactor this?". It's not for deciding between variable names — that's in-band implementation detail and slows you down if you're already confident about the approach.