Prototypes
Turn a plan into a clickable mockup you can share, comment on, and send back to the agent.
A plan can render as a prototype: a clickable mockup of what it describes, generated from the Specs themselves.
It exists to make a plan reviewable by people who will not read a Spec tree. A stakeholder who shrugs at "SPEC-4: schedule a report" will tell you within seconds that the screen never says which time zone the send happens in.
Generating one
Ask for it in the plan conversation. The agent builds the prototype from the plan as it currently stands, so generate it after the Specs are roughly right rather than at the first draft.
Regenerating it later picks up whatever has changed.
How the agent builds one
It follows the same pass every time. It looks at your linked repository first, so the prototype matches what you already ship. It walks every spec that has a screen, covers the empty and error states as well as the working one, checks its work against a fixed list, and only then saves.
That check is why the first version you open is usually complete, instead of arriving with gaps you have to point out.
Matching your app
Link a repository and the prototype uses your real colours, type and components. The agent tells you which repository it matched against, so you can check it picked the right one.
If it cannot match, it says which of three things happened, because they need different answers from you:
- No repository is linked. Link one and the next prototype will match your app.
- Your linked repositories hold no user interface. Nothing to match. This is a fact about your code, not a problem to fix.
- A repository could not be read. Its connection needs reconnecting. Your app is there, we could not see it.
Revising keeps your comments in place
When the agent revises a prototype, it carries your comment anchors across, so feedback left on an earlier version still lands where it belongs. Restyling or moving something does not break its comments.
The agent tells you when an anchor is lost: if a part is removed altogether, the comments anchored to it lose their place.
What the agent checks before you see it
The agent works through a fixed list before it saves, and the save reports anything it missed back to it. These are the things on that list:
- Every screen shows the real address it stands for.
- Every screen says whether this plan adds it, changes it, or leaves it alone. When we cannot tell, it says so rather than guessing.
- Notes from the agent sit outside the mockup, never inside it, so commentary is never mistaken for the product.
- The flow list dims what is not built yet instead of hiding it.
Point at something and say what to change
Open the prototype and press the element-select button in its toolbar. The pointer becomes a crosshair and whatever you hover is outlined, so you can see what you are about to pick. Click the button, card or heading you mean, type one instruction, and press Enter.
Your instruction lands in the chat box with the element, the screen it sits on and the prototype it belongs to already named, added after anything you were part-way through writing. Read it, change it if you want, and press send. Nothing reaches the agent until you do.
It works the same way on the plan's own prototype and on any prototype file in the drawer; on a file the instruction names that file, so the agent edits the right one.
Sharing it
A prototype has its own share link. Anyone holding that URL can open it, sign-in or not, which is what makes it useful for showing a customer or an exec.
A prototype share link sits outside your plan's permissions. It is a public URL for whoever has it. Making the plan private later does not kill an existing link. Revoke the link itself, and see Sharing a plan.
Comments come back to the agent
Reviewers can leave comments anchored to a specific part of the prototype, and you can resolve them as you work through.
The useful part: a comment can be sent to the planning agent, which reads it as feedback on the plan and updates the affected Specs. That closes the loop from "this screen is wrong" to a changed acceptance criterion without anyone transcribing anything.
Wrapping the prototype builder
Your team can add its own rules to every prototype without rewriting how prototypes are built. A wrapper is a company or project skill that extends the built-in one; it names the builder's hooks, so it keeps working when we reword a step.
| Hook | What it adds |
|---|---|
extra-craft | Your typefaces, spacing and brand rules |
extra-screens | Screens you want in every prototype |
extra-notes | Extra kinds of note beside the two we ship: what did not change, and what happens underneath |
extra-checks | More things to check before saving |
save-bar | Raise the bar the agent holds itself to before saving |
Write this under Settings → Skills. Copy it and change the parts in your own words.
Paste the body only. The settings form writes the header for you. Pasting a whole file that carries its own header gives you two, and the inner one quietly becomes body text.
Follow /skills/prototype-builder/SKILL.md exactly. Everything below EXTENDS it.
The pass, the way a prototype is saved and the checks it must pass are unchanged.
[HOOK: extra-craft] - our house style, on every prototype:
- Display face is Söhne, body is Söhne. Never a substitute, never a system font.
- Brand green is a foreground only. It is never a background fill.
[HOOK: extra-screens] - always include, even when the plan does not mention them:
- The printed dispatch note. It is a document, not a screen, so it is drawn as a
sheet with no browser chrome.
[HOOK: extra-notes] - add one register beside the two we ship:
- "Warehouse impact": what changes for a picker on the floor.
[HOOK: extra-checks] - also check before saving:
- Every price is shown with its currency. A bare number has been misread twice.
- Every date is unambiguous (12 Mar 2026, never 03/12/26).
[HOOK: save-bar] - saving additionally requires that every screen showing stock
also shows its as-of time. This RAISES the bar. It never lowers it.What a wrapper cannot do
A wrapper adds rules and raises the bar. It cannot lower one. It cannot:
- Change how a prototype is saved. Saving has one door, and it has to be one door: it stores the file, records the prototype, and stamps which specs it was built from, all together. Save any other way and the file exists with nothing pointing at it, so the Prototypes panel opens an empty tab and you cannot tell what the agent did.
- Widen where a prototype may load things from, or unpin the icon version. Both keep a saved prototype rendering the same way months later.
- Make a prototype call a server or load real data. It runs entirely in your browser, on made-up data. That is what makes it safe to share with anyone holding the link.
- Remove a check, or lower the accessibility floor.
If a wrapper asks for any of those, the agent follows the built-in skill and tells you it did.