image-to-ui-skill

Image to UI Skill

Use this skill to turn UI reference images into an executable image asset plan: first analyze which areas need generated images, then generate, post-process, and integrate them back into the UI.

This file retains routing, the core image-generation boundaries, and the main workflow; detailed rules such as App/web delivery, UI analysis, fonts, dimensions, prompt writing, cutout, integration, interaction, review, gap checking, and the final delivery report have been moved down to references/, to be read as needed (see "Detailed Rules Index" at the end of the document).

image2 image-generation priority rules

When the user explicitly requests "call image2 to generate images", "use image2 to recreate", "make a high-fidelity UI with reference images", or when the effect of the reference image clearly depends on bitmap textures such as photography, illustration, grain, halftone, pixel noise, complex textures, depth of field, real materials, complex islands/maps/characters, etc., you must prioritize the real image2 bitmap generation process, rather than only using HTML/CSS/SVG for an approximation.

In this type of task:

You must first determine which areas belong to must be truly generated as images, and which areas belong to must be implemented in code。
You must generate and land at least one batch of real bitmap assets before you can claim that "image2 has been called".
Do not describe "drew a similar background with CSS", "assembled an illustration with SVG", or "approximated the style with gradients and noise" as having completed image2 image generation.
If you are only building the code skeleton first, you must clearly state that "currently only the structural UI is complete, and image2 has not yet actually been called to generate assets".
If the user wants a high-fidelity recreation, prioritize generating high-impact bitmap assets such as the key visual, route illustrations, card thumbnails, and complex background textures, then make CSS fine-tuning adjustments.

The following content is by default regarded as should prioritize calling image2：

Hero key visuals for seascapes, people, products, and photographic scenes
Complex illustrations with grain, halftone, pixel noise, cyanotype/screen printing, or a scanned feel
Island illustrations, decorative maps, complex coastlines, and non-standard decorative objects in island-hopping route maps
Card thumbnails, scene images, and multiple themed images with a unified art style
Areas where implementing with code would significantly reduce texture quality or make it extremely difficult to approximate the reference image

The following content by default should not be handed to image2：

Titles, body text, prices, button copy, list copy, labels, navigation text
Conventional buttons, input fields, cards, dividers, bottom navigation, conventional icon containers
UI text that needs to remain accessible, translatable, and interactive

image2 call boundaries

In this skill, image2 refers to the project-specified image2 call entry point, and is not equivalent to any arbitrary image generation tool. The current skill also includes a fallback channel: when the native image2 command is unavailable or fails,scripts/image2_asset.py will, inwhen the fallback prerequisites are metautomatically switch to OpenRouter ICU gpt-image-2(for prerequisites, see "Fallback Channel Prerequisites" below). If the prerequisites are not met, the script will clearly report an error with a non-zero code; in this case, you must truthfully state that images have not yet been generated, and must not claim that bitmap assets have been landed.

During execution:

Before any real image generation, first follow references/image2-entrypoint.md Confirm the current project's image2 call entry point and filing channel.
Prefer calling this skill's scripts/image2_asset.py, and do not rewrite the API request yourself.
scripts/image2_asset.py will first try the native image2 command or the IMAGE2_COMMAND environment variable; after failure it automatically calls openrouter-icu-image/scripts/openrouter_icu_image.py, with the model fixed by default to gpt-image-2。
You can record OpenRouter ICU gpt-image-2 as the "image2 filing channel" or "fallback channel", but in the end you must state whether the actual path taken was native-image2 or openrouter-icu-gpt-image-2。
Do not treat the imagegen skill, other image generation plugins, random online image generation services, or handwritten SDK requests as this skill's image2/fallback channel.
If both native image2 and the OpenRouter ICU fallback are unavailable, then stop and explain that there is no available image generation entry point; do not claim that an image has already been generated.
You may continue implementing the code UI skeleton, but you must clearly mark it as "real bitmap asset generation not yet completed", and you must not present code approximations, CSS/SVG visuals, or images from other sources as image2 results.

Filing Channel Prerequisites

