Build mode turns the preview of an adopted codebase into a visual editor: click an element in your running app, change it on screen — text, spacing, color — and the change writes back into the real code on the 1design/<slug> branch. It's editing the UI where the UI lives.

Opening it

On a codebase project, the Build tab beside Preview and Sketch switches the panel into Build mode: your app renders live, and the edit layer activates on it. Hover highlights the element under the cursor; click selects it and opens its edit surface — the properties the element exposes, editable in place.

Build mode — the running app with an element selected for editing

Editing on screen

The edit surface covers the properties that make sense visually:

Text — click the copy, type the replacement
Spacing — padding and gap on the selected element
Color — the fill or text color, from the project's tokens
Type — size, weight, family on the text elements

Changes apply live to the preview — you see the edit where it lands, not in a property panel detached from the result.

Writing back to code

The visual edit isn't a mock overlay — it maps to the element's real styles and writes the change into the file that owns them, on the 1design/<slug> branch. The next turn or the next build reads it like any code change — the worktree diff grows by exactly the edit you made.

Adopt a repo, send a turn, the branch bar shows the commit ahead.

The diff-scoped check

Codebase projects verify the diff, not the whole codebase — the turn's (or the edit's) changed files get checked, and the branch bar's Review changes shows exactly what moved. A visual edit is a diff like any other — it lands on the branch, scoped to the files it touched.

Build vs Preview vs Sketch

Preview — look at the running app; steer with comments and pins
Build — edit the UI visually, changes write to code
Sketch — drop .1d sketches that map to components

Build mode is for the edit you can see — the button that should be bigger, the heading that should be tighter. When the change is a new flow or a multi-element reshuffle, the brief is still the tool.

Review and merge

Build-mode edits live on the same worktree branch as agent turns — the branch bar tracks the commits ahead, Review changes shows the diff the work produced, and Merge into main brings it back when it's right. The edit-to-code path is real, so the merge is a real merge.

What it's good at

Visual passes — spacing, color, type across a whole app, edited in place
Copy edits — fix the words on the screen itself
Token tuning — nudge a color or a size and watch it land in the code
The last mile — the polish pass where a brief is overkill

Tip: Build mode edits are code, so review the diff before merging — a visual tweak is honest code, but "looks right on screen" and "reads right in the file" are both worth checking before the branch merges.