frontend-image-to-implementation

name

frontend-image-to-implementation

description

Use when building or refactoring frontend UI by first inspecting the target project's existing UI and then using the imagegen skill to generate a project-matched UI design mockup. Also use when supporting bitmap assets are needed, such as empty-state illustrations, hero images, thumbnails, and product or scene imagery. This skill requires generating the UI design image from project context before implementation, then coding with project-native sizing, spacing, typography, icons, responsive behavior, and validation instead of copying mockup pixels directly.

Frontend Image To Implementation

Core Rule

First inspect the project's existing UI, then use the imagegen skill to generate a UI design mockup that matches the project.

Use the image as design direction, not pixel truth.

Implement the final UI with the current project's actual scale, spacing, font sizes, border radius, icon system, colors, layout constraints, and responsive rules.

Never copy generated-image dimensions directly when they conflict with the existing project.

Workflow

1. Inspect the target project's existing UI before generating any mockup:
   • common page layouts and navigation
   • input/button/card sizes
   • typography scale
   • icon source
   • color usage and spacing rhythm
   • page width, viewport constraints, and responsive breakpoints
2. Use the imagegen skill to generate a UI design mockup based on the project UI:
   • preserve the project's visual language
   • generate the requested new or refactored UI state
   • if the UI needs supporting visuals, generate or source those asset images too
   • Examples: empty-state illustrations, hero backgrounds, room/product thumbnails, onboarding artwork.
3. Inspect the generated mockup and extract design intent:
   • page hierarchy
   • key components
   • visual mood
   • spacing rhythm
   • primary actions
4. Convert the mockup into project-native UI:
   • reuse existing components and icons
   • adapt controls to local height and radius
   • preserve visual hierarchy, not exact pixels
   • keep copy and interaction states real
   • place generated assets in the project's local public/static asset folder
   • reference local assets from code, not remote temporary URLs
5. Validate with browser screenshots and measured DOM sizes.
6. Iterate from measurements, not guesses.

Hard Requirements

• Do not use the generated UI image as a full-screen bitmap.
• Do not use generated asset images before reviewing semantic fit, crop, clarity, and style match.
• Do not blindly copy image pixel sizes.
• Do not introduce oversized controls unless the project already uses that scale.
• Do not leave accidental vertical scroll on fixed-screen pages.
• Do not allow horizontal overflow.
• Do not leave bottom dead space, clipped controls, or hidden actions.
• Do not mix mockup styling with unrelated project UI patterns.
• Final UI must feel like it belongs to the existing app.

Asset Images

Generate asset images when the mockup depends on visuals that the project does not already have.

Use generated assets for real visual content, not for entire UI screenshots. Typical assets include:

• compact empty-state illustrations
• login or onboarding hero imagery
• room or product thumbnails
• soft decorative scene images that support the page purpose

Before using an asset:

• inspect it visually
• reject images with wrong subject matter, broken objects, unreadable text, distorted products, or mismatched style
• crop and compress as needed for the actual component
• keep dimensions proportional to the target UI, not to the generated mockup
• store it under the project's asset directory and use stable local paths

Mobile Checks

For fixed mobile screens, verify at least:

• 375 x 667
• 390 x 736
• 390 x 844
• 430 x 932

Check:

• no horizontal overflow
• no unintended vertical scroll
• primary action visible
• bottom spacing is intentional
• text fits inputs, buttons, and cards
• UI element sizes match the project

Implementation Notes

If the generated mockup looks good but the coded result feels wrong, prefer the project over the mockup.

Resize and re-space the implementation until it matches the project's established visual system while preserving the mockup's hierarchy and mood.