Implement supplied design frames

Build Design turns supplied design frames into code and compares the implementation against the original. The supplied frames define spacing, dimensions, radii, colors, typography, and component choices. Changes that the design does not show are treated as deviations for the user to decide.

The workflow reads the design at its source, maps it onto the project's existing system, implements the specified frames and states, and checks rendered differences before reporting completion. It aims to preserve the supplied design rather than introduce a different aesthetic.

Use it when a design needs implementation within an authorized interface scope. Named frames define the boundary. Frames showing the same piece at different widths are treated as breakpoint versions of one piece.

A Figma link requires access through an available Figma connection. The workflow searches available and deferred tools before declaring that connection missing. A connected server offering only authentication requires sign-in; absent tools require a connection rather than a guessed implementation.

Screenshots and exported images support estimated measurements only. The assumed capture scale must be stated, and a Figma source is requested when available. Alternative design exploration belongs to variant, finished-work review to interface-review, and component stress testing to break.

Before implementation, collect a screenshot of every scoped frame and its design values. Read project tokens and the component library, then map bound design variables or matching raw values to existing tokens. A raw value without an exact token maps to the nearest existing token and is reported as rounded.

Component instances map to the equivalent project component and shown variant. Without an equivalent, the workflow uses plain markup in place, records the deviation, and asks whether a component should exist. One-off layer groups also stay inline. New tokens, arbitrary values, and component variants are not introduced merely to hit a design number.

Visible rounding requires a decision when spacing or size differs by more than 2px or a color moves to a different step. Data requirements are connected to existing sources. Parts whose backend is absent can render from props, but must be reported as unwired.

Implementation covers the frames, their breakpoints, and explicitly drawn states such as hover, empty, or error. Undrawn states retain existing component defaults and are listed as missing. Neighboring copy, icons, and unrelated code stay outside the scope.

Comparison places the rendered build beside the design at every frame width and checks elements against the collected properties. Concrete measurements establish mismatches. With browser access, screenshots support the comparison; without it, the local URL and required widths are handed over with comparison marked unverified.

After correcting implementation-caused mismatches, compare again. Remaining differences must be documented rounding or open questions. The final table lists Element, Design, Built, and Status, followed where applicable by Unwired, Missing states, and Domain conflicts. The report also states the running location and inspected widths.

Figma tools provide exact values when connected; image references provide estimates. Existing project tokens and components supply implementation primitives. Accessibility, color, typography, layout, writing, and visual-polish conflicts are reported to their owning better-* skills rather than silently redesigned. Browser and design-tool availability limit verification.