OpenRouter ICU gpt-image-2 The filing channel is not unconditionally available.scripts/image2_asset.py Using fallback requires satisfying both:

Able to locate the OpenRouter ICU CLI: install openrouter-icu-image skill in the same-level directory as this skill (the script looks for openrouter-icu-image/scripts/openrouter_icu_image.pyby default), or explicitly set OPENROUTER_ICU_IMAGE_CLI to point to that script. This repository does not include that sibling skill by default; install or configure it separately when needed.
Credentials available: set OPENROUTER_ICU_API_KEY or OPENAI_API_KEY。

When any prerequisite is not satisfied, the script will error with a non-zero code (for example OpenRouter ICU fallback CLI not found, or prompt that an API key needs to be configured), and will not produce a bitmap. In this case, handle it according to "Real Image Generation Verification" below and references/image2-entrypoint.md 's "What to do when no entry point can be found": complete the UI breakdown, asset list, prompts, and code skeleton, clearly mark "real bitmap asset generation not yet completed", and do not use CSS/SVG code approximations to pass them off as image2 results.

Image Generation Commands

In the following commands, <skill-dir> is the actual root directory announced when the skill is loaded. Please replace it with the literal path; it is not an environment variable. Git Bash uses python, and when Windows PowerShell cannot find python , replace it with py -3。

Text-to-image:

python "<skill-dir>/scripts/image2_asset.py" generate \
  --prompt "为 App 首屏生成一张无文字、无 logo 的高级时尚产品主视觉，留出左侧文案空间，柔和自然光，4:3" \
  --output "public/generated/hero-main.png" \
  --size 1536x1024 \
  --quality medium \
  --output-format png

Reference image editing or multi-image reference:

python "<skill-dir>/scripts/image2_asset.py" edit \
  --image "reference.png" \
  --prompt "保留参考图主体轮廓和色彩气质，生成无文字、无 logo 的 UI 卡片缩略图，适合 3:2 裁切" \
  --output "public/generated/card-visual.png" \
  --size 1536x1024 \
  --quality medium \
  --output-format png

Force testing only native image2:

python "<skill-dir>/scripts/image2_asset.py" generate \
  --prompt "test image" \
  --output "output/generated/test.png" \
  --prefer image2

Force using the filing channel:

python "<skill-dir>/scripts/image2_asset.py" generate \
  --prompt "test image" \
  --output "output/generated/test.png" \
  --prefer fallback

OpenRouter ICU fallback requires OPENROUTER_ICU_API_KEY or OPENAI_API_KEY to be available. The script will use the currently installed OpenRouter ICU CLI with the current Python, and will not use py -3。

image2 minimal closed loop

When a task triggers the image2 process, at minimum complete this closed loop:

Break out from the reference images the asset categories that must be image-generated.
Write executable prompts for each asset or group of assets in the same style.
Actually call scripts/image2_asset.py, preferring native image2, and automatically filing OpenRouter ICU if necessary gpt-image-2, producing real bitmap files.
When necessary, perform cropping, slicing, transparency, size correction, or export versions for different slots.
Connect the generated results back to the front-end page, rather than stopping at "generated an image".
Open a screenshot of the real page and verify that these assets have been rendered, rather than stopping at a local folder.
In the final report, list the generated asset paths and clearly state which visual areas have been switched to real generated images.

If steps 1-7 above are not completed, do not describe the task as "replication completed with image2"; instead, accurately describe it as "partially completed image generation" or "image generation preparation only."

Core workflow

