How to implement a Figma design with a coding agent

I gave a coding agent a landing-page mockup and one job: make the Storybook story match it. The first render looked right when I put the two side by side. The diff against the mockup said 3.9% of the page's pixels were off. Nineteen uploads later it was 0.02%, locked one section at a time from the top. This post is the loop that got it there, how to run it yourself, and what I learned turning it into an agent skill: an earlier run of the same page, on an earlier version of the skill, spent ten uploads getting to 3.2% and was still visibly wrong.

A coding agent needs a way to see how far its render is from the design. Reading the Figma frame gets it a close first draft: the right sections, the right copy, roughly the right sizes. What it lacks is feedback. It cannot tell that the heading is two sizes too big or that a card sits 20px low, so it declares the page done and the last mile lands on whoever reviews it. The fix is to make the design the thing every render is compared against, and to give the agent a method for closing the gap rather than a number to chase.

In UI Verify the comparison is a design baseline: a design image declared as a story's baseline, so each upload of that story is diffed against the design instead of against an earlier screenshot of itself. The diff is the same one that catches regressions. The only change is what sits on the other side of it. The Figma to code page shows the whole flow at a glance; the rest of this post is the detail.

Export the Figma frame as a PNG at 1x. A frame drawn at 1200px should come out 1200px wide, not 2400. If your agent has the Figma MCP connected it can export the frame itself from a link; otherwise select the frame, pick PNG and 1x in the export panel, and commit the file. UI Verify scales the design to your render's width before comparing, so a small mismatch in width will not break the diff, but building at the canvas width the designer used keeps every measurement meaningful.

The value is a path to a PNG that ships inside your built Storybook (put it in a staticDirs folder) or a data: URI. Remote URLs are not accepted: the design has to travel with the upload, so nothing depends on a Figma link staying alive. The story carries its own design, which means no story IDs to look up and no separate upload step. This works for Storybook projects, and for Vitest tests through takeSnapshot(name, { baselineImage }).

Ship the design's font files with Storybook. Without the exact font, every line of text is a few pixels off and the diff lights up on copy you never touched, which buries the differences that matter.

Then mark anything that is supposed to differ with data-uiverify-ignore: a background video, an autoplay animation, live or random data. UI Verify blanks that element's box on both the design and your render, so it never counts. Use it sparingly. The whole box is blanked, so the box's own size and position go unchecked too, and a missing product photo is an unfinished page, not a dynamic region. Placeholder copy in the mockup is the other common trap: if production shows real data there, either ignore it or put the mockup's text in the story's fixtures.

Build Storybook and upload it with uiverify upload. The first build comes back changed, often by a lot. The useful part is not the percentage but where the green is. Over the UI Verify MCP your agent can pull the design and its render side by side, cropped to each region that differs, and page through a tall page in 500px bands so the footer gets the same attention as the hero. UI Verify shows where the pixels differ; the agent looks at those crops and works out why, whether that is a size, a gap, a weight, or a wrap.

That picture is why the order matters. A vertical difference near the top, a few pixels of padding or a heading one step too large, pushes everything below it down, and the diff then reports every section underneath as wrong. So work from the top: fix the first section until it matches, upload, and only then move to the next. The run in the chart below did exactly that: nav, headline, subtitle and buttons, the preview's shadow, logo strip, cards, call to action, footer.

You know it matches when every section measures clean, not when the percentage gets small. The percentage counts pixels, so a large blank area and an ignored box both dilute it, and it can sit still while real progress happens: in this run it stayed near 1% for six uploads while the preview's soft shadow was tuned. The per-section view is what shows it. At upload 10 the nav and hero were locked to within about a hundred pixels, while the logo strip and cards, not reached yet, still differed by thousands.

By upload 19 every section was locked and 0.02% of the page differed, a few hundred anti-aliased pixels along text edges. That is what done looks like: no section with a solid halo, nothing drawn twice.

