Cursor Plan Mode: Review a Plan Before the Agent Codes

Plan Mode separates thinking from doing. Instead of editing files straight away, the agent investigates the task, writes a plan you can read, and waits for your go-ahead. You reach it by pressing Shift+Tab from the chat input to rotate modes, and Cursor suggests it automatically when you type keywords that signal a complex task.

What changes is the artifact you end up reading. Agent hands you a diff and the question is whether the code is right. Plan Mode hands you a document, and the question is whether the approach is right. You can answer that second question before there is anything to unwind.

The automatic suggestion keys off how you phrase the task, which means a short request that happens to be architectural can slip past it. Rotating in by hand does not depend on the phrasing, so there is not much reason to wait for the prompt.

The flow is the same each time: the agent narrows the requirements, gathers context, drafts a plan, hands it to you to edit, and only builds once you click. The steps below are Cursor's documented sequence.

1. 1The agent asks clarifying questions to understand your requirements.
2. 2It researches your codebase to gather the relevant context.
3. 3It creates a comprehensive implementation plan.
4. 4You review and edit the plan through chat or markdown files.
5. 5You click to build the plan when it is ready.

Reading down that list, the sequence puts the cheapest correction first. Answering a clarifying question costs you a sentence, and editing the plan costs a read. Reverting a finished build costs the revert plus a second run, by which point the tokens are already spent.

The clarifying questions are where this tends to go wrong, and not by being refused. They get a two-word answer, the agent has nothing to push back on, and the research in step two goes looking for the wrong thing. What comes back is a plan that is perfectly coherent about the wrong feature, which is harder to catch than an incoherent one.

Read the plan for the claims it makes about your repo rather than for whether the steps sound sensible. Steps almost always sound sensible. Open the two or three files it leans on hardest and confirm they are the ones you would have named.

A written plan reads as more settled than it is. You can edit it in chat or as a markdown file, and my habit is to change at least one line before building, even when the change is only deleting a step I do not need. Making an edit means reading the whole thing first.

If a plan comes back and you agree with every line of it straight away, that is usually a sign the task was small enough to have skipped planning.

Plans are saved in your home directory by default, and a "Save to workspace" button moves one into the repo. Whether to press it depends on who reads the plan after you do.

Committed plans go stale in a way that chat threads do not. A thread is obviously a record of a moment. A markdown file sitting in the repo looks like current documentation, and six months on somebody reads it as the design. On a two-person team the default location is probably fine and the pull request can carry the intent. Once a reviewer is reading the plan before they read the diff, save it into the workspace and treat it like any other doc that needs deleting when it stops being true.

Plan Mode earns its time on work where the approach is not obvious. Cursor calls out four cases where it helps most; for quick changes you have made many times, jumping straight to Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. is fine.

• Complex features with multiple valid approaches.
• Tasks that touch many files or systems.
• Unclear requirements where you need to explore before you understand the scope.
• Architectural decisions where you want to review the approach first.

Three of those four are about scope. Unclear requirements is the odd one out, because a task can be small and still qualify: the plan is how you find out how big the job actually is, rather than how you organize a job you already understand.

I used to treat those four as a checklist and rotate into Plan Mode whenever a task hit one. The test I use now is narrower. Can I name the files this will touch? When I can, the plan mostly restates a decision I had already made, and the same minutes go further into @-mentioning those files and writing the success condition into the prompt. When I cannot, that is the whole reason to plan.

When the result misses what you wanted, Cursor recommends going back to the plan rather than patching it with follow-up prompts. Revert the changes, make the plan more specific, and run it again. This is often faster than fixing an in-progress agent and tends to produce cleaner results.

That advice is harder to follow than it sounds, and not because of stubbornness. Reverting throws away a diff that is mostly right, and one more prompt always looks cheaper than a second full run. What the patching path quietly costs you is the plan. Each follow-up edits code the plan never described, so after three of them the plan and the repo disagree, and you have lost the document you were going to review against.

What I would check first, before rewriting anything, is the plan you approved. Usually it was vague at exactly the point where the output went wrong, and the fix is a sentence added to the plan rather than a better prompt.

There are two ways to change modes, both documented by Cursor.

• Use the mode picker dropdown in Agent.
• Press Shift+Tab for quick switching.

Shift+Tab rotates rather than toggles, so it passes the other modes on the way and overshooting is easy at speed. The dropdown names what you are choosing, which makes it the better one while the order is still unfamiliar. The same rotation exists in the Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition., where Shift+Tab steps through the run modes in the terminal.