Code to Figma — Export Running Code at 4 Fidelity Levels

The project is LOOP THREAD, an Astro 7 + Tailwind v4 storefront with real design tokens in @theme (colors, spacing, font weights) and two reusable components (CategoryCard.astro, ProductCard.astro) already in the source. The agent asked which page (homepage) and which level, then ran both Level 1 and Level 4 for this demo.

Level 1 — Code to Canvas

The agent built the project, started the preview server, added the temporary capture script, and used chrome-devtools-mcp (no browser extension needed) to open the capture URL. generate_figma_design reported completed after one poll cycle. The homepage (1512 × 3116) landed in Figma as a pixel-perfect, non-editable capture.

Level 4 — Full (nodes + components + variables)

This is the level that rebuilds the whole page as real, editable structure — not just a captured image. Reading global.css and every component file directly, the agent reconstructed all six sections (header, hero, categories, featured products, transparency, footer) as auto-layout nodes at 1440px, then componentized the repeating elements and bound every color and spacing value to variables:

Three bugs found and fixed during the run

The agent doesn't just generate and stop — it screenshots the result and audits it against what the code actually says:

Text overflow: the Product Card's name text hugged its content width, overflowing the card's fixed 220px width for longer names and clipping the price next to it. Fixed by switching the name to fill the available width with auto-height wrapping, matching the code's own flex behavior.
2.

Dropped opacity: the card image's 8%-opacity border (rgba(26,26,26,0.08) in the code) bound to the color variable correctly but came back at full opacity — setBoundVariableForPaint returns a new paint object that doesn't carry over the opacity set on the input. Fixed by applying the opacity to the returned paint instead.
3.

Leftover default fills on wrapper frames: an audit of every fill on the page found 56 auto-layout frames (nav row, button row, section headings, card rows, and more) still carrying Figma's default white fill, even though none of the corresponding <div>s in the source have a bg-* class — they're meant to be transparent. This is the exact wrapper-frame pitfall this skill's own references/known-pitfalls.md documents. Fixed by clearing fills on every pure layout wrapper and confirming, separately, that SiteHeader and SiteFooter — which do have bg-base-white in the source — kept a real bound fill instead of losing it in the same pass.

All three fixes were verified by re-reading the affected nodes' resolved values, and a final pass confirmed zero unbound solid fills remained anywhere on the page except the (at that point still placeholder) image areas.

A second pass: checked directly against the real Code to Canvas capture

Neutral-gray placeholders and eyeballed sizes are not good enough for a "Full" level that claims to rebuild the real page. Placing the Level 4 output next to the real Level 1 capture in the same file surfaced four more real gaps:

Card sizes didn't match the code's actual Tailwind scale. The category/product cards had been sized by eye instead of computed from the source's numeric utility classes (w-90, w-120, etc. — Tailwind v4's numeric scale is 1 unit = 4px). Recomputed exactly and resized every card and its image to match.
2.

Alignment was wrong for one section. The source's Categories heading and card row use lg:justify-end lg:items-end lg:text-right — right-aligned — but the rebuild had left them at the default left alignment. Fixed by setting counterAxisAlignItems/primaryAxisAlignItems to MAX and the heading's textAlignHorizontal to RIGHT.
3. A whole nested element was dropped, and its replacement data was invented. Each EmissionRow in the source has a two-layer bar: a light track plus a colored progress segment at a constant w-1/6 for every row. The rebuild only drew the track and — worse — fabricated varying proportions (1/6, 2/6, 4/6, 1/6) that don't exist in the source. Fixed by adding the real second bar at the real constant width, and this is now called out explicitly rather than glossed over.
4.

No real images. The 8 image areas (hero + 3 category cards + 4 product cards) were still generic gray placeholders. Uploaded the project's own real photos via the upload_assets MCP tool and applied each one to its correct target node.

A genuine new bug surfaced while fixing #4: the source images are .webp. upload_assets accepted them, returned a valid imageHash, and the resulting fill read back as completely correct (type: 'IMAGE', right hash, opacity: 1, bytes verifiable via getImageByHash) — but the image rendered as a blank white rectangle, both in a fresh screenshot and (going by the same evidence) on the canvas itself. Converting the same files to PNG and re-uploading rendered them correctly immediately, with nothing else changed. This wasn't previously documented anywhere, so it's now recorded in the skill's own references/known-pitfalls.md for future runs.

