A useful screenshot-to-spec pipeline has a fixed order. Sample the palette from pixels. Call whether an agent can one-shot the UI. Name tokens, screens, and components. Infer a data model and routes. Emit a file tree and a build order. Then hand the agent a kickoff that points at the screenshot, not at a paragraph of vibes.

I run that order in HelpKoder because agents fail in predictable places. They invent a primary color. They skip the empty state. They create components/Button.tsx and nothing else. A spec that streams in sections is easier to correct than a 2,000-word essay.

Why does the order of the spec matter?

Coding agents follow the first confident structure they see. If you lead with marketing copy, they build a landing page. If you lead with a component list and no tokens, they pick Tailwind defaults. If you lead with a schema and no screens, they build an admin CRUD that does not match the mock.

HelpKoder streams verdict first so you can abort a bad frame. Tokens come before components so the tree inherits the palette. Screens come before routes so Next.js files map to what is visible. Build order comes last so the agent does not start with auth when the screenshot is a settings panel.

That sequence is the technique. The model is interchangeable. The document shape is not.

What happens before the model answers?

The browser samples colors from the frame the moment you drop it. You see swatches before GPT-4o writes a word. I added this because waiting 20 seconds to find out the mock is navy, not purple, wasted runs.

The sampled palette is a hint, not a contract. The spec still has to name roles: background, foreground, border, accent, destructive. A raw #C45C26 without a role is junk in a design system. The studio maps swatches to those roles and keeps hex copyable.

If you attach extra frames, the palette still comes from the first image unless you say otherwise in chat. Multi-frame is for flow, not for mixing two brands.

What does “looks like” do in the spec?

After the verdict, the spec says what the UI actually is. Dashboard with a table. Auth with email magic link. Mobile tab bar. Marketing hero with a price. This sentence stops the agent from turning a dense settings page into a SaaS landing.

I used to skip this and go straight to components. Agents then “improved” the layout. A screenshot-to-spec tool has to be conservative. The mock is the product. The spec is the inventory.

How do tokens get extracted from a screenshot?

Tokens are the colors, type, radius, and spacing the frame actually uses. HelpKoder names them the way a Tailwind theme wants them: background, foreground, muted, primary, destructive, radius. It does not invent a 12-step scale you cannot see.

Type is harder than color. A screenshot does not embed font files. The spec guesses a pairing from the look (a display serif plus a sans, or a mono for labels) and tells the agent to substitute only if you override. Spacing is inferred from density: tight tool UI versus editorial marketing.

If the mock is noisy (gradients, photos, glass), the spec should say so and pick the flat roles underneath. Agents love gradients. Specs should not.

How should screens and hidden states be listed?

List every visible screen in the upload, then list the states the frame cannot show. Login, empty, error, loading, permission denied. What a screenshot hides is the longer treatment. The short rule: if you cannot see it, either infer it in one line or mark it out of scope.

A KINDA verdict often means the happy path is clear and the failure path is not. That is still a valid spec. It is a bad one-shot.

What belongs in the file tree and build order?

The file tree is the agent’s map. Next.js App Router for web. Expo for mobile unless you chat a different stack. Prisma models if the UI implies records. Routes that match screens.

Build order is the sequence that will not thrash: tokens and layout shell, then the primary screen, then secondary screens, then data, then auth if it was not the first frame. I put auth last when the screenshot is an app interior. I put auth first when the screenshot is a login.

The kickoff prompt restates this in a form you can paste. Turn a screenshot into a Cursor spec is the hands-on version. AGENTS.md vs CLAUDE.md is which file to drop in the repo.

What do I still do by hand?

I still crop the screenshot. I still add a second frame for the sheet that the first frame only hints at. I still chat “no purple, use the sampled palette” when a Dribbble shot fooled the model. The studio does not replace taste. It replaces the blank page an agent fills with defaults.

If you want the product context around this pipeline, start at what HelpKoder is. Then drop a frame in the studio.

How a screenshot becomes a spec an agent can run