Plan - see the plan first

Sometimes the risk in a task is not the typing, it is the approach. Change a function that only your own service calls, and a wrong shape costs you a refactor. Change a function that a dozen services import, and the wrong shape is a breaking change every one of them inherits. For the second kind of work, you want the approach laid out where you can push back on it while it is still a paragraph - before it is a diff spread across the repository. That is the Plan role.

A stop sign before the code

Plan is a built-in entry in the agents dropdown - the role picker in the Chat view. You describe the work; it researches the codebase and produces a structured, step-by-step implementation plan - and stops there. No edits yet. (Plan’s stop-then-approve behavior is stated as of September 2026; the planning documentation tracks the current surface.) You read the intended approach, push back where it is wrong, and when it holds up, approve the plan - Start Implementation, in the current UI - which continues the work in Agent with the conversation carried over, so the building starts from the approach you actually agreed to.

The value is not the plan document itself. It is the review point the plan creates at the moment when decisions are cheapest to change. Catching “you are about to alter a function twelve services call - add a new one instead” while it is a bullet point costs a sentence. Catching it after the change is woven through the codebase costs an afternoon of re-review.

What to interrogate in a plan

Say the task is a change to a shared library - in this course’s illustrative scenario, shared-lib, the internal library a dozen services import: add a configurable approval threshold and a new audit-event type without breaking the dozen existing consumers. Nothing is built yet; this is the library change the previous lessons drilled or assumed. The request to Plan is direct:

Plan how to add a configurable approval threshold and a new audit-event type to shared-lib without breaking existing consumers. I want to review the approach before any code changes.

What comes back is an approach you can interrogate before it is real. The questions that matter on shared-code work:

• Does it preserve compatibility? Is it adding new surface or changing surface consumers depend on? On this kind of change, that single question is what the plan lives or dies by.
• Is the sequencing sane? Library change, then version bump, then consumer adoption - in an order that never leaves downstream services broken in between.
• Did it miss anything? A migration note, a config default, the consumers that need updating. Adding a step now is cheap; discovering the gap mid-build is not.

Push back where the answers are wrong, and approve only when the approach is right. The building then happens with your context intact, whether you hand the approved plan to Agent immediately or come back to it - the conversation persists in your session history, so a delayed build keeps the plan’s context.

Plan as the gate in front of Agent

Plan reframes the other built-in roles rather than sitting beside them. Ask understands; Agent builds; Plan is the gate you put in front of Agent when the approach is too consequential to leave unreviewed. That gate is a control decision in this course’s sense - control being what guides execution and enforces boundaries - and the decision it governs is how much happens before you look. The rhythm that emerges on serious work is the one this chapter’s index states: ask to understand, plan to agree the approach, let Agent build - and because switching roles carries the conversation forward (as of September 2026), it is one continuous piece of work, the latitude you grant - how much of the work the agent does before you look - widening only as your confidence does.

Knowing the three roles is table stakes, though. The skill is reading a task that lands on your desk and knowing which one it is asking for - and that judgment is specific enough to have its own page. Next: Switch - match the role to the risk.