Cursor Plan Mode: A Pasteable Prompt That Forces a Verifiable Plan

What Cursor Plan Mode Actually Changes

Cursor Plan Mode is an agent mode — toggled with Shift+Tab — that makes Cursor research the codebase, ask clarifying questions, and write a structured plan before it touches any code. You review the plan, edit the to-dos, then the agent builds from it. Cursor says most of its own new features now start with the agent writing a plan, which tells you something about where the real payoff sits.

Cursor's Plan Mode announcement describes the feature and the four-step flow. Its agent best practices post says planning first is "the most impactful change you can make." Both are right, and both stop at the feature. Neither hands you the prompt that makes the plan good. You press Shift+Tab and hope the agent's default planning instinct is enough.

Why a Default Plan Drifts

Plan Mode without a planning contract produces a plan shaped by whatever the agent inferred from a short ask. Sometimes that's fine. On a real feature it tends to drift: steps that aren't ordered, steps that can't be verified independently, a "refactor the service layer" item that's really five items in a trench coat.

The fix isn't a longer description of the feature. It's a contract for what a step is. A good plan has steps that each change one thing, name the files they touch, and carry a check that says how you'd know the step worked. That structure is what lets you run steps one at a time and catch a wrong turn at step two instead of step nine.

The Planning Contract a Prompt Enforces

A planning prompt you paste into Plan Mode (or any agent's planning step) forces the plan into a fixed shape:

• Goal restatement. One line: what done looks like. If the agent can't state it crisply, the ask was too vague, and that surfaces now, not after the build.
• Ordered steps. Each step changes one thing, in dependency order, so step N never needs something step N+2 hasn't built yet.
• Files per step. The concrete paths each step touches, so you can spot a step that's secretly a refactor of half the repo.
• A verification check per step. How you'd confirm the step worked: a test to run, an output to see, a behavior to click through.
• Open questions. What the agent is unsure about, asked before it builds, not assumed silently.

That per-step verification check is the line most plans omit and the one that makes the plan executable.

Clarifying Questions Are a Feature, Not a Delay

Plan Mode asks clarifying questions before it plans, and the instinct is to rush past them. Resist it. Those questions are the agent telling you where your ask was ambiguous, and answering them now is far cheaper than discovering the ambiguity in a half-built diff. A question like "should this reuse the existing auth middleware or add a new guard?" is the agent surfacing a fork you hadn't decided. Decide it.

The questions also improve the plan's structure, not just its content. When the agent knows the constraint, it can order steps around it and write a verification check that actually tests the right thing. Skip the questions and the agent guesses, which means the plan encodes a guess you'll have to unwind.

A good planning prompt leans into this: it tells the agent to ask before assuming, and to list any assumption it had to make anyway as an open question. That turns silent guesses into visible ones. You'd rather see "assumed Postgres, not MySQL" in the plan than find it in the migration.

How to Use the Planning Prompt, Step by Step

1. Toggle Plan Mode

Shift+Tab in the agent input. Let the agent read the codebase first.

2. Paste the planning contract

Give it {{goal}} (what you want) and {{constraints}} (the stack, the boundaries, what not to touch). The prompt makes it produce the contract above instead of a freeform list.

3. Review the plan, not just the code

Read the ordered steps and their verification checks. A weak plan is cheap to fix here and expensive to fix after the diff lands.

4. Execute incrementally

Run steps one at a time or in small groups. Verify each before the next. Faster agents make this more important, not less. Speed without review just produces wrong code sooner.

One Opinion: Review the Plan Harder Than the Code

Here's a stance that runs against the reflex. Everyone says review the AI's code, and you should. But the review that pays off more is the plan. A bad line of code is a five-minute fix. A bad plan (wrong ordering, a step that bundles three concerns, a missing verification) costs you the whole build plus the untangling.

AI-generated code can look right while being subtly wrong, and the same is true of plans, except a wrong plan is harder to spot because it reads as reasonable. Spend your scrutiny upstream. A plan with a verification check per step is a plan you can hold accountable; a plan that's just an ordered wish list isn't. This is the same discipline behind task decomposition for coding agents — the contract is on the step, not the prose.

Variables You'll Set

Getting Started

1. Toggle Plan Mode with Shift+Tab.
2. Write {{goal}} as a crisp definition of done.
3. Paste a planning prompt that enforces ordered steps with a verification check each.
4. Review the plan's structure before approving it.
5. Execute steps incrementally, verifying each diff as it lands.

For the planning prompt itself, the Agent Task Decomposition System Prompt turns a {{goal}} into ordered, independently-verifiable subtasks with a per-step contract — the exact shape Plan Mode rewards. If the work starts from a written spec, the Spec-to-Code Harness carries it from spec to ordered, buildable code.

Why the contract makes Plan Mode worth it

Plan Mode's value is the chance to catch a wrong approach before the agent commits to it. That chance is only real if the plan is structured enough to evaluate. A contract that forces ordered steps, named files, and a check per step turns "looks reasonable" into "this is verifiable," which is the difference between a review and a rubber stamp. The feature gives you the moment; the prompt makes the moment useful.

Plan Mode is the right idea with a missing piece: a contract for what a plan is. Force ordered, verifiable steps, review the plan harder than the code, and execute one step at a time. For the related agent setups, see spec-driven development prompts for agents and Cursor vs Copilot for refactoring.