how to turn any landing page into a build prompt for your AI agent

You point your agent at a landing page you admire and say "build me something like this." What comes back is the page every model ships by default: centered hero, violet gradient, three feature cards, rounded corners on everything. The agent never saw the reference. It guessed. The fix is not a better sentence, it is a better input: a build prompt carrying the real tokens, the real section order, and the intent of the page you pointed at. This is the step-by-step for getting one and driving it through your agent.

what a build prompt actually needs to carry

A screenshot in your prompt is not a design brief. The model reads compressed pixels, invents a type scale, and often picks the wrong button as primary. A good build prompt replaces guessing with three things the agent can trust:

• Tokens. The measured raw values: colors and their roles, fonts, the type scale, radii, spacing, shadows, and motion. Not "a blue button" but #635bff, weight 500, radius 8px.
• Structure. The page in sections, in order: hero centered or split, the nav pattern, how many feature blocks, where proof and pricing and footer sit.
• Intent. What kind of page this is and what it is trying to do, so the prompt is shaped for the thing you are building rather than a generic clone.

Most tools in this space stop at the first two. They emit a DESIGN.md or a tokens file and call it done. That is useful, but a flat token dump does not tell the agent this is a landing page whose job is to convert, versus a dashboard whose job is density. uiscanner carries all three, and derives them by reading the rendered page and the DOM together, which is where the accuracy comes from.

step 1: pick a reference page worth learning from

Pick a real, public page whose design language you want to borrow, not a Dribbble shot. The value is in production decisions: the spacing a team shipped, the hover states, the real primary button. Landing pages from teams with strong systems make the best references. To see the shape of the output first, browse example teardowns, including full breakdowns of the Stripe and Linear systems.

One rule is built into the tool, not left to you: uiscanner is transformative by design. It describes and tokenizes a page and never copies or re-hosts the original site's asset bytes. You rebuild in your own stack from tokens and structure, and decorative imagery comes back with prompts to recreate it as originals.

step 2: run the teardown

You can scan from three surfaces: the web app, the CLI, or an MCP call inside your agent. From the address bar, prepend the app URL to any page:

uiscanner.com/https://stripe.com

From the CLI, name the archetype you are building with --target:

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

Every scan returns an id and a shareable uiscanner.com/t/<id> link, plus the tokens, the section structure, and a build prompt tailored for Claude. The scan reads the rendered page (vision) alongside the DOM, so it catches what a CSS scraper misses: the real primary button rather than the first one in the source order, whether the hero is centered or split, and which images are decorative.

To run this inside an agent, wire it in once. For Claude Code:

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

The setup page has the same one-liner for Cursor and Codex. It is a stdio server: nothing to host, no remote URL to paste. The first call opens a browser to sign in, then resumes. Before spending a scan, call ui_probe (a free preflight confirming the URL is reachable) and whoami (your plan and scans left). Both are free and catch a dead link or a bot wall before it eats a scan.

step 3: hand the prompt to your agent

Now you have a build prompt grounded in real values. Give it to your coding agent in your own project. Because the tokens and structure are structured data, not prose, the agent stops inventing brand values and starts applying them. GitHub's writeup on building a landing page in Copilot agent mode makes the same point: agents translate visual references into code far better when you hand them concrete context and name the files to edit.

Inside Claude Code or Cursor, the ask is plain language: "scan stripe.com as a landing page and build our pricing page against those tokens in Next.js and Tailwind." The agent pulls the teardown and writes the page using the actual color roles, type scale, and section order. This is where the generic defaults disappear: the model is reading a system instead of guessing at one.

step 4: iterate against the tokens

The first pass is rarely final. The point of tokens is that iteration stays anchored. Claude's own prompting best practices come down to being specific and pointing at concrete references, and a teardown gives your follow-ups something exact to point at:

• "The card shadow is too heavy, use the shadow token from the teardown, not your default."
• "Match the type scale exactly: the section headings are the wrong weight."
• "The hero should be split, not centered. Check the structure again."

Because the values are named, corrections converge instead of drifting. You can re-fetch the teardown any time with get_teardown by id or link, so the agent keeps ground truth on hand mid-iteration.

step 5: retarget for a different archetype

Here is the move most people miss. You built a landing page from a marketing site, and now you want the same visual language on your dashboard, where density, nav, and emphasis are all different. The instinct is to scan again. Do not.

retarget_teardown takes the id from a scan you already ran and rewrites the build prompt for a different archetype, without touching the page again. It is faster and spends no scan. In an agent you just say "retarget teardown t/abc123 to a dashboard." One teardown can feed a landing page, then a dashboard, then a portfolio variant, each tuned to that shape, all against a single scan.

The target archetypes and what each shapes the prompt toward:

the tools, and what each one costs

Inside an agent you get five tools, and only one spends a scan. ui_teardown is the scan itself. The other four are free and do most of the work: whoami reports your plan and scans left, ui_probe is the preflight, get_teardown re-fetches a finished teardown by id or link, and retarget_teardown re-aims the prompt at a new archetype. A good session leans on the free four so one scan can drive a landing page, a dashboard, and a settings screen without scanning twice.

a realistic session, end to end

You wire uiscanner into Claude Code once, then ask it to rebuild your pricing page in the spirit of a page you admire. It calls whoami, runs ui_probe, then ui_teardown with target: landing, writes your page against those exact values, and hands you a t/<id> link. You nudge the shadow and heading weight in two follow-ups pointing at the token values. Later the same language should carry into your settings screen, so the agent calls retarget_teardown on that id with target: dashboard. Total spend: one scan. That is the difference between an agent that decorates and one that builds from a reference. Tools like extract-design-system prove the appetite; uiscanner goes further by reading the rendered page plus the DOM for accuracy, carrying intent alongside tokens, and letting you retarget a single scan across archetypes for free.

quota, briefly

Scans are metered per plan on a rolling 30-day window, unified across the web app, the MCP server, and the CLI, so a scan is a scan wherever it runs. Free gives you 5, Indie ($12/mo) 100, and Studio ($39/mo) 400. Full numbers are on the pricing page. For the deeper comparison against the inspector tools people usually reach for, the uiscanner vs Snable writeup covers where a real build prompt beats a color panel. Otherwise: pick a page, run the teardown, and hand your agent a system to build from instead of a screenshot to guess at.