Skip to main content

​
The order of a build

The assistant is told to build in this order, and the server nudges it back when it drifts:
  1. Read the site. get_design_system once. The site has a look already, seeded from its address, so two sites never start with the same bones.
  2. Write a direction. Five lines before touching anything: mood, palette with one accent, type pairing, one signature device, the hero opening.
  3. Design system. Colours, typography, the button style and hover animation, the look.
  4. Logo. From Brand assets, from the business’s website, or a generated wordmark.
  5. Header. From the canonical header recipe, with the menu items in the same call. A fresh menu is created and assigned.
  6. Pages. Each one added to the menu; the home page set as the front page.
  7. Footer. Built from scratch to the design. A build is not finished while the theme’s starter header or footer is still live, and every response says so until it is done.
A shop adds a product template and a product archive template, and rebuilds the Cart, Checkout and My account pages WooCommerce made.

​
Briefing the assistant

A short brief works. What helps most:
  • Who it is for and what they do. The industry picks the logo mark, the section shapes and the photography.
  • A reference, if you have one: a site you like, a screenshot, a Framer template. The assistant sets the look to reference and extracts its tokens.
  • The words. Real copy beats “lorem” every time; the assistant writes well from bullet points.
  • The files. Drop them into Brand assets first.
Example:
Build a site for Northline Roofing, a family roofing contractor in Leeds. Repairs, re-roofs, gutters, inspections. Warm and plain-spoken, no stock-photo gloss. Five pages: Home, Services, About, Reviews, Contact. Logo and photos are in Brand assets.

​
What the server does to every page

Before a page is saved, the rule engine:
  • repairs what it can: mobile twins for inline positions, hover colours for buttons whose colour was set, line-heights on sized card titles, padding on containers that paint a background, image crops to the slot’s real box with faces kept in frame, the light logo on dark surfaces, split panes around bare photos, gaps on split rows;
  • rejects what it cannot: fake navigation instead of the nav widget, flex_wrap, disallowed widgets, testimonial cards in the wrong shape, three centred card grids in a row, a hero without a visual device;
  • reports both, so the assistant learns the house rules in the first two pages.
The engine is idempotent: a page it has repaired comes back unchanged from a second pass, so an edit never drifts.

​
Reading and editing

The assistant reads a page as an outline (one line per band: title, surface, widgets, first heading), then one band, then edits with section operations: replace, insert before or after, append, remove. It passes the section count it read, and the edit is refused if the page changed in between.

​
Guides

The assistant reads the build rules once per conversation, then the cards for the widgets it is about to place, then the header and footer recipes. Everything is served in the smallest useful unit, and the compact rules are the default. A conversation starts at roughly 9,500 tokens of Bevel knowledge; the long documents are one call away.

​
Sessions

Each conversation gets a session. The rules gate and the one-time notes key on it: a new chat reads the rules again, and a long build is never blocked half-way. A client that does not echo the session falls back to the connection.