A third pass: two more real defects, caught by looking at the corrected screenshot itself

Even after the second pass, two things still looked wrong once the page was actually inspected again:

1. The EmissionRow bars still looked like one solid flat line, not a two-tone track + progress bar. Two separate bugs compounded: the color/border variable used for the track was created with full opacity baked in (a: 1, not the source's translucent value), and the progress-bar rectangle added in the second pass was positioned at the wrong y-coordinate — outside its parent frame's clipped bounds — so it was invisible the entire time, never actually rendering on top of the track at all. Fixed by applying paint-level opacity to the track (the same class of fix as the earlier opacity bug, reapplied — a fix on one node doesn't carry over to a different node binding the same variable) and repositioning the progress bar to exactly match the track's coordinates.

The product card row's right edge was clipped. The card width had been copied as a literal pixel value from the Level 1 capture (319.25px, taken at a 1512px browser viewport) instead of being recomputed for the Level 4 rebuild's own 1440px frame. The source uses a CSS Grid (grid-cols-4), so the card width is a fraction of its container — 301.25px at 1440px, not a fixed value that travels between viewports. Using the captured value made 4 cards overflow the row by 72px, silently clipped with no error. Recomputing the fraction against the rebuild's own row width fixed it exactly.

Both are now documented as new entries in the skill's own references/known-pitfalls.md — the grid-fraction-vs-fixed-scale confusion as a new rule, since it hadn't been seen before, and the recurring-opacity-drop as an addendum to the existing one.

A fourth pass: the header/footer border was still solid, and a better verification method

After the third pass, the header and footer borders still rendered as solid flat lines instead of a faint hairline. This time the fix wasn't just "apply the same patch to one more node" — it changed how this class of bug gets found and fixed at all:

1. Verified against the live site, not just another Figma screenshot. The project's own dev server was started, and the exact computed border-color was read straight from the live DOM for every element using the border style — consistently rgba(26, 26, 26, 0.08) everywhere in the real page. A translucent border and an opaque one of the same color are genuinely hard to tell apart by eye in a screenshot comparison; reading the real computed value removed any doubt about the target.

A file-wide scan, not a spot check. Rather than assuming the earlier two opacity fixes had covered every instance, every single node bound to the color/border variable was enumerated across the whole file in one pass. This turned up

9 more untouched bindings beyond the two already patched: the header's bottom border, the footer's top border, the footer's bottom copyright-row border, the hero image's border, all 3 category-card image borders, and 3 of 4 product-card image instances (whose per-instance overrides had quietly diverged from their already-fixed master once other properties, like the uploaded photo, were set on them).
3. Fixed the variable itself instead of patching nodes one at a time. Rather than reapplying the same per-paint opacity override a 12th time, the color/border variable's own value was updated to carry the real alpha ({r, g, b, a: 0.08}). Every one of the 11 bindings resolved correctly immediately, with zero per-node edits — because there was no longer a separate opacity value for any binding to lose.

This changed the skill's own guidance: references/known-pitfalls.md's Rule 22 now recommends baking alpha into the variable as the only reliable fix rather than a preference, and its mandatory pre-completion verification (Rule 2) now includes cross-checking computed styles against a live dev server whenever one is available — which it always should be for Level 2–4, since they require one to read the source from in the first place.

A final screenshot after all four passes confirms cards at the correct size with no overflow, the Categories section right-aligned, real two-tone emission bars on every row, all 8 real product photos in place, and every border at its correct faint opacity.

Re-verified on a second, unrelated project

To confirm the fixes above actually generalize rather than being specific to this one page, Level 4 was run again from scratch on a completely different, real Astro project — an Okinawan villa-rental site with its own design tokens, its own translucent-color naming (already split into separate -a72/-a35/-a15/-a10 tokens at the CSS level), a CSS Grid/flex-1 layout, and its own local .webp photos. Every one of the bug classes found above was checked for and came back clean on the first attempt: correct alpha on every translucent binding, no row overflow, all images rendering (PNG-converted per the fix), and computed styles matching the live site exactly. One new, unrelated bug did turn up in that run — combineAsVariants() silently dropping one component variant's padding — and is now documented and fixed the same way as everything above.

Summary

The same page now exists in Figma two ways: an exact visual reference (Level 1) and a design-system-quality, fully editable version built from the code's real structure, tokens, and images (Level 4) — both from the same source, at whichever fidelity the task needs.