Guide
Editing and iterating
The first build is a starting point, not a final answer. Most good sites come out of four or five rounds of small corrections. This page explains how editing works, what the two modes are for, and how to get out of trouble when a change goes the wrong way.
Targeted edits
When you send a message after a build exists, the agent loads the current files, decides which of them your request touches, and rewrites only those. Sections you never mentioned are left exactly as they are. That is why "make the footer three columns" is safe, while "redo the whole thing but nicer" throws away work you may have liked.
Each edit appears in the activity checklist with the real file path, so you can see exactly what was touched. If the agent had to change something you did not ask about — a shared stylesheet, for instance — that file shows up too.
Plan mode and Build mode
| Mode | What it does | When to use it |
|---|---|---|
| Build | Goes straight to writing files after any necessary clarifying questions. | Small changes, and first drafts where you want something to react to. |
| Plan | Returns a written plan of pages, sections, and data. Nothing is written until you approve. | Multi-page sites, restructures, and anything where a wrong turn is expensive. |
A plan can be sent back for changes as many times as you like before you approve it. Once approved, the build follows it step by step and you can compare the checklist against the plan you agreed to.
Reading the activity checklist
Every line in the checklist corresponds to a real server event. Nothing is simulated to make the wait feel productive.
- Pulsing — the step is running right now.
- Ticked — the step finished successfully.
- Red — the step failed, with the underlying error shown inline.
- Grouped rows — file operations collapse under a heading; expand to see each path.
If a build stops with a red step, the message tells you whether the problem was the model, the provider, your key, or the content of the request. Those four have very different fixes.
Working across projects
- The project name sits at the top of the workspace. Click it to slide open the project list.
- Switch between projects there, or create a new one without leaving the page.
- Your remaining credits are shown in the same panel.
- Each project keeps its own chat history, files, and published state.
When a change goes wrong
Ask for the reverse
The fastest fix is usually a plain instruction: "put the previous hero back, with the photo on the right". The agent has the conversation history and can restore what it changed.
Use GitHub history
If the project is connected to GitHub with auto-sync on, every build is pushed as a commit. That gives you a full, ordinary version history and the ability to revert precisely.
Before a big restructure