Modulify
Dashboard

Plan and Build modes

The two chat modes, what actually changes between them, and how a plan gets approved.

On this page

Every message runs in one of two modes. Build carries the request out. Plan works out what it would do, shows you, and stops without touching a file.

Switch mode

The mode picker sits at the bottom of the chat box, between the + button and the model picker, showing the current mode's name and icon. Click it for a menu headed Mode with both options and the one line each carries there:

Mode The menu reads
Build Makes the changes right away
Plan Proposes an approach first

The choice sticks until you change it again. A new project starts in Build.

Mode belongs to the project

Mode is not a personal preference. It is stored on the project and pushed straight to everyone else who has it open, so switching to Plan switches it for your teammates too and their picker updates without a refresh.

The transcript records the change so nobody is left wondering why their message behaved differently. A divider appears reading Switched to Plan mode or Switched to Build mode.

What Build does

Build is the default and the right choice for most messages. The request is carried out directly, files change as the run goes, and the preview picks them up.

Build also repairs itself. When a change it makes leaves a runtime error in the preview, the same run notices and fixes it. Plan mode does not do this, because it is not changing anything that could break.

What Plan does

A Plan run investigates before it proposes. It opens the pages, components and config your request actually touches instead of guessing at a file it has not read, and it will not propose a change to a file it never opened. Broad requests get a broader look, enough to know where the work lands.

Then it writes the plan as ordinary prose: a short heading and a numbered list of steps, each saying what changes and where, naming real files and components. The length matches the change, so a copy tweak is two lines and a new page with a form is a dozen.

The plan is written to tell you what you cannot see for yourself:

  • which files it will create, and which it will edit
  • anything already there that will be replaced or removed
  • parts of the site affected beyond the obvious ones
  • the judgement calls it had to make where your request could be read two ways, and which reading it took

It does not restate your request back at you, narrate its own investigation, or list the alternatives it rejected. If something genuinely blocks it, it asks instead of guessing.

Approve a plan

When the plan is ready the run ends and a card appears at the bottom of the transcript reading The plan is ready. Nothing has been changed yet. Under it sits one button, Approve and build.

Pressing it does three things in order. It switches the project to Build mode, posts Approved. Build the plan. to the chat as a message from you, and starts the run. From there it behaves like any other Build message.

Adjust a plan

There is no adjust button. Reply in the chat box with what you want different and the plan gets revised, then presented again with a fresh approval card.

Sending any message while a plan is waiting retires the card, which collapses into an Approval requested divider in the transcript. A plan you have already replied to cannot be approved later by accident.

Reject a plan

There is no reject button either, because nothing has happened that needs undoing. A plan you do not want is a plan you leave unapproved. Switch the picker back to Build and send whatever you want instead.

The queue waits on you

A plan waiting for approval holds the message queue. It does not hold you: type in the composer with the queue empty and your message runs straight away, which is how you adjust or refuse a plan. What the hold stops is the queue draining, so a message that does get queued waits, with Your message was queued because a plan is waiting for approval. The queue drains on its own the moment you approve, so this hold has no resume button.

Each queued message also remembers the mode it was written in, so one queued in Plan still plans when its turn comes round, whatever the picker says by then.

When Plan is not available

Plan mode needs support from the preview environment the project is running on. If the preview is not there yet, the message comes back as an amber warning titled Plan mode is not supported with the code SC-3003, reading Plan mode is not ready on this preview yet. Switch to Build mode in the chat box to continue. Restarting the preview clears it, and so does switching to Build.

Which to use

Build when you could describe the change in a sentence and you would recognise a wrong result the moment you saw it. That covers most work, and reading a plan for a copy change costs more than redoing the copy change.

Plan when the change is large, when it spans several pages at once, when you are not certain your request reads only one way, or when you want to know what is going to be removed before it is removed. Reading a plan is faster than restoring a version.

Next