Design-to-Code Builder

/figma-implement-design

A structured workflow for translating designs into production-ready code with high visual fidelity. There is no live Figma connection: the design context comes from what the user attaches or pastes -- an exported frame image, inspect-panel/dev-mode CSS, design tokens, or a written spec. The output is working, componentized frontend code delivered as a chat artifact and integrated with the user's design system. For a throwaway pixel-faithful HTML copy of a screenshot, use design-mirror; for producing handoff documentation rather than code, use design-handoff; for organizing pasted Figma data itself, use figma.

Required Workflow

Follow these steps in order. Do not skip steps.

Step 1: Gather the Design Context

Collect what a live design tool would normally provide, from the user:

• Visual reference (required): an exported image of the frame or component. This is the source of truth for validation; keep it in view throughout.
• Structured values (strongly recommended): inspect-panel or dev-mode CSS for the key layers, or a token/variable export. These give exact colors, typography, spacing, and radii.
• Assets: exported SVGs/PNGs for icons, logos, and imagery. Do not substitute icon packages when the user can export the real assets; ask for them.
• Behavior notes: hover/active/disabled states, responsive intent, and any interactions not visible in a static export.

If the user provides only a Figma URL, explain you cannot open it and ask for an export plus the inspect CSS of the main layers. If only an image is provided, proceed, but state which values are estimated from the image.

Step 2: Understand the Structure

Break the design into its component tree before writing code: layout regions, repeated patterns, atomic components, and their variants. For a large screen, implement section by section rather than in one pass.

Step 3: Translate to Project Conventions

• Treat the design values as a representation of design and behavior, not final code style.
• Reuse existing components (buttons, inputs, typography, icon wrappers) instead of duplicating functionality; extend a matching component with a new variant rather than creating a parallel one.
• Use the project's color system, typography scale, and spacing tokens consistently; map design values onto them.
• Respect existing routing, state management, and data-fetch patterns.
• Replace absolute positioning implied by the design with proper flexbox/grid relationships and responsive units.

Step 4: Achieve Visual Parity

• Prioritize fidelity to the provided design; avoid hardcoded values where tokens exist.
• When project tokens differ from the design's values, prefer the project tokens but adjust spacing or sizes minimally to match the visuals.
• Follow WCAG requirements for accessibility.
• Implement the interactive states from the behavior notes (hover, active, focus, disabled), and sensible defaults where unspecified -- flag those defaults.

Step 5: Validate Against the Design

Before marking complete, compare the result against the provided image:

• Layout matches (spacing, alignment, sizing)
• Typography matches (font, size, weight, line height)
• Colors match exactly (from pasted CSS/tokens) or closely (estimated from image, flagged)
• Interactive states work as designed
• Responsive behavior follows the design's intent
• Assets render correctly
• Accessibility standards met

Offer the user a check loop: they render the artifact, screenshot it, and paste it back for a side-by-side diff against the design.

Implementation Rules

Component Organization

• Place UI components in the project's designated design system directory
• Follow the project's component naming conventions
• Avoid inline styles unless truly necessary for dynamic values

Design System Integration

• ALWAYS use components from the project's design system when possible
• Map design tokens from the pasted spec to project design tokens
• When a matching component exists, extend it rather than creating a new one
• Document any new components added to the design system

Code Quality

• Avoid hardcoded values - extract to constants or design tokens
• Keep components composable and reusable
• Add TypeScript types for component props
• Include JSDoc comments for exported components

Examples

Example 1: Button Component

User uploads a button export and pastes its inspect CSS.

1. Read exact padding, radius, typography, and colors from the pasted CSS
2. Check whether the project has an existing button component
3. Extend it with a new variant if so; otherwise create one using project conventions
4. Map the design colors to project tokens (e.g. primary-500, primary-hover)
5. Validate against the export for padding, border radius, typography

Example 2: Dashboard Layout

User uploads a full dashboard frame export.

1. Decompose from the image: header, sidebar, content area, cards
2. Ask for inspect CSS or tokens for the key sections and any icon/logo exports
3. Build the layout with the project's layout primitives
4. Implement each section using existing components where possible
5. Validate each section against the corresponding region of the export, then the whole

Best Practices

• Always start with context. Never implement from assumptions; get the image and the values first.
• Incremental validation. Compare against the design frequently during implementation, not just at the end.
• Document deviations. If you must deviate (accessibility, technical constraints, missing values), say why in code comments.
• Reuse over recreation. Codebase consistency beats literal replication of the design file.
• Design system first. When in doubt, prefer the project's design system patterns over literal translation.

Common Issues and Solutions

• Only an image, no values: implement with estimated values, clearly marked; ask for inspect CSS of the layers that must be exact (brand colors, type sizes).
• Implementation doesn't match: do a side-by-side against the export; check spacing, colors, and typography against the pasted values one property at a time.
• Token conflict: when project tokens differ from the design's values, prefer project tokens for consistency but adjust spacing/sizing minimally to maintain visual fidelity.
• Missing assets: ask the user to export the specific icons/images from the design file rather than approximating with icon libraries.

Usage

/figma-implement-design $ARGUMENTS