design-to-web · diff
git:20261007.aef2817 to git:20261007.a99fc21
35 added, 19 removed. Audit A to A.
---
name: design-to-web
- description: "Turns a Figma design into a polished, accessible web component: exact tokens via the Figma MCP server, pixel-faithful build with every state, spring motion, Playwright verification. Use when the user says /design-to-web, 'implement this Figma', 'make it feel native' or 'pixel-perfect'."
+ description: "Builds a polished, accessible web component or screen from a mockup image, a description or the project's design system: exact tokens, every state, spring motion, Playwright verification. Use when the user says /design-to-web, 'make it feel native', 'pixel-perfect' or 'build this from the mockup'."
model: claude-opus-5-5
context: fork
---
# Design to Web
- You are the bridge between a strict design and the interactive experience people use. The Figma file is the spec; the browser is the proof. Nothing ships on the default state alone, and nothing ships unverified.
+ You are the bridge between a design and the interactive experience people use. The design is the spec; the browser is the proof. Nothing ships on the default state alone, and nothing ships unverified.
- ## Workflow
+ This skill runs in a forked context on Claude Opus 5.5 (`model` and `context: fork` in the frontmatter), whatever model the main session uses; subagents it launches use the default subagent model. A forked skill does not see the conversation: everything it needs comes in its arguments. If something essential is missing, stop and return the question for the user instead of guessing.
- Run the four steps in order. Each one has its own skill with the details; this skill is the conductor.
+ ## Workflow
- | Step | Skill | Done when |
+ | Step | How | Done when |
| --- | --- | --- |
- | 1. Extract | `figma-to-code` | A token table (colors, spacing, type, radii, shadows) read from Figma, not guessed, in one Figma read (two at most), cached for later |
- | 2. Build | this skill, section below | Semantic, accessible markup with every state implemented |
- | 3. Motion | `motion-direction`, then `motion-design` | One motion personality with its timing and choreography, built with springs on `transform` and `opacity`, with a `prefers-reduced-motion` fallback |
- | 4. Verify | `ui-states-verification` | Playwright has driven every state and compared it against the cached Figma screenshot |
+ | 1. Source | section below | A token table taken from the project's tokens, with every value the design needs |
+ | 2. Build | "Build standard" below | Semantic, accessible markup with every state implemented |
+ | 3. Motion | `motion-direction`, then `motion-design` | One motion personality with its timing, built with springs on `transform` and `opacity`, with a `prefers-reduced-motion` fallback |
+ | 4. Verify | `ui-states-verification` | Playwright has driven every state, and compared it with the reference image when there is one |
- This skill and the other design skills run in a forked context on Claude Opus 5.5 (`model` and `context: fork` in the frontmatter), whatever model the main session uses; subagents they launch use the default subagent model. A forked skill does not see the conversation: everything it needs comes in its arguments. If something essential is missing, such as a Figma link with `node-id`, stop and return the question for the user instead of guessing.
+ Start the reply with the usual `⚡ GOD` line when invoked through `/god`; otherwise open with the token table from step 1.
- Figma reads are scarce (20 per month on the Starter plan): only `figma-to-code` reads from Figma, and every later step works from its cache. Steps 2 to 4 never call a Figma tool.
+ ## 1. Source
- Before step 1, confirm the Figma MCP server is connected. If it is not, do not estimate values from a screenshot: stop and show the user how to connect it (see `figma-to-code`). Connecting an MCP server is an external install under the protocol's autonomy limits, so wait for their "yes".
+ The design comes from one of three places, in this order:
- Start the reply with the usual `⚡ GOD` line when invoked through `/god`; otherwise open with the token table from step 1.
+ 1. **A reference image**: a screenshot or mockup saved as a file, passed by its path (`design/checkout.png`). Open it with the Read tool. An image pasted into the chat does not reach this skill: if the request mentions an image and gives no path, ask the user to save it in the project and send the path.
+ 2. **The project's design system**: CSS custom properties, the Tailwind config, a theme file or existing components. Read them before writing any value.
+ 3. **A description** in the request ("a pricing card like the one on the home page, with a monthly and yearly toggle").
+ Then write the token table:
+
+ | Token | Project token | Value | Used by |
+ | --- | --- | --- | --- |
+ | Primary | `--color-brand-500` | `#2563EB` | button background |
+ | Space 3 | `spacing.3` | `12px` (`0.75rem`) | button padding-y |
+ | Radius md | `--radius-md` | `8px` | button |
+
+ Rules for the table:
+
+ - Every value maps to a token the project already has. Never create a second token for a value the project already defines.
+ - A value read off an image is an estimate. Map it to the closest existing token and mark it `≈` in the table; if no token is close, say so on the first line of the reply and let the user decide.
+ - If the project has no design system, propose a small token set (color, space, type, radius, shadow) and use it everywhere instead of raw values.
+
## Build standard
- - **The design is the law.** Match the extracted tokens exactly: sub-pixel alignment, vertical rhythm, line-height, letter-spacing. Where the design is ambiguous, say so and pick the closest token already in the file instead of inventing one.
+ - **The design is the law.** Match the reference: alignment, vertical rhythm, line-height, letter-spacing. Where the design is ambiguous, say so and pick the closest existing token instead of inventing one.
- **Semantic and accessible.** Native elements first (`button`, `a`, `input`, `dialog`), then ARIA only to fill gaps. Keyboard reachable, visible `focus-visible` ring, labels and names for assistive tech, color contrast at least 4.5:1 for text.
- - **Every state, always.** `default`, `hover`, `active`, `focus-visible`, `disabled`, `loading`, and `error` or `empty` where the component has data. A component delivered with fewer states is unfinished.
+ - **Every state, always.** `default`, `hover`, `active`, `focus-visible`, `disabled`, `loading`, and `error` or `empty` where the component has data. A state the design does not show is built from the closest token and listed in the reply.
- **Touch targets of at least 44×44 px.** When the visual element is smaller, grow the hit area with padding or a pseudo-element, never the visible shape.
- **Composition-only animation.** Animate `transform` and `opacity`; never `width`, `height`, `top`, `left`, `margin` or `box-shadow` on interaction. Promote layers with `will-change` only while they animate.
- - **Design-system first.** If the project already has tokens or components, map Figma variables to them instead of hard-coding values. For components with no Figma source, use `frontend-ui-engineering` instead of this skill.
+ - **Design-system first.** Reuse the project's components before writing new ones.
## Deliverable
- 1. The token table from Figma, with the Figma variable name next to each value, and the Figma reads used (`Figma: 1 lectura`).
+ 1. The token table, with `≈` on every value estimated from an image.
2. The component, with its states, in the project's framework and styling convention.
3. The motion spec: which elements move, with which spring parameters, and what happens under reduced motion.
- 4. The Playwright verification: a per-state screenshot set and the checks that passed, with any mismatch against Figma listed on the first line of the reply.
+ 4. The Playwright verification: a per-state screenshot set and the checks that passed, with any mismatch against the reference listed on the first line of the reply.
- Report what the tools showed. If Figma could not be read, Playwright could not run, or a state failed, that goes first, never in the summary.
+ Report what the tools showed. If the image could not be read, Playwright could not run, or a state failed, that goes first, never in the summary.