Overview
The design system is two things, handed to a coding agent together:
| File | What it is | How to use it |
|---|---|---|
| design.md | The spec as a single DESIGN.md-format file: tokens, component specs, design intent, a contract for agents at the top and a self-check at the end | Put it in the project and have the agent read it first |
| Five layout templates | One per generator layout, each in two HTML files: a skeleton (structure + stylesheet) and a runnable one (behaviour inlined as well) | Read the skeleton and copy it into your project; take the runnable one to see the example work |
The pages below are written for people — the same tokens and components, with demos you can touch. Changes happen in one place: design.md is the single source of truth, and the docs pages and templates follow it.
Why templates, not descriptions
There used to be a written spec only. The same file handed to different agents produced good UI one day and poor UI the next, because every agent was rebuilding the 28px input, the property-card header row and the select's keyboard contract from prose, and rebuilding always varies. The agent's job is now reuse: the template already has the right skeleton, components and behaviour, so the work left is content and whatever your generator adds on top. That is what makes the output steady.
A template is deliberately one file: no second stylesheet or script to copy alongside it, no relative path to get right, and double-clicking it runs it in a browser.
Skeleton, skin and behaviour
The spec has three layers, and the contract section of design.md keeps them apart:
- Skeleton — must match: the five layouts and their region widths, where the tabs / Fabrication Tips / zoom / export sit, control heights (24 / 28 / 32 / 40), radii (4 / 6 / 8 / 12), the closed state set, the keyboard and screen-reader contract each control owes, and every platform constraint. All of it is judged on what renders — the framework, the tags and the class names are yours.
- Skin — default, replaceable: every colour value and the type sizes. The values shipped here come from the platform's own token export, so they match its surfaces; you may bring your own neutrals and accent as long as the result stays light, text that carries meaning clears 4.5:1, every control state stays distinct, and you change token values, never token names.
- Behaviour — yours: what the generator actually makes, which parameters it exposes, what Generate produces, how far zoom goes, what the history holds — none of it is specified. The runnable templates answer these one way so the example runs; treat those answers as a demo, not a requirement.
Review checks two things: the skeleton — the layouts, widths, control sizes and behaviour listed above — and the platform constraints: export goes through the platform button, the generator uses only the region it is given, the exported file is 1:1 actual size. The skin is advice.
A workbench, not a storefront
The reference for a generator is the properties panel of a professional creative tool: quiet chrome, dense enough to work in, never decorated. Whoever is using it will run the same generator twenty times in an afternoon, changing one value each time. At that repetition rate the value of the interface is its predictability: controls stay in the same place, values stay legible, and the twentieth transition looks exactly like the first.
A real slice of the parameters rail: white property cards standing on a bg-subtlest panel, header rows at 12 / 500, field rows at 12 / 400, grey-filled borderless 28px inputs aligned to the end edge. Click a header to collapse the card, drag the slider and the value follows — the spec describes controls in every state, and you only really understand a state you can touch.
What it is not: not a marketing page, not a dashboard, not a consumer app. No hero moment, no gradients, no glass, no glow, no illustrated empty state, no entrance animation. Those belong to products that still have to convince you to stay. This one already has your attention.