Skip to main content
Version: 0.1.125 – latest

UI prototypes

For a feature with a user interface, the design is settled before the code is written. A prototype is that design, made concrete enough to react to.

Why a prototype comes first​

An agent asked to implement a screen has to decide what it looks like. Left to itself it will decide something reasonable and you will disagree with it after the code exists, which is the expensive moment to disagree. A prototype moves that conversation earlier, when changing your mind costs a regeneration instead of a rewrite.

Two kinds​

HTML prototypes are standalone: fast to produce, fast to change, not running on your stack.

Target-stack prototypes are built and run on the project's own stack, so what you are looking at is the real thing. They live on the project's prototype branch, one per feature, and the feature's target-stack build has its own tab with its own guarded rebuild.

The design source and whether a target-stack preview is built are independent project settings, so you can work from an HTML design and still have it reproduced on your stack.

Options, and choosing between them​

A prototype comes as options rather than a single answer. You pick the one to carry forward, and the implementation agent reproduces the option the feature selected — not a fresh interpretation of the scenarios.

Options can be opened in their own browser tab when the embedded preview is too small to judge.

Giving feedback​

Pin it. Feedback attaches to the component it is about, on both HTML and target-stack prototypes, and several pinned problems can be reported from one session together. A pinned comment carries the context that a sentence in a chat box does not.

The design system​

A design system is produced automatically by the shell and prototype flows and written to DESIGN.md in the modernized codebase. That is what keeps the fifth feature looking like the first: agents read it rather than re-deciding typography and spacing per screen.

Accessibility​

Generated prototypes are checked for accessibility, deterministically, as they are produced. Whether that check gates a feature is a project setting — see Project settings.

Keeping a prototype honest​

  • When a feature's to-be scenario changes, its prototype can be regenerated, because a design for behaviour that has moved on is misleading.
  • A target-stack rebuild reconciles the prototype to a design that has moved.
  • The target-stack prototype tracks the code that ships, so it does not drift into being a screenshot of something that no longer exists.
  • Every prototype agent that can render its work looks at it, rather than reporting success on markup it never displayed.

Separately from individual features, the project has an application shell and a navigation map — the frame every screen sits in. It is generated once and reproduced by the implementation agents, so features do not each invent their own navigation.