Turn a mockup into a working prototype

Attach a mockup image in Claude Code and get a clickable prototype that follows its layout and states, built in its own folder with fake data.

Task: Turn a mockup into a working prototype · Other tasks

Fill in the details

What the screen or flow is for (required)

One sentence. Attach the mockup image in Claude Code itself; this page cannot hold images.

States and interactions to include

Optional. Especially the states the mockup does not show.

How to build it

Folder for the prototype

Optional. Claude puts every new file here.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Here is a mockup: the image attached to this message. Build a working prototype I can click through, matching the layout and states shown.

What it is for: [fill in: What the screen or flow is for]
Build it as a standalone page in HTML, CSS and vanilla JavaScript, with no build step.

Before building, list what you see in the mockup: screens, components, text and the states it implies. If no image is attached, or part of it is unreadable, stop and tell me.

Rules:
- Put all new files in one new folder. Do not change or delete existing files.
- This is a prototype: use fake data, no backend, no real requests and no new dependencies.
- Before building, list interactions the mockup does not specify, such as where a button leads or what an error looks like. Ask me about the ones that matter for the flow. Build the rest as clearly marked placeholders; do not invent their behavior.

When it is built, if you have a browser tool (the Desktop preview, the Chrome extension or a Playwright MCP server), click through the path to each state and compare the rendered page with the mockup. If not, say it was not verified and list the checks I should do by hand.

Tell me how to open it. Finish with:
1. The files you created.
2. A click path that reaches each state.
3. Where the prototype differs from the mockup, and why.
4. Placeholders, open questions, and what you verified in the browser.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

You have a static mockup and want something people can click through, so questions about flow and interaction come up before engineering work starts. Paste, drag or @-mention the image into Claude Code before you send the prompt.
You want to hand engineering a working example of the interactions instead of describing them in a document.
You want to try two or three variations of a screen quickly and compare them in a browser rather than in a design tool.

When not to use it

You need production code that matches the design exactly. Use the screenshot template, which builds into the real app and checks the result against the image.
You have no mockup yet, only an idea. Describe the tool in words instead, or pin down the requirements with a spec interview first.
You cannot attach images where you run Claude. This page cannot carry an image, and without it Claude would be guessing the layout.

Why this structure

The opening line refers to the attached image, and the prompt asks Claude to stop if none is attached. A prototype built without the mockup would look plausible and match nothing.
Listing what Claude sees before it builds makes its reading of the mockup visible. You can correct a misread label or a missing screen before it is built in.
The states field covers what a single static image rarely shows, such as errors, loading and success, which is where a clickable prototype adds the most.
The rules keep the work contained: one new folder, no edits to existing files, fake data and no requests. You can delete the folder and nothing else in the project has changed.
The build setting decides whether the prototype stands alone or uses the project's own components. A standalone page is quick to share; project components make the prototype closer to what will ship.
Unspecified interactions are flagged before building, and the ones you do not answer become marked placeholders. You see which behavior came from the mockup and which is still undecided, instead of finding invented behavior later.
The click-through step gives Claude a check when a browser tool is available, and asks for a list of manual checks when it is not, so the report says plainly whether the prototype was looked at.
The closing list asks for a click path to every state, each difference from the mockup and the remaining placeholders, so you can review the result in a few minutes.

Example input (fictional)

What the screen or flow is for

A three-step signup flow for a team plan

States and interactions to include

Empty form, an invalid email error, a loading state after submit, and a success screen with a link to invite teammates.

How to build it

a standalone page in HTML, CSS and vanilla JavaScript, with no build step

Folder for the prototype

prototypes/team-signup/

Follow-ups to send Claude

Add a second version of step two with the plan options as cards instead of a list, and a toggle to switch between them.
Make the prototype work at phone width and tell me which parts of the mockup did not fit.
Write a short handoff note for engineering: each state, what triggers it, and the assumptions that still need a decision.

Common mistakes

Sending the prompt before the image is attached in Claude Code. Check that the image appears in the message first.
Expecting the mockup alone to define behavior. Name the states and interactions you care about; otherwise Claude has to ask about each one or leave it as a placeholder.
Letting the prototype grow into the product. Keep it in its folder with fake data; when the design settles, build the real feature against the codebase.

Implement from a screenshot and self-check: Give Claude Code a design image; it builds the UI, screenshots the result, compares the two and fixes differences for a set number of rounds.
Map edge cases before building: Ask Claude Code to list the error states, empty states and edge cases a feature must handle, so the design covers them before anyone builds it.
Write a spec by interview: Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code docs: Common workflows, work with images (Anthropic documentation)
How Anthropic teams use Claude Code (Anthropic documentation)