Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/image-to-code-skill
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific
📊 Stats
Stars80,905
Forks9,349
LanguageTypeScript
LicenseApache-2.0
📦 Ships with open-design
</> SKILL.md
image-to-code-skill.SKILL.md
---name: image-to-code
description: |
Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific images instead of tiny compressed boards, generate fresh standalone images for sections or detail views instead of cropping old ones, avoid lazy under-generation, avoid cards-inside-cards-inside-cards UI, and keep the hero clean, spacious, readable, and visible on a small laptop.
triggers:
- "image to code"
- "reference image to frontend"
- "generate then code"
- "visual implementation"
od:
mode: prototype
surface: web
platform: desktop
scenario: design
category: web-artifacts
upstream: "https://github.com/Leonxlnx/taste-skill"
preview:
type: html
design_system:
requires: true
craft:
requires:
- typography
- color
- anti-ai-slop
example_prompt: |
Use image-to-code: create or analyze visual references first, then implement a responsive website artifact that matches the reference direction closely.
---
`(1 = broad vibe only, 10 = deep extraction of design details)`
- IMAGE_GENERATION_EAGERNESS: 10
`(1 = minimal image count, 10 = generate as many images as needed for excellent extraction)`
- UI_SIMPLICITY_DISCIPLINE: 9
`(1 = willing to add many micro-elements, 10 = aggressively reduce clutter and unnecessary UI chrome)`
AI Instruction:
Use these as defaults unless the user clearly wants something else.
Adapt them to the prompt.
Interpretation:
- If the user says “clean”, reduce density and increase clarity.
- If the user says “crazy creative”, increase variance and art direction.
- If the user says “premium SaaS”, keep clarity high and art direction controlled.
- If the user says “editorial”, allow stronger type and more asymmetry.
- Keep sections breathable.
- Prefer readability over squeezing too much into one image.
- In Codex, bias strongly toward larger, more analyzable section images.
- If more images would improve extraction quality, generate more images.
- Do not be lazy with image count.
- Default away from nested containers, excessive pills, tiny labels, and dashboard clutter.
---
## 2. MANDATORY IMAGE-FIRST RULE
For website design requests where visual quality matters, image generation is mandatory first.
This means:
1. generate the design image or image set yourself first
2. deeply inspect and analyze the generated image(s)
3. extract the design system from them
4. implement the frontend only after that
Do not:
- start with freeform coding
- skip straight to implementation
- describe a website without first generating the visual reference when generation is available
- rely on memory of “good frontend taste” instead of producing the actual reference
The image is the design source.
The code is the translation layer.
---
## 3. GENERATE ENOUGH IMAGES RULE
Generate enough images to make the design truly readable and extractable.
Do not be lazy with image count.
If more images would improve:
- text readability
- typography extraction
- spacing analysis
- button analysis
- card analysis
- color extraction
- component inspection
- implementation fidelity
- responsive understanding
- section clarity
then generate more images.
Strong rule:
- it is better to generate too many clear images than too few compressed images
- it is better to generate one clear image per section than one unreadable board for the whole site
- it is better to create an extra detail image than to guess details later
Never reduce image count just for convenience if that harms quality.
---
## 4. CODEX-SPECIFIC SECTION IMAGE RULE
Inside Codex, do not compress too many website sections into one single image if that would make the text, spacing, buttons, or layout details too small to analyze properly.
In Codex, prefer separate large images per section.
Default rule inside Codex:
- 1 section requested → generate 1 image
- 2 sections requested → generate 2 images
- 3 sections requested → generate 3 images
- 4 sections requested → generate 4 images
- 5 sections requested → generate 5 images
- 6 sections requested → generate 6 images
- 7 sections requested → generate 7 images
- 8 sections requested → generate 8 images
- 9 sections requested → generate 9 images
- 10 sections requested → generate 10 images
- and so on when reasonable
This is preferred because:
- text stays readable
- typography becomes analyzable
- spacing stays visible
- button details stay visible
- layout proportions stay visible
- extraction quality becomes much better
- implementation becomes more faithful
Do not default to:
- one giant multi-column collage
- one long compressed board with tiny unreadable text
- one image containing many sections if that reduces extraction quality
If necessary, generate more images rather than shrinking everything.
Outside Codex, this skill may still allow more compact multi-section composition when appropriate.
Inside Codex, prioritize section clarity and extraction accuracy.
---
## 5. DO NOT CROP OLD IMAGES RULE
When a section needs a dedicated image or a closer detail view, do not simply crop, cut out, zoom into, or slice it from a previously generated larger image.
Do not:
- crop a hero out of a full-page board
- crop a pricing area out of a larger composition
- crop tiny cards out of a multi-section image
- rely on rough cutouts from existing images
- use extracted image fragments as the main source for implementation if they distort spacing, proportions, or typography
Instead:
- generate a fresh new image for that section
- generate a fresh new detail image for that section
- keep the same design language, palette, typography mood, and component family
- make the new image specifically optimized for readability and extraction
Reason:
cropped images often destroy:
- spacing accuracy
- type scale relationships
- clean margins
- layout proportions
- button clarity
- section balance
- overall implementation fidelity
Fresh section-specific generation is strongly preferred over cropping.
---
## 6. FRESH RE-GENERATION RULE
If a section or detail is not clear enough, generate it again as a new standalone image.
This standalone regeneration should:
- preserve the same visual language as the original overall design
- keep the same palette
- keep the same typography mood
- keep the same button style
- keep the same radius logic
- keep the same image treatment
- keep the same overall brand world
But it should also:
- make text larger and more readable
- make spacing more visible
- make buttons easier to inspect
- make component structure easier to analyze
- make layout proportions clearer
- make the section cleaner if the previous render was too busy
This is not a different design.
It is a cleaner, more analyzable section-specific render of the same design system.
---
## 7. OPTIONAL DETAIL / EXTRACTION IMAGE RULE
If a section image still does not expose the necessary detail clearly enough, generate an additional detail image for that same section.
Examples of useful secondary images:
- a closer hero render to read headline, subheadline, CTA, and typography
- a detail image for pricing cards
- a closer render for testimonials
- a closer render for navbar / header treatment
- a closer render for feature cards or UI panels
- a closer render for footer or CTA section
- a refined variation of the first generated image that makes the section more extractable
- a cleaner re-generation of the same section with larger text for extraction
- an image focused mainly on typography and spacing instead of the full composition
These additional images exist to improve analysis and extraction quality.
Use them when needed for:
- readable text
- clearer button states
- tighter spacing analysis
- card and component inspection
- clearer color extraction
- better typography observation
- more precise implementation
Do not hesitate to create a second or third extraction-oriented image for a section if the first image is too broad.
---
## 8. CLEAN ANALYSIS STANDARD
Analyze cleanly and systematically.
Do not do vague vibe-only analysis.
Do not jump too fast from image to code.
For every generated section image, inspect cleanly:
- what the section is
- what the visual priority is
- what text is readable
- what typography relationships are visible
- what spacing relationships are visible
- what buttons and controls are visible
- what card or block logic is visible
- what colors dominate
- what structural rhythm is visible
- what details are still unclear
If something is unclear, generate another image before coding.
The analysis should feel:
- calm
- structured
- exact
- faithful
- design-aware
- implementation-aware
---
## 9. DEEP IMAGE ANALYSIS REQUIREMENT
Before implementing anything, deeply analyze the generated image(s).
Do not just glance at them.
Treat them like a design specification.
Carefully inspect and extract:
- exact visible text where readable
- hero headline wording
- subheadline wording
- CTA wording
- section titles
- typography character
- type scale relationships
- font mood
- line count
- line wrapping behavior
- alignment logic
- section spacing
- internal spacing
- padding and gutters
- card dimensions and rhythm
- border radius logic
- stroke / divider usage
- button shapes
- button hierarchy
- button padding
- hover-implied styling if visually suggested
- color palette
- accent colors
- background treatment
- image treatment
- icon treatment
- shadows / depth logic
- grid logic
- layout structure
- section ordering
- section density
- visual rhythm
- repeated motifs that define the design language
Your goal is to understand exactly why the generated website looks strong.
Only after this deep analysis should you implement the frontend.
---
## 10. IMAGE-FIRST CODEX WEBSITE WORKFLOW
When this skill is used inside Codex or any environment that supports image generation plus implementation, default to an image-first workflow for website design tasks.
Preferred execution order:
1. infer the section count
2. generate section reference images first
3. generate extra detail/extraction images where needed
4. if needed, regenerate unclear sections as fresh standalone images
- if one section is still unclear, regenerate that section again cleanly instead of cropping
- keep sections open and not overboxed
- then implement the full site from those references
### Example 3
User:
“make a premium creative agency website with 4 sections”
Interpretation:
- generate 4 separate section images in Codex
- keep the hero very clean
- ensure text remains readable
- deeply analyze each section
- do not use rough cutouts from the first renders
- regenerate clearer section images if needed
- avoid over-pilled microcopy and container overload
- then implement the site from those 4 references
---
## 38. FINAL GOAL
Generate website reference images that feel:
- premium
- art-directed
- clear
- structured
- readable
- analyzable
- memorable
- anti-generic
- implementation-friendly
For visual website work, the skill must first generate the image(s) itself, then deeply and cleanly analyze those generated image(s), then use them as the primary visual source, then build the frontend to match them closely.
Inside Codex, if the user wants multiple sections, prefer separate large section images instead of one compressed multi-section board, so text, spacing, typography, buttons, and colors can be extracted properly.
If a section still needs more clarity, generate an additional extraction-oriented image for that section.
If more images would improve quality, generate more images.
Do not be lazy with image count.
Do not crop previously generated images when a fresh section-specific image would preserve spacing, layout, and readability better.
Generate a new clean image instead.
Avoid cards-inside-cards-inside-cards.
Avoid giant boxed wrappers around every section.
Avoid fake technical pills and decorative micro-labels.
Keep the hero especially clean, spacious, restrained, and readable on a small laptop.
The result should be:
- strong as section images
- strong as a design system
- strong under deep analysis
- and strong as implemented frontend
The final outcome should look like a top-tier website concept translated faithfully into real code, not a tiny unreadable design board and not a generic coded reinterpretation.
