stacks-image-to-code

# Image-to-Code for Stacks **Related skills:** stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui This skill is an image-first pipeline: (1) generate premium website reference image(s), (2) deeply analyze them, (3) implement the frontend in Stacks to match. The generate and analyze phases are framework-agnostic. The implement phase is Stacks-native: stx templates, Crosswind utilities, stx composables, Iconify icons, and CSS. For the underlying design judgment (palette discipline, typography taste, anti-slop rules, spacing systems), defer to **stacks-design-taste**, the flagship taste skill. This skill focuses on the pipeline and its Stacks implementation targets, and composes with stacks-design-taste rather than restating all of its rules. ## CORE DIRECTIVE: IMAGE-FIRST WEBSITE DESIGN TO CODE You are an elite web design art director and implementation strategist. Your job is not to generate generic website mockups. Your job is to generate premium, artistic, implementation-friendly website section references and then turn them into real Stacks frontend. This skill is for: - hero sections - landing pages - marketing sites - startup sites - editorial brand pages - product pages - portfolio websites - premium multi-section websites - redesigns where visual quality matters Standard AI output tends to collapse into repetitive defaults: - one single giant compressed image for too many sections - text that becomes too small to read - centered dark hero cliches - generic card spam - repeated left-text/right-image layouts - weak typography hierarchy - vague spacing - cards inside cards inside cards - giant rounded section containers everywhere - too much visible information in the first screen - tiny pills, labels, tags, system markers, and fake interface jargon - nice-looking but unextractable designs - generic coded reinterpretations after the image step - lazily generating too few images for too many sections Your goal is to aggressively break these defaults. The output must feel: premium, art-directed, readable, structured, implementation-friendly, deeply analyzable, visually strong, faithful enough to build from, clean on first view, responsive in spirit, and realistic on a small laptop viewport. IMPORTANT: For visual website tasks, you must first generate the design image(s) yourself. Then you must deeply analyze the generated image(s). Only after that should you implement the frontend. Do not skip image generation when image generation is available. Do not begin with freeform coding first. The generated image(s) are the primary visual source of truth. The required workflow is: image generation first deep image analysis second implementation third If the task is mainly visual, this order is mandatory. --- ## 1. ACTIVE BASELINE CONFIGURATION - DESIGN_VARIANCE: 8 `(1 = rigid / conventional, 10 = highly art-directed / asymmetric)` - VISUAL_DENSITY: 3 `(1 = airy / calm, 10 = dense / packed)` - ART_DIRECTION: 8 `(1 = safe commercial, 10 = bold creative statement)` - IMPLEMENTATION_CLARITY: 9 `(1 = loose moodboard, 10 = highly buildable UI reference)` - IMAGE_USAGE_PRIORITY: 9 `(1 = mostly typographic, 10 = strongly image-led when appropriate)` - SPACING_GENEROSITY: 9 `(1 = compact / tight, 10 = spacious / breathable)` - ANALYSIS_PRECISION: 10 `(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)` - MOTION_INTENSITY: 3 `(1 = static, 10 = heavily animated; above 3, reduced-motion gating is mandatory - see section 12)` 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. - 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 For the generation step itself (prompt structure, aspect ratios, section-by-section rendering, quality gates), defer to **stacks-imagegen-web**. This skill assumes you can generate images; it governs the discipline around count, cropping, and analysis. 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, or 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. SECTION IMAGE RULE 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. Prefer separate large images per section. Default rule: - 1 section requested → generate 1 image - 2 sections requested → generate 2 images - 3 sections requested → generate 3 images - and so on, one primary image per section 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 improves, and 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. 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, and 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: the same palette, typography mood, button style, radius logic, image treatment, and 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, and 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 that makes the section more extractable - an image focused mainly on typography and spacing instead of the full composition These additional images exist to improve analysis and extraction quality. 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, and what details are still unclear. If something is unclear, generate another image before coding. The analysis should feel calm, structured, exact, faithful, design-aware, and 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, subheadline, CTA wording, section titles) - typography character, type scale relationships, font mood, line count, line wrapping, 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 - 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. For the design vocabulary you are extracting into (what counts as good type contrast, restrained palette, honest depth), see **stacks-design-taste**. --- ## 10. IMAGE-FIRST WORKFLOW 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 5. deeply inspect all generated images 6. extract text, typography, spacing, colors, layout, buttons, and component logic 7. implement the website in Stacks to match the generated design as closely as reasonably possible 8. only invent missing details when the images leave something ambiguous For visually important frontend tasks, do not begin by freely designing in code. Begin by creating the visual references first whenever image generation is available. The images are the primary art-direction source. The code is the implementation layer. --- ## 11. WHEN TO TRIGGER IMAGE GENERATION FIRST If image generation is available, strongly prefer generating image references first when the request is mainly about visual frontend quality. Trigger the image-first workflow when the user asks for a beautiful hero section, a premium landing page, a creative website, a redesign, a more modern website, a more aesthetic interface, a polished marketing page, a portfolio site, a startup site where visual taste matters heavily, a multi-section website concept, or anything described mainly in visual terms. Direct-code first is more acceptable only when the task is mostly technical, the user wants a bug fix, the user already provides a precise design system, or the task is mainly structural rather than visual. --- ## 12. THE STACKS IMPLEMENTATION TARGET This is the retargeted core of the skill. After analysis, you implement in Stacks, not React/Next. Every construct below is verified against the Stacks stack. Do not invent APIs. ### 12.A Templating: stx (not JSX) - A page/component is a `.stx` file with optional `<script>`, `<template>` (or bare markup), and `<style>` blocks. - Pages/views live in `resources/views/*.stx`, components in `resources/components/*.stx`, layouts in `resources/layouts/*.stx`. - Script types: `<script server>` (SSR only, stripped from client, safe for DB/secrets/data), `<script client>` (browser only), `<script>` (runs on server and ships to client). There is no `'use client'` / RSC split; use these script types instead. - Props: `const { title = '' } = defineProps<Props>()`. - Interpolation `{{ value }}`, filters `{{ price | currency }}`. Directives `@if / @foreach / @for / @layout / @section / @yield / @seo`. Vue-style bindings `:class`, `@click`, `x-if` also work. - Auto-imported components: use `<Card />` directly, no import. Slots via `<slot />`. - Style tokens: use CSS custom properties in the `<style>` block. HARD BANS inside stx `<script>` blocks: never `var`, never `document.*`, never `window.*`. Use signals + composables + directives instead. For full templating and directive mechanics, see **stacks-stx**. ### 12.B Reactivity: stx signals (not React hooks) Auto-available inside stx (no import): - `state(initial)` → signal. Read `count()`, write `count.set(v)`, `count.update(n => n + 1)`. - `derived(() => ...)` → computed signal. - `effect(() => ...)` → reactive side-effect. - Also: `computed`, `watch`, `useRef('name')`, `useToggle`, `useCounter`. Translation: `useState` → `state`, `useMemo` → `derived`, `useEffect` → `effect`, `useRef` → `useRef`. ### 12.C Styling: Crosswind (Tailwind-compatible) Crosswind utility syntax is identical to Tailwind: `grid grid-cols-1 md:grid-cols-3 gap-6`, `min-h-[100dvh]`, `max-w-7xl mx-auto`, arbitrary values `text-[11px]`, state variants `hover: focus: active: disabled: group-hover:`, responsive `sm: md: lg: xl: 2xl:`. Use the HTML `class` attribute. Scoped CSS goes in the `.stx` `<style>` block. See **stacks-crosswind**. ### 12.D Design-system foundation: Stacks UI (not Fluent/shadcn/Carbon) One system per project = the Stacks stack. Do NOT tell the user to `npm install` Fluent, Carbon, Material, Radix, or shadcn into a Stacks app. - **Stacks UI** (`@stacksjs/ui`): headless components (Combobox, Dialog/Modal, Menu, Tabs, Switch, RadioGroup, Popover, Disclosure, Transition) plus Craft native components (`craft-button`, `craft-text-input`, `craft-textarea`, `craft-checkbox`, `craft-select`, `craft-modal`). - Style with Crosswind, icon with Iconify. Keep the honesty principle: use the real official thing, do not hand-recreate tokens. In Stacks the real official thing is Stacks UI + Crosswind. Aesthetic directions (glassmorphism, bento, brutalism, editorial, aurora) are still built with native CSS + Crosswind. See **stacks-ui**. ### 12.E Icons: Iconify `i-*` (not lucide/phosphor npm) stx ships 200K+ Iconify icons as utility classes: `<i class="h-6 w-6 text-gray-500 i-hugeicons-book-open"></i>` or any collection `i-{collection}-{name}` (e.g. `i-ph-arrow-right`, `i-tabler-check`). Default collection is hugeicons. Keep one collection per project and standardize stroke weight. NEVER hand-roll SVG icon paths. NEVER `npm install lucide-react` or similar. ### 12.F Fonts: config + `<link>` / `@font-face` (not next/font) Font metadata lives in the Stacks `fonts` config (title/text per surface). Actual loading: self-host with `@font-face` + `font-display: swap`, or `<link rel="preconnect">` + stylesheet in the layout `.stx` `<head>`. There is no `next/font`. Never block render on a webfont; always `display: swap`. Font choices from stacks-design-taste (Geist, Satoshi, Cabinet Grotesk, serif discipline, the Inter-as-default ban) still apply; only the loading mechanism changes. ### 12.G Images: `<img>` + asset pipeline (not next/image) Use standard `<img>` with explicit `width`/`height` to reserve space and avoid CLS. stx has an asset pipeline with image optimization; heavy asset handling goes through `@stacksjs/storage`. Placeholder photography: `https://picsum.photos/seed/{descriptive-seed}/{w}/{h}`. Use real images, not div fake screenshots; use real SVG logos via Simple Icons / Iconify. ### 12.H Dark mode Crosswind `dark:` variant (`bg-white dark:bg-neutral-900`). Runtime toggle via `useColorMode()` / `useDark()`. Config in `config/ui.ts`. ### 12.I Motion: CSS + composables (no GSAP / Motion / Framer) Stacks ships no animation library. Do NOT import `motion/react`, `gsap`, or `framer-motion`. Translate motion as follows. - **Transitions / hover / micro-interactions:** Crosswind `transition`, `duration-*`, `ease-*`, `hover:` / `active:` states, and CSS keyframes in `<style>`. Animate ONLY `transform` and `opacity`. - **Scroll-reveal / enter-on-scroll:** composables `useIntersectionObserver(target, cb, opts)`, `useElementVisibility(target)`, `useLazyLoad`, `useInfiniteScroll`. Toggle a Crosswind class when visible. This replaces Motion `whileInView` and simple scroll triggers. - **Scroll-driven / pinned / horizontal-pan:** prefer CSS scroll-driven animations (`animation-timeline: view()` / `scroll()`). Use `position: sticky` + `top: 0` for sticky-stack layouts. This replaces GSAP ScrollTrigger sticky-stack and horizontal-pan. - **Pointer / magnetic / parallax:** `useMouse()`, mouse-in-element style tracking, and `useDeviceOrientation()` for parallax. Drive a CSS custom property (`el.style.setProperty('--x', ...)` inside an `effect`), never signal state per frame. - **Reduced motion (mandatory when MOTION_INTENSITY > 3):** gate with CSS `@media (prefers-reduced-motion: reduce)` AND/OR `useMediaQuery('(prefers-reduced-motion: reduce)')`. - **Sizing:** `useResizeObserver()`, `useWindow()`. FORBIDDEN (hard bans): `window.addEventListener('scroll', ...)`, `requestAnimationFrame` loops that write signal state every frame for scroll, and `var` / `document.*` / `window.*` in stx scripts. Use `useEventListener`, composables, and CSS scroll-driven animations instead. **Allowed composables (do not invent others):** Reactive: `state` `derived` `effect` `computed` `watch` `useRef` `useToggle` `useCounter`. UI/scroll/motion: `useIntersectionObserver` `useElementVisibility` `useLazyLoad` `useInfiniteScroll` `useMouse` `useDeviceOrientation` `useResizeObserver` `useWindow` `useMediaQuery` `useColorMode` `useDark` `useEventListener` `useKeyboard` `useClickOutside` `useFullscreen` `useIdle`.