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'.
Installs into .claude/skills of the current project.
Are you the author of Design To Web?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/gastonchevarria-design-to-web)
---
name: design-to-web
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 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.
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.
## Workflow
| Step | How | Done when |
| --- | --- | --- |
| 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 |
Start the reply with the usual `⚡ GOD` line when invoked through `/god`; otherwise open with the token table from step 1.
## 1. Source
The design comes from one of three places, in this order:
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 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 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.** Reuse the project's components before writing new ones.
## Deliverable
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 the reference listed on the first line of the reply.
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.