|
| 1 | +--- |
| 2 | +schemaVersion: 1 |
| 3 | +name: design-reference-to-html |
| 4 | +description: > |
| 5 | + Recreates an existing visual reference, such as a UI screenshot, mockup export, |
| 6 | + Figma frame image, dashboard, SaaS screen, empty state, or landing-page capture, |
| 7 | + as high-quality HTML/CSS or App.jsx. Use only when the user provides a concrete |
| 8 | + visual reference, not for text-only page design. |
| 9 | +aliases: [design-to-html, screenshot-to-html, visual-reference, screenshot-recreate] |
| 10 | +dependencies: [responsive-layout, craft-polish] |
| 11 | +validationHints: |
| 12 | + - visual reference is mapped before code is written |
| 13 | + - complex brand or illustration assets are treated as assets, not improvised CSS |
| 14 | + - preview screenshots are compared against the reference before done |
| 15 | +trigger: |
| 16 | + providers: ['*'] |
| 17 | + scope: system |
| 18 | +disable_model_invocation: false |
| 19 | +user_invocable: true |
| 20 | +--- |
| 21 | + |
| 22 | +## Design Reference Recreation |
| 23 | + |
| 24 | +Use this workflow when the user asks to recreate, copy, convert, or implement a |
| 25 | +visible design reference as HTML/CSS, `App.jsx`, or a local web artifact. |
| 26 | + |
| 27 | +Do not use it for ordinary product design from prose. If there is no screenshot, |
| 28 | +mockup, exported frame, or equivalent visual artifact, use normal frontend |
| 29 | +design judgment instead. |
| 30 | + |
| 31 | +## Core Contract |
| 32 | + |
| 33 | +Do not jump straight from image to code. |
| 34 | + |
| 35 | +Work as an error-reduction loop: |
| 36 | + |
| 37 | +1. Inspect the visual reference and build a compact page map. |
| 38 | +2. Separate code-rendered UI from external visual assets. |
| 39 | +3. Decide the reference canvas, target viewport, and scaling strategy. |
| 40 | +4. Implement structure first, then visual polish. |
| 41 | +5. Run `preview(path)` and inspect the rendered result. |
| 42 | +6. Compare the preview screenshot against the reference by region. |
| 43 | +7. Correct concrete visual differences and preview again before `done(path)`. |
| 44 | + |
| 45 | +## Inputs To Establish |
| 46 | + |
| 47 | +Infer these from the prompt, attachments, workspace files, and `inspect_workspace` |
| 48 | +when possible. Ask only when missing information would change the output format |
| 49 | +or fidelity target. |
| 50 | + |
| 51 | +- Visual reference: screenshot, mockup export, frame image, browser capture, or |
| 52 | + local reference asset. |
| 53 | +- Output surface: default to `App.jsx` in an Open CoDesign workspace; use |
| 54 | + standalone `.html` only when requested or when editing an existing HTML file. |
| 55 | +- Reference canvas: preserve the image aspect ratio when dimensions are known. |
| 56 | +- Verification viewport: match the reference size when practical, then also |
| 57 | + check the user-facing viewport if different. |
| 58 | +- Asset availability: logos, illustrations, product screenshots, device renders, |
| 59 | + photos, icon sets, or only the flat reference image. |
| 60 | +- Responsive scope: desktop-only unless the user requests mobile/tablet or the |
| 61 | + existing artifact clearly needs breakpoints. |
| 62 | + |
| 63 | +## Page Map Before Code |
| 64 | + |
| 65 | +Before writing source, make a short implementation map: |
| 66 | + |
| 67 | +- Overall regions: header, sidebar, hero, content grid, panels, footer, overlays. |
| 68 | +- Layout ratios: column widths, row heights, primary alignment, visible margins. |
| 69 | +- Component inventory: visible UI pieces in top-to-bottom, left-to-right order. |
| 70 | +- Color and surfaces: background, cards, borders, shadows, accent colors. |
| 71 | +- Typography: heading/body/helper sizes, weights, line-height, casing. |
| 72 | +- Shape and density: radius scale, padding rhythm, gaps, shadow softness. |
| 73 | +- Asset candidates: logos, photos, screenshots, illustrations, 3D objects, |
| 74 | + detailed empty-state art, or brand key visuals. |
| 75 | + |
| 76 | +Keep the map concise. It is a checklist for implementation, not a long critique. |
| 77 | + |
| 78 | +## Asset Separation |
| 79 | + |
| 80 | +Render with HTML/CSS: |
| 81 | + |
| 82 | +- Navigation, sidebars, tabs, menus, cards, panels, forms, tables, buttons, |
| 83 | + labels, badges, dividers, text, simple charts, and simple icons from an |
| 84 | + existing icon library. |
| 85 | + |
| 86 | +Treat as assets: |
| 87 | + |
| 88 | +- Brand logos and marks. |
| 89 | +- Detailed illustrations, hero art, 3D renders, people photos, textures. |
| 90 | +- Product screenshots, app mockups, detailed empty-state images. |
| 91 | +- Any shape where exact brand detail matters more than layout structure. |
| 92 | + |
| 93 | +If removing an element leaves the UI skeleton intact, it is probably an asset. |
| 94 | +If removing it breaks the page structure, it is probably code-rendered UI. |
| 95 | + |
| 96 | +Do not hand-draw logos or complex illustrations with ad hoc CSS/SVG. Prefer, in |
| 97 | +order: |
| 98 | + |
| 99 | +1. Existing user-supplied assets in the workspace. |
| 100 | +2. A cropped asset from the reference, when available and clear enough. |
| 101 | +3. A stable neutral placeholder that preserves layout. |
| 102 | +4. `gen_image(prompt, path)` only when the user asked for generated/redrawn |
| 103 | + bitmap assets and the current provider supports it. |
| 104 | + |
| 105 | +Report placeholders and low-quality crops in the final summary. |
| 106 | + |
| 107 | +## Canvas And Fit |
| 108 | + |
| 109 | +For screenshot recreation, distinguish: |
| 110 | + |
| 111 | +- Reference canvas: the design image/artboard being copied. |
| 112 | +- Display viewport: the browser or preview size used to inspect the result. |
| 113 | + |
| 114 | +Standalone visual reproductions should preserve the reference aspect ratio. |
| 115 | +Use an outer shell plus a stable stage rather than scattering viewport math |
| 116 | +through every element: |
| 117 | + |
| 118 | +```css |
| 119 | +html, |
| 120 | +body { |
| 121 | + width: 100%; |
| 122 | + height: 100%; |
| 123 | + margin: 0; |
| 124 | +} |
| 125 | + |
| 126 | +.preview-shell { |
| 127 | + min-height: 100vh; |
| 128 | + display: grid; |
| 129 | + place-items: center; |
| 130 | + overflow: hidden; |
| 131 | + background: var(--page-bg); |
| 132 | +} |
| 133 | + |
| 134 | +.design-stage { |
| 135 | + width: min(100vw, calc(100vh * var(--reference-ratio))); |
| 136 | + max-height: 100vh; |
| 137 | + aspect-ratio: var(--reference-ratio); |
| 138 | + position: relative; |
| 139 | + overflow: hidden; |
| 140 | +} |
| 141 | +``` |
| 142 | + |
| 143 | +Use a normal responsive layout for production app screens, but still preserve |
| 144 | +the reference proportions at the target breakpoint before adding other |
| 145 | +breakpoints. |
| 146 | + |
| 147 | +Avoid direct `transform: scale(...)` on a centered fixed canvas unless a parent |
| 148 | +frame also reserves the scaled layout size. Otherwise the visual canvas and the |
| 149 | +layout box disagree, which causes clipped edges or large empty bands. |
| 150 | + |
| 151 | +## Build Rules |
| 152 | + |
| 153 | +- Match proportions and alignment before tuning shadows or gradients. |
| 154 | +- Use CSS variables for repeated colors, spacing, typography, radius, and |
| 155 | + shadows; update `DESIGN.md` when the reference establishes a reusable system. |
| 156 | +- Use explicit dimensions, `aspect-ratio`, grid tracks, `object-fit`, and |
| 157 | + min/max constraints for repeated units and asset slots. |
| 158 | +- Keep text content faithful to the reference. Do not add visible explanatory |
| 159 | + labels unless the reference shows them. |
| 160 | +- Prefer local assets and app-provided libraries. Do not install packages, |
| 161 | + download images, or add external hotlinks without user approval. |
| 162 | +- Use the repo's existing framework and source entry. In Open CoDesign, default |
| 163 | + to `App.jsx`; reserve `index.html` for standalone exports or existing HTML |
| 164 | + workspaces. |
| 165 | + |
| 166 | +## Preview And Compare |
| 167 | + |
| 168 | +Always run `preview(path)` before `done(path)` when the preview tool is |
| 169 | +available. Inspect: |
| 170 | + |
| 171 | +- Canvas fit: no unintended crop, squeeze, overflow, or corner anchoring. |
| 172 | +- Region layout: header, sidebar, main content, repeated cards, footer. |
| 173 | +- Typography: hierarchy, wrapping, weight, line-height, and text color. |
| 174 | +- Surfaces: background hue, card contrast, border opacity, radius, shadows. |
| 175 | +- Assets: size, crop, aspect ratio, resolution, and style match. |
| 176 | +- Density: gaps, padding, vertical rhythm, and whether the page feels too empty |
| 177 | + or too cramped. |
| 178 | +- Responsive behavior when mobile/tablet is in scope. |
| 179 | + |
| 180 | +Convert vague visual mismatch into actionable edits: |
| 181 | + |
| 182 | +- "Hero starts about 24px too low." |
| 183 | +- "Cards need 8px less vertical padding." |
| 184 | +- "The sidebar is too wide relative to the reference." |
| 185 | +- "The product screenshot slot should use `object-fit: contain`, not stretch." |
| 186 | + |
| 187 | +Iterate with focused edits, preview again, then stop when remaining differences |
| 188 | +are minor, blocked by missing assets, or outside the requested scope. |
| 189 | + |
| 190 | +## Delivery |
| 191 | + |
| 192 | +When calling `done(path)` and summarizing for the user, include: |
| 193 | + |
| 194 | +- What file or artifact was implemented. |
| 195 | +- Which reference and viewport were checked. |
| 196 | +- Which assets were used, cropped, generated, or represented by placeholders. |
| 197 | +- Remaining visual gaps or unverified assumptions. |
| 198 | + |
| 199 | +Do not claim pixel-perfect fidelity unless preview comparison supports it. |
0 commit comments