build-from-image

name	build-from-image
description	Activate when visual quality is central to a frontend task and image generation is available — generate design reference images first, analyze them thoroughly, then implement the frontend from those references.
version	1
category	frontend-code
outputs	images + code

Build From Image

Purpose

This skill enforces an image-first workflow for web UI tasks where visual quality matters. Rather than designing in code from scratch, the agent generates design reference images, performs a structured analysis of those images, and then implements the frontend as a faithful translation of the analyzed design. The goal is to prevent the generic "coded from memory" output that produces repetitive SaaS patterns by making the visual reference the primary source of truth.

When to Activate

• Image generation is available AND the task is visually important
• User requests a landing page, hero section, marketing site, or product showcase
• User describes the output primarily in visual terms ("beautiful," "premium," "creative")
• User wants a multi-section website where section-by-section image analysis would improve quality
• User asks to redesign or improve a site's aesthetic quality

When Not to Activate

• Image generation is not available in the current environment (use frontend directly)
• The task is primarily technical (bug fix, API integration, data processing)
• The user has already provided a precise design system to follow
• The task is a minor component addition where visual quality is not the focus

Core Principles

1. Images are generated before code is written. For visually important tasks, no frontend code is written until at least one reference image has been generated and analyzed. Describing what the site "could look like" without generating the image is not a substitute.

2. Section count drives image count. Generate one image per section. One section = one image. Do not compress multiple sections into one board to save generation time.

3. Fresh images replace crops. When a section needs clearer detail, generate a new standalone image at a larger, cleaner scale. Do not crop, zoom, or extract a region from a previously generated image — crops destroy spacing relationships and type proportions.

4. Analysis is systematic, not impressionistic. After generating images, extract: visible text, type scale relationships, spacing behavior, button shapes, color palette, grid structure, component family. Do not proceed to code if the analysis is vague.

5. Implementation follows the reference, not memory. The coded output should look like the generated reference was translated into HTML/CSS — not like the reference "inspired" a different design. Visual drift from the reference is a failure.

6. Multi-section consistency is mandatory. Every generated section image must share the same palette, type family, CTA style, border-radius logic, and image treatment. A viewer scrolling through all images should see one website.

7. The hero must work at 1280px wide. The first section must be clean and readable at a standard laptop width — not only at full-screen.

Configuration

Parameter	Scale	Default
DESIGN_VARIANCE	1–10	8
VISUAL_DENSITY	1–10	3
IMAGE_GENERATION_EAGERNESS	1–10	10 (always generate more, not fewer)
IMPLEMENTATION_FIDELITY	1–10	9 (stay close to generated references)

Workflow

1. Determine section count. Read the user's request. Identify how many distinct sections are needed. Default for "a website": 4–8 sections.

2. Generate section images. One image per section in 16:9 or 16:10 horizontal format. If text in a generated image is too small to read, generate a dedicated detail image for that section at a larger scale.

3. Verify image quality before analysis. For each image: is the text readable? Are spacing relationships visible? Are button shapes clear? If any image fails these checks, regenerate it freshly. Do not proceed with an unreadable image.

4. Analyze each image systematically. For every image, extract and document:

   • Visible text: headline wording, subheadline, CTA labels, section titles
   • Typography: size relationships, weight contrast, line count, line-height feel
   • Spacing: section top/bottom padding, internal card padding, element gaps
   • Color palette: background, panels, accent, text hierarchy, border values
   • Components: button shape and radius, card structure, badge usage
   • Layout: grid structure, composition anchor (centered / left / asymmetric / image-led)

5. Define the implementation plan. From the analysis: establish the type scale, spacing scale, color tokens, and component set. This plan bridges the reference images and the code.

6. Implement from the plan. Write the frontend code section by section. At each section, compare the coded output against the corresponding reference image. Correct deviations before moving to the next section.

7. Apply the anti-drift check. Before delivering: scan the implementation for sections that look like generic templates instead of the generated references. Revise any drifted sections.

Forbidden Patterns

In image generation:

• Multiple sections compressed into one tall image
• Cropping a detail from a previously generated image
• Accepting images where body text or button labels are too small to read
• Generating fewer images than there are sections

In implementation:

• Beginning with freeform code before generating images
• Implementing a different design than what the images show
• Replacing distinctive reference sections with generic patterns
• Collapsing generous spacing from the references into tight default layout
• Adding components or patterns that were not visible in the references

Design patterns to avoid in generated images:

• Centered dark hero with purple/blue gradient as the default for every AI product
• Identical card rows in every section
• Cards inside cards inside cards
• Giant rounded section wrappers around every block
• Hero headline exceeding 3 lines
• Fake technical micro-labels as decoration (pseudo-enterprise jargon)
• Generic brand names: Acme, Nexus, Flowbit, NovaCore
• Filler copy: "Unleash," "Elevate," "Seamless," "Next-Gen," "Transformative"

Output Requirements

• At least one reference image generated before any code is written
• Each generated image analyzed before implementation begins
• Implementation faithful to the reference (not "inspired by")
• Multi-image sets share a consistent brand world
• Hero section works at 1280px wide without looking overcrowded
• Apply complete behavior for the implementation phase

Quality Gates

Image generation:

• One image per section (not compressed boards)
• All text in images legible at normal viewing size
• Detail images created for sections where elements were too small
• No images cropped from previously generated larger images
• All section images share the same palette, type treatment, and component family

Analysis:

• Visible text extracted for each section
• Type scale relationships documented
• Color palette documented (background, panel, accent, text values)
• Component details documented (button shape, card structure)
• Spacing described (generous / medium / tight)

Implementation:

• Implementation does not visually drift from reference images
• Hero works at 1280px wide
• No generic patterns introduced that were absent from the references
• Spacing matches what the references showed
• Color palette matches the generated images

Failure Modes

"Design drift": The final coded website looks like a generic template despite having strong reference images. Cause: implementation was "inspired by" the images rather than following them. Fix: section by section, compare the coded result against the reference image and correct deviations.

"Unreadable images": Generated references have text too small to extract. Cause: too many sections compressed into one image. Fix: regenerate with one section per image at 16:9.

"Analysis skipped": Agent jumps from image generation to code without a documented analysis step. Fix: always produce a structured analysis (type, spacing, color, components) before writing code — it is a mandatory workflow step.

"Overcrowded hero": The hero contains headline, subheadline, two CTAs, a trust bar, a screenshot, and stat chips above the fold. Detection: count distinct content blocks in the hero. If more than 4, reduce. Fix: simplify to headline + subheadline + one CTA + one primary visual.

Response Format

Workflow order: (1) Generate images, (2) State "Analyzing images" and produce the structured analysis, (3) Implement the code. Do not abbreviate the analysis step — it is not optional. Apply complete behavior for the implementation phase.