Specialists

Building a prototype

Working, responsive, accessible UI in your existing stack — not a mockup.

Code
/prototype                                  stay in prototype mode
/prototype build a mobile intake flow       one job, then back

What comes back

Real code in the stack the repository already uses — same framework, same component library, same conventions. Responsive at the widths you actually ship. Keyboard reachable, with focus states and labels, because retrofitting that later is how it never happens.

Not a static mockup, and not a new toolchain.

Give it something to match

The more specific the reference, the closer the first pass:

Code
/prototype an invite flow, matching @web/src/components/dashboard-account-dialog.tsx
/prototype this screen, from @sketch.png, using our existing table component

Pointing at an existing component in your own codebase is the strongest signal you can give — it will match your patterns rather than invent new ones.

It checks its own work

The prototyper renders what it built and looks at it, at desktop and mobile widths, before saying it's done. If the layout breaks at 390px it fixes it first.

To push that further — clicking through the flow, not just looking at it — see Checking it actually works in a browser.

Design first for anything new

For a screen that doesn't exist yet, /design decides what it should be and /prototype builds it. Going straight to prototype gets you a competent version of whatever it guessed you meant.

If it doesn't work

It used a library we don't use. Name the one you do, or point at a file that uses it. It reads the repository but can't tell which of three installed options is the blessed one.

It looks generic. Run /design first, or hand it a reference. With no direction it produces something reasonable and unremarkable.

It's beautiful and doesn't work. Ask it to verify the flow — see /verify — or run the tests. Rendering correctly and behaving correctly are different claims.

Next