Plan: clarify, research, then a plan you can edit

Plan is the posture for a change big enough that letting Agent start editing on its first instinct is how you get a confident rewrite of the wrong thing. Instead of jumping to edits, Plan runs a deliberate sequence before a single line is written.

The flow:

1. It asks clarifying questions. Plan doesn’t assume the spec; it pulls the ambiguity out of you first.
2. It researches the codebase - read-only. It reads and greps to ground the plan in the real code, without touching anything.
3. It writes the plan as an editable markdown file. Not a chat message you skim and lose - a .md artifact you can open, argue with, and rewrite.
4. You edit the plan inline, then click to build from it.

plan ›
> add a second-approver requirement: transactions above a configurable
  threshold can't post until a second user approves them.

  Before I plan this, a few questions:
  • Should the threshold be per-org or global?
  • Does "approve" need an audit record, or just a status flip?
  • Is the second approver any user, or a specific role?

> per-org threshold; yes, every approval must be audited; second
  approver must hold the "budget-admin" role.

  ⏵ Read  src/budget/guard.ts, src/budget-policy/policy.ts,
          src/audit/log.ts, src/models/transaction.ts       (gathering context)

  Wrote plan to second-approver-plan.md:
    1. Add perOrgThreshold to budget-policy (shared package - bump
       minor, coordinate the six importers).
    2. Add an Approval record + audit entry in src/audit/log.ts.
    3. Gate guard.ts on role "budget-admin".
    4. Migration for the transaction approval-state column.
  Edit the plan, then build when you're ready.

Two things in that transcript are the whole reason Plan exists. The clarifying turn caught three decisions you’d otherwise have discovered as bugs. And the research stage is about gathering context, not shipping changes - it reads and greps your actual code to ground the plan, and the only artifact it produces is the plan itself.

Where the plan is saved

Plans are saved by default in your home directory - it’s yours, a personal artifact, not part of the repo. When you want the plan in the repo so teammates (or a PR) can see it, click “Save to workspace”, which moves it into the project.

Plan with one model, build with another

The detail that makes Plan more than a speed bump, shipped in Cursor 2.0: you can create your plan with one model and build it with another. Point a frontier reasoning model at the design - where the cost of a bad call is highest - and then hand the approved, written-down plan to a faster, cheaper model to execute. The plan is a markdown artifact, so the second model doesn’t need the first model’s reasoning context; it needs the plan, which is sitting right there.

This is also where the blast-radius rule from the last two lessons pays off. The second-approver feature above touches the shared budget-policy package six services import - high blast radius, easy to get subtly wrong, expensive to undo. That’s precisely the task that earns the clarify-research-plan ceremony. The self-contained retry fix you handed to Agent did not. Difficulty isn’t the signal; who a mistake hurts, and how hard it is to reverse is.

Try it

Switch to Plan mode and describe a change that touches three files. Read the plan, argue with one step, then let it execute. Compare the result to what you’d have gotten by jumping straight to Agent mode.

Ask, Agent, and a Plan posture all take the same shape: you’re about to change something, and the only question is how much rope you hand over first. A Debug posture is different - it exists for the case where the change already happened and broke something. Next: Debug, a custom debugging posture.