Skip to main content
Plan mode exists to de-risk a feature before you write code. It helps you agree on scope, surface gaps early, and leave with a clear sequence of work and checks.

​
Why use Plan mode

  • You want alignment on goals, outcomes, and risks before building.
  • You need a concise spec that explains what changes, why it matters, and how success will be verified.
  • You prefer to catch ambiguities or design concerns upfront instead of mid-implementation.
  • You’d like the assistant to keep you honest with structured reviews and follow-up questions.

​
How to start

  1. In the chat dock, choose Quick starts → Plan to open a planning chat.
  2. Describe the feature in plain language: the goal, who it serves, platforms, constraints, and any files you think matter.
  3. Answer the short clarification prompts so the assistant can lock scope before drafting.

​
How the assistant engages

  • Stays in planning mode (no code edits) and asks targeted questions until the scope is crisp.
  • Pulls in context from your repo or external references when needed to ground decisions.
  • Drafts a structured Markdown plan with Overview, Intent, Goals, Outcomes, Context, and Implementation phases that each include details, implications, and verification steps.
  • Runs plan and design reviews when relevant so the draft tightens before you build.

​
What you can do with the plan

  • Use it as your single source of truth while you implement.
  • Ask the assistant to kick off work from the first implementation phase and follow the sequence.
  • Keep referring to the plan in future chats so guidance stays anchored to the agreed scope.

​
Evaluate and iterate

  • Highlight any part of the plan and click Ask in chat to question risks, missing tests, or edge cases without losing your place.
  • Ask the assistant to rerun reviews after edits, or to sharpen verification and success checks if something feels vague.
  • Drop related files or screenshots into the chat when you probe a section—the assistant will fold that context back into the plan.

​
What goes behind the scenes

  • What happens: The assistant stays in a planning-only lane with a tight toolset, steering the conversation toward clarity instead of code changes.
  • Why it helps: fewer distractions and faster convergence on scope, goals, and risks.
  • What happens: Your plan lives in one place and every edit builds on that version.
  • Why it helps: everyone reviews the same source of truth, and changes stay obvious so you iterate confidently.
  • What happens: A dedicated reviewer looks only at the plan and its changes, returning one buffered response per pass.
  • Why it helps: concentrated feedback with no tool chatter keeps the loop short and the critique coherent.
  • What happens: UI/UX feedback runs through its own reviewer that builds on prior design notes.
  • Why it helps: design quality improves without repeating context, and the plan gains clear experience checkpoints.
  • What happens: After reviews, the plan remains the guide for workstreams and next steps.
  • Why it helps: a reviewed, stable plan reduces rework and keeps momentum when you start building.