When to Use
- Use when: user uploads an image or screenshot and asks to implement it as code
- Use when: user pastes a Figma/design URL description and wants the layout coded
- Use when: user says "match this", "replicate this UI", "build exactly what's shown"
- Do NOT use when: no image is provided — use
design-taste-frontend for improvements from description only
- Do NOT use when: image contains sensitive/personal data — flag it and ask for a redacted version
Pre-conditions
How It Works
- Analyze the image — identify: layout grid, component boundaries, spacing rhythm, color palette, typography hierarchy, interactive elements
- Decompose into components — name each logical piece (Card, Header, NavItem, Badge, etc.)
- Map spacing — convert visual spacing to a consistent scale (4px/8px base); estimate if pixel values are not given
- Extract colors — identify background, surface, text, accent, border colors; name them semantically
- Identify interactive states — note buttons, links, inputs; mark which states are shown vs assumed
- Write the component hierarchy — top-level layout wrapper first, then nested components
- Output the code — semantic HTML structure, accessible roles and labels, responsive considerations noted
- Flag assumptions — list any visual detail that was estimated, not clearly visible, or left as TODO
Output Format
## Component: [Name]
[Description — what this component does]
## Assumptions
- [Visual detail inferred, not clearly visible]
- [State assumed but not shown in image]
## Code
[component code]
If multiple components: output one block per component, ordered parent → child.
Gotchas
- Do not hallucinate exact font names or pixel values — use estimates and flag them
- If the image shows only one state (e.g., default), generate only that state; add a
// TODO: hover/active/disabled states comment
- Images often compress gradients — treat subtle color differences as flat backgrounds unless clearly a gradient
- Accessibility: any text in the image that is decorative gets
aria-hidden; text that is content gets proper alt or label
- Do not output inline styles unless the framework requires it — prefer class-based styling
Anti-Fake-Pass Rules
Before claiming the implementation is done, you MUST show:
Reference: gates/anti-fake-pass-gate.md
1---2name: image-to-code3description: Convert a UI screenshot, mockup, or design image into production-quality frontend code. Analyzes layout, spacing, component hierarchy, and visual states from the image, then outputs clean, semantic code. Use when the user provides an image/screenshot and asks to "code this", "build this UI", "implement this design", or "turn this into a component". Do NOT use for generating new designs — only for converting existing visuals to code.4license: MIT © 2026 Leonxlnx5---6
7<!-- Adapted from taste-skill (MIT © 2026 Leonxlnx). Changes: added YAMTAM origin/Anti-Fake-Pass/compatibility fields, removed GPT-specific behavior, generalized to any frontend stack. -->
8
9## When to Use
10
11- Use when: user uploads an image or screenshot and asks to implement it as code
12- Use when: user pastes a Figma/design URL description and wants the layout coded
13- Use when: user says "match this", "replicate this UI", "build exactly what's shown"
14- Do NOT use when: no image is provided — use `design-taste-frontend` for improvements from description only
15- Do NOT use when: image contains sensitive/personal data — flag it and ask for a redacted version
16
17## Pre-conditions
18
19- [ ] Confirm the image is visible and has sufficient resolution to analyze layout
20- [ ] Confirm the target stack (React, Vue, plain HTML) — default to React/JSX if not stated
21- [ ] Confirm whether to use a CSS framework (Tailwind, CSS Modules, styled-components) — default to Tailwind if project uses it
22
23## How It Works
24
251. **Analyze the image** — identify: layout grid, component boundaries, spacing rhythm, color palette, typography hierarchy, interactive elements
262. **Decompose into components** — name each logical piece (Card, Header, NavItem, Badge, etc.)
273. **Map spacing** — convert visual spacing to a consistent scale (4px/8px base); estimate if pixel values are not given
284. **Extract colors** — identify background, surface, text, accent, border colors; name them semantically
295. **Identify interactive states** — note buttons, links, inputs; mark which states are shown vs assumed
306. **Write the component hierarchy** — top-level layout wrapper first, then nested components
317. **Output the code** — semantic HTML structure, accessible roles and labels, responsive considerations noted
328. **Flag assumptions** — list any visual detail that was estimated, not clearly visible, or left as TODO
33
34## Output Format
35
36```
37## Component: [Name]
38[Description — what this component does]
39
40## Assumptions
41- [Visual detail inferred, not clearly visible]
42- [State assumed but not shown in image]
43
44## Code
45[component code]
46```
47
48If multiple components: output one block per component, ordered parent → child.
49
50## Gotchas
51
52- Do not hallucinate exact font names or pixel values — use estimates and flag them
53- If the image shows only one state (e.g., default), generate only that state; add a `// TODO: hover/active/disabled states` comment
54- Images often compress gradients — treat subtle color differences as flat backgrounds unless clearly a gradient
55- Accessibility: any text in the image that is decorative gets `aria-hidden`; text that is content gets proper `alt` or label
56- Do not output inline styles unless the framework requires it — prefer class-based styling
57
58## Anti-Fake-Pass Rules
59
60Before claiming the implementation is done, you MUST show:
61- [ ] Component list — all major visual regions named and accounted for
62- [ ] Assumptions list — all inferred values flagged (fonts, exact px, hidden states)
63- [ ] Code output shown — not just a plan or description
64- [ ] At least one responsive consideration noted (or explicitly stated as out of scope)
65
66Reference: `gates/anti-fake-pass-gate.md`
yanacuti1121