Before editing code or generating images, first inspect every UI reference image provided by the user.
Split the UI into:
- Code-rendered UI: layout, text, buttons, cards, simple gradients, borders, shadows, toggles, forms, charts, and repeated components.
- Icon assets: prefer the project's existing icon library or lucide-style vector icons. Generate icons only when the icon is a custom illustrative mark and the design system cannot express it.
- image-to-ui image assets: photos, illustrations, product renders, characters, complex textures, complex hero backgrounds, real objects, App showcase images, decorative bitmaps, and visual content that would be fragile or low-quality if replicated with code.
- Cutout assets: foreground people, products, or objects that need transparent PNG/WebP, masks, or background removal.
First output a pre-review document explaining which elements are easy to reproduce, which elements are difficult to reproduce, which need generated images, and which need user confirmation; if the user has already explicitly requested "just do it" or "just replicate it," you may skip waiting, but you should still complete this breakdown internally first.
After the user confirms the key questions, proceed to image generation; if the user explicitly requests "just continue," you may continue with reasonable assumptions, but record the assumptions.
Output an asset list before generation. The list should include asset id, UI location, target slot size, export size, aspect ratio, generation prompt, post-processing requirements, integration target, and the judgment of whether real image2 generation is required.
Only generate assets that truly require bitmap generation. Structural UI, readable text, and ordinary controls should continue to be implemented in code.
For a group of assets that need a unified style, prioritize the approach of "generate a unified asset board in one pass, then slice and export" to reduce style drift.
Perform post-processing as needed: cropping, scaling, background removal, adding alpha, compression, and size verification.
Integrate the generated assets into the UI, using stable dimensions,object-fit, responsive constraints, alt text, and necessary lazy loading.
Complete the clickable behavior and navigation logic for the page: obvious buttons, links, back/close, cards, tabs, and navigation items should all have real interactions; multi-screen reference images should automatically be chained into a flowable prototype.
Perform a final review of the complete page: check dimensions, garbled text, typography, responsiveness, image embedding, integration with code UI, and whether interactions and navigation are natural.
Compare the final page screenshot with the original UI reference image for gaps, list the differences, fix them, and then take another screenshot for comparison.
If the target is a front-end application, finally verify the effect using rendered screenshots and click paths, and confirm that image2 assets actually appear in the screenshots.

When confirming the image2 call entry point and determining whether real image generation is possible, read references/image2-entrypoint.md. When building the asset list, writing image-to-ui prompts, calculating output dimensions, or planning cutouts/background removal, read references/asset-manifest-and-prompts.md。

When the user wants to turn social media visual trends, Instagram/Pinterest micro-trends, or image creation tools into a usable web page, and cares about launch validation, distribution data, or technical community case studies, they can read references/hicolor-case-study.md as a real project reference.

Real image generation verification

If the task involves image2, the final output must include a piece of "image generation verification" information, containing at least:

Which assets were actually generated
The landing path of each asset
The channel actually used by each asset:native-image2 or openrouter-icu-gpt-image-2
Which page areas have been replaced with real bitmaps
Which areas are still code approximations
What screenshots or page verification methods were used to confirm that these assets are displayed

The following misleading statements are prohibited:

"Completed according to the image2 process", but without any newly generated bitmap files
"Images have been generated", but the images are not connected to the page
"High-fidelity reproduction has been achieved", but all complex visuals are still imitated with CSS/SVG

If the page still mainly relies on code approximations, it must be clearly written as:

"Currently a structural reproduction version, real image2 asset replacement has not yet been completed"
or "Currently only the homepage hero visual has been connected to generated images, the remaining areas are still to be completed"

Detailed rule index

The following detailed rules have all been moved down from this skill to references/, the content is consistent with the previous SKILL.md, read as needed:

references/image2-entrypoint.md — Confirm the image2 call entry point, filing channel, and post-generation verification records.
references/asset-manifest-and-prompts.md — Pre-review templates, asset list templates, image2 prompt templates, page-level checklists.
references/delivery-app-and-web.md — App-form trigger rules (iOS outer frame, Dynamic Island, clickable preview, screenshot verification) and default rules for web delivery.
references/integration-rules.md — UI analysis rules, font recognition and loading, size planning, image-to-ui prompt writing, cutout and background removal, integration rules, interaction and navigation.
references/review-and-gap-check.md — Pre-review and confirmation, common risks and protection, page-level review, original image gap checking and iteration, final delivery report.
references/hicolor-case-study.md — A real project case of turning social media visual trends into a launchable web page.
references/fashion-shopping-app-case-study.md — A case of style reference, multi-screen reproduction, and display mockups for a women's clothing shopping App.
references/museum-app-case-study.md — A case of restoration, linking, and delivery of a multi-screen mobile UI for a museum.