image-to-code

name	image-to-code
description	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.
origin	adapted:taste-skill
license	MIT © 2026 Leonxlnx
version	1.0.0
compatibility	React/JSX output by default. Mention stack preference to get Vue, HTML, or other output.

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

• Confirm the image is visible and has sufficient resolution to analyze layout
• Confirm the target stack (React, Vue, plain HTML) — default to React/JSX if not stated
• Confirm whether to use a CSS framework (Tailwind, CSS Modules, styled-components) — default to Tailwind if project uses it

How It Works

1. Analyze the image — identify: layout grid, component boundaries, spacing rhythm, color palette, typography hierarchy, interactive elements
2. Decompose into components — name each logical piece (Card, Header, NavItem, Badge, etc.)
3. Map spacing — convert visual spacing to a consistent scale (4px/8px base); estimate if pixel values are not given
4. Extract colors — identify background, surface, text, accent, border colors; name them semantically
5. Identify interactive states — note buttons, links, inputs; mark which states are shown vs assumed
6. Write the component hierarchy — top-level layout wrapper first, then nested components
7. Output the code — semantic HTML structure, accessible roles and labels, responsive considerations noted
8. 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:

• Component list — all major visual regions named and accounted for
• Assumptions list — all inferred values flagged (fonts, exact px, hidden states)
• Code output shown — not just a plan or description
• At least one responsive consideration noted (or explicitly stated as out of scope)

Reference: gates/anti-fake-pass-gate.md