Translate UI/UX designs into production-ready, accessible, responsive
frontend code. This skill turns an agent into a design-aware implementation
engine that extracts design tokens, maps component hierarchies, applies
accessibility standards, and produces framework-appropriate code — not just
a design export.
Accessible markup, ARIA, focus management, color contrast
🛠️ Implement
Generate framework-appropriate code
Component files, styles, tests
🧪 Verify
Visual regression testing and design QA
Test snapshots, diff reports, checklist
Quality Tiers:
💎 Production — Accessible, responsive, tested, framework-native, token-driven
🥈 MVP — Functional across breakpoints, basic accessibility, inline styles OK for speed
🥉 Prototype — Single viewport, minimal accessibility, rapid iteration
When to Use This Skill
Activate this skill when the user asks you to:
"Turn this Figma design into code" / "Convert this mockup to React/Vue/Svelte"
"Implement this design" / "Build this UI from this screenshot"
"Extract design tokens from this Figma file" / "Create a design system from these specs"
"Make this design responsive" / "Add responsive breakpoints to this layout"
"Make this component accessible" / "Ensure WCAG 2.1 AA compliance"
"Set up a component from this Sketch/XD design"
"Create a pixel-perfect implementation of this design"
"Integrate this design with our existing design system"
"Set up visual regression tests for these components"
Any request containing "design" + "code", "implement", "build", "convert", or "translate"
Additionally, activate proactively when a conversation includes a design
artifact (Figma link, screenshot, design spec) and the user's intent is
implementation.
Do NOT Activate For
The following inputs are near-miss negatives — they mention design or
code language but are not design-to-code tasks:
Pure code generation without a design: "Write a React form component" — no visual design input, so plain coding.
Design critique/review: "What do you think of this design?" — opinion, not implementation.
Pure accessibility audit without implementation: "Audit this page for accessibility" — audit, not design-to-code.
Design tool usage questions: "How do I create an auto-layout in Figma?" — tool instruction, not code generation.
Backend/styling-less code: "Build a REST API for user management" — no visual design involved.
Pure CSS framework questions: "What's better, Tailwind or CSS Modules?" — opinion, not implementation.
Animating existing components: "Add a fade-in animation to this button" — micro-interaction on existing code, not a full design translation.
Logo/brand asset generation: "Create an SVG logo based on this brief" — graphic design output, not frontend implementation.
Design token management without code: "Organize our design tokens in Figma" — design tool work, not code.
When in doubt, ask: "Do you have a design you want me to translate into
code, or are you asking me to work directly with code/design concepts?"
Common Pitfalls & Anti-Patterns
❌ Implementer Anti-Patterns
Skipping the design analysis phase — Jumping straight to code without
understanding the design's intent, hierarchy, and reusable patterns. Always
ingest and analyze before you code.
Hardcoding design values — Using raw pixel values (color: #3B82F6)
instead of design tokens (color: var(--color-primary-500)). Token-driven
code is maintainable; hardcoded values rot.
Accessibility as an afterthought — Adding ARIA at the end rather than
building accessible from the start. Retrofit accessibility is always
incomplete.
Responsive as a second pass — Implementing desktop-first then
"making it responsive" leads to fragile media-query spaghetti. Plan
breakpoints and layout strategy before writing a single rule.
Div-soup markup — Nesting <div> inside <div> rather than using
semantic HTML (<nav>, <main>, <section>, <article>, <aside>).
Semantic elements are free accessibility and SEO wins.
Over-engineering the component tree — Creating 12 components for a
simple card because "atomic design says so." Map hierarchy to what the
design actually calls for, not an ideology.
Copying Figma auto-layout directly — Figma's stacking model doesn't
always map 1:1 to CSS Flexbox/Grid. Translate the intent, not the
implementation.
Ignoring existing design system tokens — Using colors/spacing that
diverge from the project's token set. "Close enough" values accumulate
into an inconsistent codebase.
Testing only one viewport — Verifying at 1440px and calling it done.
Every breakpoint, every browser, every component state needs verification.
Skipping visual regression testing — Assuming your implementation
matches the design because it "looks right." Screenshot diffs catch
what the human eye misses.
✅ Implementation Quality Checklist
Before declaring a design-to-code task complete, verify:
All design sources were ingested and analyzed
Design tokens are extracted and referenced as CSS custom properties or token variables
Component hierarchy matches the design's visual hierarchy
All defined breakpoints have been implemented and tested
WCAG 2.1 AA compliance verified (contrast, focus, labels, semantics)
Framework conventions followed (component structure, styling approach)
No hardcoded design values — all through tokens
Visual regression baselines captured and tests pass
Component states accounted for (hover, focus, active, disabled, loading, empty, error)
Keyboard navigation works end-to-end
Screen reader announcement is meaningful
Dark mode / theme variants considered (if applicable)
Workflow
Phase 1: Ingest the Design Source
Identify the design source type:
Figma: Extract via Figma API, Figma plugin export, or screenshot +
manual annotation. For API access, use the Figma file key and node IDs.
Sketch: Parse .sketch files (they are ZIP archives with JSON inside).
Extract via unzip and read document.json + pages/.
Adobe XD: Export via XD plugin or Adobe's Design Automation API.
Screenshots / image files: Use image analysis (vision model) to
identify layout, colors, typography, spacing, and components. If a
screenshot is the only input, acknowledge the precision limitation.
Design specs / redlines: Parse spec documents for explicit
measurements, colors, and type scales.
Normalize the design data. Regardless of source, produce:
Color palette — all named colors with hex/RGB/HSL values
Typography scale — font families, sizes, weights, line heights,
letter spacing per text style
Spacing scale — consistent spacing units (4px/8px base recommended)
Shadow definitions — box-shadow values per elevation level
Border radii — consistent corner radius tokens
Component inventory — every distinct UI element, its states, and
how it repeats
If the design source is incomplete (screenshot, rough mockup), ask the
user for clarification on:
Exact color values (approximated from a screenshot may be off)
Font family names (not guessable from a screenshot)
Interactive states not visible in a static image
Responsive behaviour at different breakpoints
Phase 2: Extract and Define Design Tokens
Extract a structured token system. Use CSS custom properties as the canonical
format and derive framework-specific versions.
States — default, hover, focus, active, disabled, loading, empty,
error (list all that apply)
Variants — primary/secondary for buttons, compact/default/expanded
for cards, etc.
Slots/children — where does content get injected
Responsive behaviour — how does it change at each breakpoint
Identify shared/reusable patterns:
Buttons, inputs, cards, avatars — extract as base components
Layout primitives — Container, Grid, Stack, Flex
Typography components — Heading, Text, Caption
For each reusable component, check if an equivalent exists in the
project's design system. If yes, extend it rather than creating a new one.
Phase 4: Define Responsive Breakpoint Strategy
Choose a breakpoint system:
Mobile-first (recommended): Start at the smallest viewport and add
complexity as screen size increases. Use min-width media queries.
Desktop-first: Start at the largest viewport and simplify for
smaller screens. Use max-width media queries. Less common but valid
for desktop-heavy applications.
Define breakpoint values. Common breakpoints:
Name
Width
Typical Device
xs
0px+
All phones
sm
640px+
Large phones, small tablets
md
768px+
Tablets
lg
1024px+
Small laptops, large tablets landscape
xl
1280px+
Desktops
2xl
1536px+
Large desktops
For each breakpoint, document layout changes:
Component
< 640px
640–1024px
> 1024px
Navigation
Hamburger menu
Hamburger menu
Horizontal nav
FeatureGrid
1 column
2 columns
3 columns
HeroBanner
Stacked (image below text)
Stacked
Side-by-side
Sidebar
Hidden, toggle overlay
Collapsible
Persistent
Implement responsive utilities. Create CSS custom properties or
utility classes for media queries. For Tailwind, use the built-in
breakpoint prefixes (sm:, md:, lg:, xl:).
Test at every breakpoint. Do not trust that a component will work at
intermediate sizes. 720px can expose layout bugs that 640px and 768px
hide.
Phase 5: Accessibility-First Implementation
Minimum standard: WCAG 2.1 Level AA. If the user's project requires AAA,
escalate accordingly.
5.1 Semantic HTML
Use the correct HTML element for every piece of content. This is the
single highest-impact accessibility decision.
Content
Correct Element
Avoid
Page header
<header>
<div class="header">
Primary navigation
<nav aria-label="Main">
<div class="nav">
Main content
<main>
<div class="content">
Standalone sections
<section> (with heading)
<div>
Articles / blog posts
<article>
<div>
Sidebar / complementary
<aside>
<div>
Page footer
<footer>
<div class="footer">
Data tables
<table>, <thead>, <tbody>, <th scope="">
<div> grid
Lists of items
<ul>, <ol>, <li>
<div> repeated
Buttons that perform actions
<button>
<div onclick="">
Links that navigate
<a href="">
<button onclick="navigate()">
Images with meaning
<img alt="description">
<img> (missing alt)
Decorative images
<img alt="">
<img alt="icon">
Form inputs
<label> + <input> paired with for/id
Placeholder-only inputs
Headings
<h1>–<h6> in logical order (no skips)
<div class="heading">
Figures with captions
<figure> + <figcaption>
<div> + <p>
5.2 ARIA — Use Only When HTML Isn't Enough
First rule of ARIA: don't use ARIA if native HTML can do it. ARIA adds
complexity and is easy to get wrong.
Text contrast ratio: 4.5:1 minimum for normal text, 3:1 for large text
(18px+ bold or 24px+ regular). WCAG AA requirement.
Non-text contrast: 3:1 minimum for UI components and graphical objects
(button borders, input borders, icons).
Never use color alone to convey information. Error states need both
red color AND an icon/text indicator. Links need underlines (not just
color change).
Focus indicators: Every interactive element must have a visible focus
style. Default outline is fine; custom focus rings must have 3:1
contrast against adjacent colors. :focus-visible is preferred over
:focus for mouse users.
Tab order must follow visual order. Avoid positive tabindex values;
use tabindex="0" to add to the natural order or tabindex="-1" for
programmatic focus only.
Interactive elements must be reachable and operable via keyboard:
buttons, links, form controls, custom widgets.
Skip links: Provide a "Skip to main content" link as the first
focusable element.
Modals: Trap focus inside the modal while open. Restore focus to the
trigger element on close.
When the project has an existing design system, integrate without disruption.
Audit the existing system — what tokens, components, and patterns
already exist?
Map new design elements to existing tokens:
If the design uses a color that matches --color-primary-500, use it.
If the design introduces a new color not in the system, flag it:
"This design specifies #7C3AED which is not in our design system.
The closest existing token is --color-secondary-600 (#7C3AED is
an exact match to our secondary-600 — recommend using it)."
Extend components rather than creating duplicates. If a Card
component exists but the design needs a slightly different variant,
add a prop rather than creating SpecialCard.
If the design contradicts the design system, flag the discrepancy
and ask whether the design should change or the design system should
be updated.
Token synchronization — If the project has a token pipeline (e.g.,
Style Dictionary → CSS + JS + Tailwind config), update the source of
truth, not the generated files.
Safety Rules
ABSOLUTE RULES — never violate these:
Respect intellectual property. Never reproduce copyrighted designs,
illustrations, logos, or brand assets without explicit permission or
license. If a user provides a design from Dribbble, Behance, or a
competitor's website and asks you to clone it, refuse: "I cannot
reproduce this design because it appears to be copyrighted/owned by
[entity]. I can help you create an original design inspired by UI
patterns but not a direct copy."
Never ship hardcoded secrets. If a design includes API keys,
tokens, or credentials in code examples, flag them and strip them.
Use environment variables.
Always use HTTPS for external assets (fonts, images, CDN resources).
Mixed content is a security risk.
Respect user privacy. Don't add third-party trackers, analytics,
or telemetry to generated code without the user's explicit request.
Screen readers and accessibility tools must not be blocked.
Be honest about fidelity. When working from a screenshot (not a
design file), preface output with: "I'm working from a screenshot,
so colors and exact measurements are approximate. Please verify
the following values against your design spec."
Don't silently replace the design intent. If the design has a
complex interaction that would be expensive to implement, don't
simplify it without asking. Say: "This carousel pattern would take
~4 hours to implement with full accessibility. A simpler tabbed
layout would take ~1 hour. Which do you prefer?"
Accessibility is non-negotiable. Every implementation must meet
WCAG 2.1 AA at minimum. If the user explicitly asks to skip
accessibility, warn them but comply with the caveat noted.
Don't generate inaccessibly. Never produce code with outline: none
without a replacement focus indicator. Never use tabindex values
greater than 0. Never skip heading levels or use non-semantic markup
where semantic elements exist.
Platform Compatibility Notes
This skill is designed to work across AI coding platforms with minor
adaptations:
Platform
Notes
Claude Code
Figma API integration works well. Can parse design JSON. Good for token extraction pipelines.
Codex (OpenAI)
Strong at component generation. Paste design specs or describe the design verbally. Screenshot analysis works well.
Cursor
Can read existing codebase for design system context. File system access helps with token integration.
Gemini CLI
Large context window useful for ingesting full design specs. Use web_fetch for Figma API.
OpenClaw
Exec for Figma CLI/API calls. GitHub skill for PR-based design review. Image analysis for screenshots.
GitHub Copilot
Works within IDE context. Best for incremental component implementation with existing design system access.
Windsurf
Can access workspace files and design assets. Execute design-to-code in context of existing project.
OpenCode
Terminal-based. Best with explicit design specs pasted or described textually. Can run token extraction scripts.
Platform-Specific Adjustments
If Figma API token is unavailable: ask the user to export the design as
SVG/PNG or paste a design spec document. Screenshot analysis is the fallback.
If image/vision analysis is not available: ask the user to describe the
design in text (layout, colors, typography, spacing). Work from description.
If a specific framework is not specified: default to the framework the
project already uses. If no project exists, ask the user.
For Discord/Slack delivery: use bullet lists, not markdown tables. Split
large code blocks across multiple messages. Wrap links in <>.
For platforms without file system access: inline tokens and styles
directly in generated output rather than referencing external files.
References
references/design-tokens-guide.md — W3C Design Tokens Community Group
specification and implementation guide
