Design to code

Handing a design to an agent usually means pasting an image and hoping. Studio hands over a structured document instead, and the useful part of it is the parts that point back into your repository.

What the agent receives

• The screen's semantics, not its markup: what each element is, how it is laid out, and how it responds, extracted from the design's own representation rather than scraped from rendered HTML.
• The tokens it uses, matched against the tokens that already exist in your project. Where a design variable corresponds to a code token, the handoff says so, so the agent writes your token name rather than a hex value that will be wrong the first time someone changes the theme.
• Component bindings. Where a design component corresponds to a component in your codebase, the binding carries the source path, supported platform and compatible prop map. An agent that has a proved binding to packages/ui/Button.tsx writes an instance. Without that evidence, the handoff keeps the component explicitly unbound instead of inventing a source component.
• The node ids, carried into the code. This is small and it pays twice: it makes a later fidelity comparison exact, and it makes an automated tap on that element unambiguous when the flow becomes a test.
• The motion, as the compiled CSS described in Motion.
• The assets the screen actually uses.

How a component match is accepted

Project discovery is bounded and read-only. It inventories exported contracts without executing the application, supports React, Vue, Svelte, SwiftUI and Compose, and respects configured include, exclude and import-path boundaries.

A component becomes an automatic binding only when all of these checks agree:

• Its name has one supported match after conservative normalization.
• The candidate belongs to the requested platform.
• Prop names and types are compatible.
• Enum and variant options agree.
• No second candidate is close enough to make the result ambiguous.

The output carries the evidence state: matched, ambiguous or unmapped, plus a reason. A confidence value never overrides an incompatible prop contract or a platform boundary.

Where unmatched components go

A binding that matched is a fact. A binding that did not is also information, and it is reported rather than dropped. It becomes a review list: configure a project boundary, choose among ambiguous candidates, or create the component when it is genuinely missing.

That turns a handoff into a work list instead of an argument about whether the implementation is faithful.

The other direction

The same map works backwards. Studio can read the components and tokens that exist in your project, which is what lets a design be authored against what is really there, and what lets a code connect draft be generated for the components whose contracts correspond.

How Pathrule proves hard claims collects the binding, readiness and fidelity gates in one technical reference.