Docs / design-first

Design-first: approve mockups before code

A big UI prompt can open with mockups instead of code. You pick the screens, review what the AI draws, then approve.

Approved mockups become the contract for the build: every run that follows is told to match them rather than invent its own layout.

Starting a design

There are two ways in:

  • Tick Design first. The checkbox sits beside Generate. It forces the design step for that message however short the prompt is. Ticking it disables Ask first on the same message.
  • Let it happen. A broad, UI-facing prompt — a new app, or a new module with its own screens — routes into a design on its own. Backend-only work, refactors, bug fixes, questions and small tweaks never do.

The mockups follow the target chip beside the composer: Web screens are drawn at a desktop viewport (about 1280px wide), Mobile screens at a phone viewport (412×892).

Choosing which screens to draw

The run pauses at Choose screens with the AI's proposal — a checklist with Select all and Clear all.

Screens you named in your prompt start ticked; the rest start unticked, so a broad idea does not quietly become a bill for seven mockups. If your prompt named none of them — "buatkan dashboard admin" names no screen — the whole proposal starts ticked instead, because clearing seven boxes by hand is worse than the alternative. Tick anything the AI suggested that you also want.

Under the list a line reads 4 screens selected · ≈4 credits estimated, metered from actual usage. That figure is an estimate, not a price. Drawing the mockups is one run, and it settles from the tokens it really used — see how credits work.

A round draws at most 10 screens. Skip design drops the mockups entirely and builds straight from your prompt, at no extra cost.

Watching the AI draw

The center panel switches to its Design tab and stays there for the run. Screens appear one at a time as the AI writes them, with a 3/6 screens counter and a queue of the ones still to come.

You can switch back to Preview at any point; the run carries on either way.

Reviewing and revising

When the run finishes, the status badge reads Awaiting design review and the tab shows the gallery: Design v1 plus the screen count. Click any mockup to open it fullscreen and step through the set.

To change something, type it in the chat. While a design is awaiting review the composer becomes the revision channel — your message does not start a parallel build, it queues Design v2. A revision is a new run and is charged like any other, metered from its own tokens. The previous version is marked superseded, so only one design is ever actionable.

Approving

Approve & continue sits in the Design tab. Approving is free and re-uses the same run: the AI reads the approved screens and comes back with either a plan to review or a single build run.

After that the mockups turn read-only, and the panel says so — they are the UI contract the build follows.

Exporting the mockups

PNG downloads the screen you have selected. PDF downloads every screen as one file, a page each. Both work while you are reviewing and after you approve.

Export runs in your browser, on the same engine that painted the preview. A screen that reaches for an external image or web font — which the design rules forbid — can lose it in the export while still showing it on screen, and an older browser can fail outright. The raw .html files stay in your project, so exporting the source is always the fallback.

Limits & notes

  • Mockups are static HTML: no JavaScript, no live data. They show the layout, not a working app.
  • At most 10 screens per round.
  • Screen counts are estimates. Each design round and each revision is a run, metered from its tokens.
  • Approving costs nothing, and skipping the design costs nothing extra.
  • Both pauses — Choose screens and Awaiting design review — expire after 60 minutes. Past that the run is cancelled and you send the prompt again.
  • Ticking Design first disables Ask first on the same message.
  • Limits may change during alpha.