Accepting ends the comparison with the design. When you accept a render, it becomes the story's baseline, and from then on every pull request is checked against that render, not against the mockup. That is what you want once the page is right: the design did its job and the regression check takes over. Accept too early and whatever was still off becomes the reference, and every later build passes against it.

Until you accept, a story that does not match its design shows as changed, like any other visual change, so it cannot slip through a pull request unnoticed. When the designer ships a new export of the same frame, the new image takes over as the baseline again and the page is checked against the new design. The design baseline is also scoped to your branch, so declaring one on a feature branch does not move the baseline on main.

The loop above is a procedure, and procedures are what agent skills are for. The implement-figma-design skill packages it so any coding agent can run it the same way every time:

1. Gets the design as a 1x PNG, exported through the Figma MCP from the link you give it, or asks you for an export.
2. Declares it as the story's baseline and checks that the fonts and canvas width match the design.
3. Builds the whole page once and uploads it, so there is a first diff to work from.
4. Splits the design into blocks at its natural gaps (nav, hero, cards, call to action, footer) and writes the list down before the second upload.
5. Works down the list one block per upload: measures every element in the block on the design and on UI Verify's render, fixes every difference in that block, uploads, and re-measures the same window. It moves down only when the block measures clean.
6. Stops when every block is clean, when it runs out of its upload budget, or when something it needs is missing, and reports which, block by block. It never accepts. That decision stays with you.

The first version of the skill was a paragraph: upload, read the diff, fix, repeat. It took about a dozen revisions over five days of runs to get to the list above, and each rule in it exists because a run failed without it. If you build your own version of this loop, with UI Verify or anything else, these are the lessons worth stealing:

• Locked means zero, not "roughly in place". An earlier run of the same page counted a section as done once it looked close. At its upload 10 it was 3.2% off, with the nav and headline it had called done each still thousands of pixels out.
• One section per upload. A run that batched fixes across several sections went from 3.42% to 4.72% and could not tell which change caused it. One section at a time, top down, means a finished section stays finished and every regression has a single suspect.
• The number is a progress log, not a decision. Two runs reverted fixes that were correct and measured, because the percentage went up after them. The percentage tells you whether you are moving; the regions tell you what to do.
• Read both images, not only the overlay. A diff overlay under-reports low-contrast differences. One run left a badge 35px too wide with no highlight on its outline, because the outline was faint. Compare the design and the render at the same window.
• Measure, don't eyeball. "The buttons look off" produces nudging. "3px taller, 9px wider" produces a padding fix. A few lines of Python over the two images give numbers the agent can act on.
• Never let the agent grade its own screenshots. A run that measured its own page in its own browser declared a match and accepted it with buttons 20px too wide and a card row 15px too tall. The only view that counts is the render the comparison actually used.
• Don't accept halfway. One run accepted at about 2.8% to lock in progress. The next session then spent 20 rounds chasing a 13% difference against that accepted render, because the design was no longer the baseline.
• A flat number is not a floor. Runs kept stopping around 1% and calling the rest anti-aliasing. On one header, measuring the ink itself (where the glyphs sit and how dark they are) instead of bounding boxes took it from 0.90% to 0.125%: the wordmark was weight 700 in code and 600 in the design.
• Give it a budget and honest stop states. Without them, runs stopped wherever the number looked small enough and wrote reports that claimed more than their logs showed. Now the only exits are clean, out of budget, or blocked, and the report has to cite the measurements it was built from.

Install it with npx skills add uiverify/uiverify --skill implement-figma-design, hand your agent the Figma link, and run /implement-figma-design. The skill page has the full playbook, and the design baselines docs cover the parameter, the ignore attribute, and what happens when you accept.

Matching the design is the authoring half of the job. Once the page is accepted, keeping it that way is ordinary visual regression testing: every later pull request is diffed against the render you approved, and baselines covers how that render moves across branches.