> **Important:** This skill provides guidance and recommended instructions to assist the AI system. Outputs are not guaranteed to be complete, correct, secure, or applicable to every scenario. Results should be reviewed and validated by a human before being applied. The AI model may choose not to follow all instructions exactly, and additional verification may be required. # HTML/CSS Preview — presentation-quality recipes > **🎨 This preview is a PRESENTATION-QUALITY visual spec — the screen a designer would show a stakeholder to sign off the look.** > > It is the **raw-HTML/CSS rendering** of the shared design-quality contract in [`frontend-quality-bar.md`](.github/agents/shared-references/frontend-quality-bar.md) → "Shared design-quality principles". Read that section first: the preview and the eventual scaffolded app must look like the **same professional product** at two fidelities. This is not a wireframe — a flat, gray, boxy result fails the bar even if it is technically correct. > > It must confirm, at a polished bar: > > 1. **What's on each page** — real regions with real, populated content, in the right order. > 2. **The themed look** — brand palette applied through surfaces, badges, buttons, and a real hero; multi-tier elevation; consistent radius; clear type hierarchy. > 3. **All four data states** — `data`, `loading` (skeleton), `empty` (icon + CTA), `error` (banner + retry), depicted at least once across the page set. > > **What this raw-static preview intentionally leaves to the scaffold** (raw-static limits, not a license to look unpolished): real webfonts (use system fonts), JavaScript (no working toggles — states are depicted statically), and real photos (use neutral placeholder blocks — a subtle surface + border with a muted icon or initials, **not** a brand-color gradient). Everything else — real inline-SVG icons, elevation, hover/focus styling, skeleton shimmer — the preview DOES do, and must. > > **Polish is about *treatment*; content is about *the plan*.** Every `{...}` placeholder token in the recipes below MUST be replaced with the **real, domain-specific Sample Content** handed to you in your prompt (the page's records from the plan's Section 6 Sample Content block). Render the *same* entities, names, numbers, and states the scaffolded app will show — the preview is a faithful view of the real app, not a generic stand-in. **Never** emit generic filler like "Item 1", "Recent items", "Trending", "Card title", or lorem ipsum. **Never** add a banner or note claiming the app "will use" a different framework or component library — render the content directly with no such disclaimer. > > **Audience:** the planner sub-agents that fan out from Step 3.5b. Each sub-agent owns one page and writes a single self-contained HTML file linking to the shared `./theme.css`. **No `