what is a build prompt?

A build prompt is the full instruction you hand an AI coding agent to make it build a specific interface, not just describe one. The word matters. A chat prompt asks a question. A build prompt commits the model to producing running code that fits a real project, so it has to carry the things running code needs: the design tokens, the section structure, and the constraints. Most people type one line ("build me a pricing page") and are surprised when the result looks like every other AI page. The line was not the problem. The missing context was.

a build prompt is not a wish

Most guides on prompting for UI tell you to be more descriptive: add adjectives, name a vibe, say "modern and clean." That advice is half right and quietly useless, because the words that feel descriptive to a human carry almost no design information. "Sleek," "premium," "cutting-edge," these describe taste, not decisions. As one breakdown of generic AI UI puts it, those words say nothing about hierarchy, tradeoffs, or user behavior, so the model falls back on what it always falls back on.

And what it falls back on is the average. A language model predicts the most probable next token, and the most probable UI is the one it saw ten thousand times in training: Inter, a purple-to-blue gradient, a centered hero, three feature cards, rounded buttons. That is not a bug in any single tool. It is what statistical averaging produces when you give it nothing specific to anchor on. Distinctive design lives in the tails of the distribution, and a vague prompt never reaches the tails.

So a build prompt is not a wish for a nice-looking page. It is the anchor. It is the difference between "make a button" and something the agent can actually build against.

what a good build prompt carries

Anthropic's own guidance on prompting is blunt about this: Claude responds to clear, explicit instructions, and if you want above-and-average output you have to ask for it explicitly rather than hope the model infers it. Their context-engineering work goes further, framing the real job as curating the entire information environment the agent works inside, not just the sentence you type. A build prompt is that environment, compressed into something you can paste or wire in.

Concretely, a complete build prompt for an interface carries three layers.

1. tokens

The raw design values, as machine text, not adjectives. Colors as hex, type as font families and a real scale, plus radii, spacing, shadows, and motion. "Rounded corners" is a wish. border-radius: 12px is a token. The agent can act on the second one and cannot act on the first.

2. structure

The section-by-section layout: what the hero is (centered or split), what order the sections come in, where the real primary button sits, which imagery is decorative versus load-bearing. This is the layer that vague prompts lose entirely, and it is the layer that makes a page feel like a considered product instead of a stack of default components.

3. constraints

What the agent must respect: your stack, your accessibility floor, the states a component needs (hover, disabled, loading), and what it must not do (do not copy asset bytes, do not invent a fourth card). Constraints are where a build prompt stops being a mood board and starts being a spec.

Here is the same request, before and after, so the gap is concrete.

The left column is a wish. The right column is a build prompt. Only one of them closes the loop.

where uiscanner fits

Assembling that right-hand column by hand is real work: you would inspect a reference, read off every value, sketch the structure, and format it so an agent can use it. uiscanner does that step. You paste any public URL and get a design teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a Claude-tailored build prompt to recreate the look. In other words, it outputs a build prompt, already carrying all three layers.

It reads the rendered page with vision plus the DOM, so it catches what a plain code scraper misses: the real primary button rather than the first one in source, whether the hero is centered or split, and which imagery is decorative (with prompts to recreate it as originals). And it is transformative by design. It describes and tokenizes a page and never copies or re-hosts the original asset bytes, so you rebuild in your own stack from the tokens and structure, not from someone's literal files. You can see the shape of that output on any teardown page, for example the Stripe teardown, where the tokens and structure are laid out the way an agent wants to receive them.

If you want the longer version of turning one specific reference into a prompt, that is its own walkthrough in landing page to build prompt.

getting a build prompt into your agent

The output is designed to travel. The fastest path is the web app: scan straight from the address bar (for example uiscanner.com/https://stripe.com), and every scan returns an id plus a shareable uiscanner.com/t/<id> link you can hand to a teammate or drop into a task.

If you work in an agent, wire it in over MCP so the agent can pull a fresh build prompt mid-task instead of you pasting one. The same server works for Claude Code, Cursor, and Codex:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

Or run it once from the CLI without any setup:

npx -y uiscanner-mcp@latest scan stripe.com --target landing

The MCP surface gives you five tools: ui_teardown(url, target?) for a scan, ui_probe(url) for a cheap preflight that spends no scan, get_teardown(id|link) to re-fetch a finished one, retarget_teardown(id, target) to re-tailor the same build prompt to another archetype without re-scanning, and whoami(). The target picks the archetype the prompt is written for: landing, dashboard, marketing, ecommerce, portfolio, mobile, or general. Retargeting matters here, because a build prompt is written for a job. The same page tokenized for a landing page reads differently than the same page tokenized for a dashboard, and retarget_teardown re-tailors the instructions without burning a second scan. Full setup for every client lives on the MCP setup page.

Scans run on a unified quota across web, MCP, and CLI on a rolling 30-day window: Free is 5, Indie ($12/mo) is 100, Studio ($39/mo) is 400. It is stdio-only, so there is no remote endpoint to configure; the server runs locally through your agent.

the one-line version

A build prompt is a design brief the model can execute. It carries tokens as real values, a structure the model would otherwise guess wrong, and constraints that keep it honest. Skip those and you get the average page every AI produces. Include them and the agent builds the thing you actually meant. uiscanner exists to write that build prompt for you from any page worth learning from, so the anchor is real design instead of a hopeful adjective.