Cursor Plan Mode: Review a Plan Before the Agent Codes

Plan Mode separates deciding 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. Press Shift+Tab in the chat input to rotate into it. Cursor also suggests it automatically when you type keywords that signal a complex task.

What changes is what you review. 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. ends with a diff, and the question is whether the code is right. In Plan Mode you read a document before any code exists, so you can settle the approach while there is nothing to unwind.

The automatic suggestion keys off the words you type, so a short request that happens to be architectural can slip past it. When you know a task needs a plan, rotate in by hand instead of waiting for the suggestion.

Cursor's documented sequence ends with you: nothing is built until you click.

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.

The order 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, and by then the tokens are spent.

So give the clarifying questions full answers. A two-word reply gives the agent nothing to push back on, and the research in step two can go looking for the wrong thing. The plan that comes back is then 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, not for whether the steps sound sensible, because the steps almost always do. 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 we suggest changing at least one line before you build, even if the change is deleting a step you don't need. Picking a line to change makes you read the whole plan first.

If you agree with every line of a plan straight away, that usually means the task was small enough to skip 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 chat threads don't. A chat thread reads as a record of a moment. A markdown file in the repo looks like current documentation, and six months later someone reads it as the design. On a two-person team the default location is usually enough, because the pull request can carry the intent. Once a reviewer reads the plan before the diff, save it to the workspace and delete it when it stops being true.

Reach for Plan Mode when the approach isn't obvious. Cursor names four cases where it works best. For quick changes or tasks you have done many times, going 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.

Unclear requirements is the odd one out. The other three describe big or many-sided work, but a small task can have unclear requirements too. For that kind of task, the plan is how you find out the size of the job.

Our own test is narrower than the list. Can you name the files this task will touch? If you can, a plan mostly restates a decision you have already made, and the same minutes go further on @-mentioning those files and writing the success condition into the prompt. If you can't, that gap is what the plan is for.

When the result misses what you wanted, Cursor recommends going back to the plan instead of patching the code with follow-up prompts. Revert the changes, make the plan more specific, and run it again. Cursor says this is often faster than fixing an in-progress agent, and that it produces cleaner results.

The advice is hard to follow in the moment. Reverting throws away a diff that is mostly right, and one more prompt looks cheaper than a second full run. But patching costs you the plan. Each follow-up edits code the plan never described, so after a few of them the plan and the repo disagree, and you have lost the document you meant to review against.

Before you rewrite anything, reread the plan you approved. It is often vague at exactly the point where the output went wrong. When it is, add the missing sentence to the plan and build from it again.

Cursor documents two ways to change modes, one for the mouse and one for the keyboard.

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

Shift+Tab rotates through the modes instead of toggling one, so it is easy to overshoot at speed. The dropdown names what you are choosing, which makes it the safer choice while the order is unfamiliar. 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., Shift+Tab also rotates modes, through Agent, Plan and Ask. Auto-approval is a separate setting there, so the shortcut doesn't change what runs without asking.