Skip to content
Book demo

Coding

Figma design to production code

Turn updated Figma frames into production components by reading tokens and layout, generating code, running a visual diff, and opening a PR.

figmadesigndesign systemcomponentreactuicodingdesign-to-codetokensfrontend

[ workflow / coding ]

Figma design to production code

A Figma publish event sends Cosmos to the updated frame. It extracts tokens, spacing, typography, and breakpoints, maps components to the existing design system, generates code, and compares the rendered output with the frame. If the visual diff misses tolerance, the agent iterates before opening the PR.

12 nodes

11 edges

Trigger[trigger]
Figma frame published

Figma MCP event / manual URL

System step[read-figma]
Read design via Figma MCP

Tokens, hierarchy, states

AI Agent step[map-ds]
Map to design system

Reuse existing components

Decision

New tokens needed?

Design-system gaps

Yes
AI Agent step[add-tokens]
Generate token additions

Design-system package commit

YES
AI Agent step[generate]
Generate component code

React / Vue + a11y + styles

AI Agent step[stories]
Write Storybook stories

Default, hover, focus states

System step[render]
Render + screenshot

Headless browser, all viewports

System step[visual-diff]
Visual diff vs Figma

Pixel + structural similarity

Decision

Within visual tolerance?

Default: ≥ 95% similarity

No
AI Agent step[patch]
Patch discrepancies

Fix + re-render + re-diff

YES
Output / Result[open-pr]
Open component PR

Code + stories + visual diff

Workflow prompt

Paste this into Augment to reproduce the workflow end-to-end.

Build a Cosmos workflow that turns a published Figma design into a production-ready pull request.

Trigger: a Figma "file published" or "component updated" event, or a manual trigger with a Figma frame URL.

Steps:
1. Read the Figma frame via the Figma MCP. Extract: the component hierarchy, all design tokens (colors, spacing, radii, shadows, typography), responsive breakpoints, interactive states (hover, focus, disabled, loading), and any annotations the designer added.
2. Map the design to the project's existing design system. Identify which existing components, tokens, and utility classes can be reused. Flag new tokens or patterns that don't exist yet and need to be added to the design system.
3. Decision: "New design-system tokens needed?".
   - If yes, generate the token additions in the design-system package as a separate commit, to be reviewed first.
   - In both cases, continue.
4. Generate the component code in the project's stack (React/TypeScript, Vue, etc.) following the conventions in AGENTS.md. Use the mapped design-system primitives. Include: prop types, accessibility attributes (ARIA roles, labels), responsive styles, and interactive state handling.
5. Write Storybook stories (or the equivalent) for the main states: default, hover, focus, disabled, and any data-driven variants visible in the Figma frame.
6. Render the component in a headless browser and take a screenshot at each configured viewport.
7. Run a visual diff between the rendered screenshot and the original Figma frame export. Compute pixel-level and structural similarity scores.
8. Decision: "Within visual tolerance?". Use a configurable threshold (default: 95% similarity).
   - If no, identify the largest discrepancies, patch the component, re-render, and re-diff. Repeat up to a retry limit.
   - If yes, continue.
9. Open a pull request with: the component code, the Storybook stories, the visual diff images (Figma vs rendered), and a link to the original Figma frame for reference.

Constraints:
- Always include the side-by-side visual diff in the PR so reviewers can verify fidelity without opening Figma.
- Never commit generated code without at least one Storybook story: undocumented components accumulate design debt.
- Token additions must be in a separate commit from component code so they can be reviewed and merged independently.