Designs
The look library users pick from. A design is content, not code — adding one puts it in the picker immediately, with no deploy.
/admin/designs is a small content management system for looks.
The looks users choose from when they build. Each design's instructions are injected into the builder's prompt, so apps stop converging on one house style. Content, not code — add a look and it appears in the picker immediately.
The problem it exists to solve: a model left to its own taste produces the same app every time — the same rounded buttons, the same spacing, the same gradient. A design is a written brief that overrides that.
What users see
On the dashboard, under the prompt box, a row of pills: Surprise me plus up to six designs, each with a two-colour swatch. Hovering shows the description.
Only active designs appear, and the instructions themselves are never sent to the browser — users see the name, the description and the swatch, and nothing else.
What ships
Eight designs in five categories, seeded on first start while the design table is empty.
Categories: Minimal (restrained, typographic, lots of air), Bold (high contrast, big type, saturated color), Editorial (magazine feel — serif headlines, measured columns), Playful (rounded, colorful, a little motion), Professional (calm, trustworthy, enterprise-ready).
Designs: Swiss Minimal, Terminal Mono (Minimal); Soft Brutalist, Midnight Glass (Bold); Broadsheet, Warm Boutique (Editorial); Candy Pop (Playful); Quiet Corporate (Professional).
The user-facing list, with descriptions, is in Designs.
The page
Category pills across the top: All (N) first, then one per category. Hovering a category pill reveals a small delete button.
A grid of cards, each with a gradient swatch, the design's name, a badge for its category — or Uncategorised — and its description. Below: a switch reading Live or Hidden, and a delete button. Hidden designs are dimmed.
Empty for a filter: No designs in this category yet.
Adding or editing a design
New design, or click a card's name.
The instructions are what the builder actually follows. Be specific about palette, type, spacing and component treatment — vague guidance produces the generic look.
| Field | What it does |
|---|---|
| Name | Required. Shown on the picker pill. |
| Category | Optional. The first option is Uncategorised. |
| Description | One line, shown on the picker card. |
| Swatch from / Swatch to | Two colours making the card's gradient. A colour picker and a text box each, with a live preview. Defaults are #e5e5e5 and #111111. |
| Search tags | Comma-separated keywords, e.g. dark, editorial, serif. Matched by the picker's filter box. |
| Design instructions | Required. The brief the builder follows. |
There is no preview image. The two-colour swatch is the preview, deliberately — it means adding a design needs no screenshot pipeline.
Save design is disabled until both the name and the instructions are filled in. The refusals are A name is required. and Design instructions are required — this is what the builder follows.
Writing the instructions
The instructions field is prefilled with the shape to follow — five labelled lines:
Palette: …
Typography: …
Layout: …
Components: …
Motion: …
Swiss Minimal's, as an example of the level of detail that works:
Palette: white background (#fff), near-black text (#111), one accent used sparingly (#1d4ed8). Borders #e5e5e5. No gradients, no shadows beyond a hairline border. Typography: system sans throughout. Hero 48–64px, tight tracking (-0.02em), weight 600. Layout: strict 12-column feel with a max-width of 1100px. Sections separated by 96px. Components: buttons are rectangles with a 4px radius. Cards are bordered, never shadowed. Motion: none beyond a 150ms colour transition on hover.
Named colours, named sizes, named durations. That specificity is the whole point — "make it modern" produces exactly the generic look the library exists to avoid.
Say what not to do as well as what to do. "No gradients, no shadows" is doing as much work there as anything else.
How it reaches a build
When a run starts, the design on the project is looked up and used only if it is still active. It is injected into the system prompt before the skills:
## Design direction — <name>
The user chose this look. Follow it over your own defaults, and keep it
consistent across every screen you touch.
<the instructions>
A design changed on a project applies to the next build, not to the app already written.
Hiding and deleting
Hidden takes a design out of the picker without removing it. Projects pointing at a hidden design build with no design direction at all — the builder falls back to its own taste. No error, no warning.
Deleting has the same effect, permanently:
Delete "
<name>"? Users can no longer pick this look. Projects already built with it are untouched.
Prefer hiding. It is reversible, and it leaves the instructions intact so you can bring the look back.
Categories
Category in the header creates one: Name (required) and an optional Description.
Refusals: A name is required., That name has no usable letters or numbers. (a name with nothing but punctuation in it), A category with that name already exists.
Deleting one keeps its designs:
Delete "
<name>"? Its designs are kept and become uncategorised.
One quirk: a category's internal identifier is derived from its name when it is created and is not recalculated when you rename it. Renaming is safe; it simply means the internal identifier still reflects the old name.