--- name: design-html preamble-tier: 2 version: 1.0.0 description: | Design finalization: generates production-quality Pretext-native HTML/CSS. Works with approved mockups from /design-shotgun, CEO plans from /plan-ceo-review, design review context from /plan-design-review, or from scratch with a user description. Text actually reflows, heights are computed, layouts are dynamic. 30KB overhead, zero deps. Smart API routing: picks the right Pretext patterns for each design type. Use when: "finalize this design", "turn this into HTML", "build me a page", "implement this design", or after any planning skill. Proactively suggest when user has approved a design or has a plan ready. (gstack) voice-triggers: - "build the design" - "code the mockup" - "make it real" triggers: - build the design - code the mockup - make design real allowed-tools: - Bash - Read - Write - Edit - Glob - Grep - Agent - AskUserQuestion --- {{PREAMBLE}} # /design-html: Pretext-Native HTML Engine You generate production-quality HTML where text actually works correctly. Not CSS approximations. Computed layout via Pretext. Text reflows on resize, heights adjust to content, cards size themselves, chat bubbles shrinkwrap, editorial spreads flow around obstacles. {{DESIGN_SETUP}} {{UX_PRINCIPLES}} {{BROWSE_SETUP}} --- ## Step 0: Input Detection ```bash eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)" ``` Detect what design context exists for this project. Run all four checks: ```bash setopt +o nomatch 2>/dev/null || true _CEO=$(ls -t ~/.gstack/projects/$SLUG/ceo-plans/*.md 2>/dev/null | head -1) [ -n "$_CEO" ] && echo "CEO_PLAN: $_CEO" || echo "NO_CEO_PLAN" ``` ```bash setopt +o nomatch 2>/dev/null || true _APPROVED=$(ls -t ~/.gstack/projects/$SLUG/designs/*/approved.json 2>/dev/null | head -1) [ -n "$_APPROVED" ] && echo "APPROVED: $_APPROVED" || echo "NO_APPROVED" ``` ```bash setopt +o nomatch 2>/dev/null || true _VARIANTS=$(ls -t ~/.gstack/projects/$SLUG/designs/*/variant-*.png 2>/dev/null | head -1) [ -n "$_VARIANTS" ] && echo "VARIANTS: $_VARIANTS" || echo "NO_VARIANTS" ``` ```bash setopt +o nomatch 2>/dev/null || true _FINALIZED=$(ls -t ~/.gstack/projects/$SLUG/designs/*/finalized.html 2>/dev/null | head -1) [ -n "$_FINALIZED" ] && echo "FINALIZED: $_FINALIZED" || echo "NO_FINALIZED" [ -f DESIGN.md ] && echo "DESIGN_MD: exists" || echo "NO_DESIGN_MD" ``` Now route based on what was found. Check these cases in order: ### Case A: approved.json exists (design-shotgun ran) If `APPROVED` was found, read it. Extract: approved variant PNG path, user feedback, screen name. Also read the CEO plan if one exists (it adds strategic context). Read `DESIGN.md` if it exists in the repo root. These tokens take priority for system-level values (fonts, brand colors, spacing scale). Then check for prior finalized.html. If `FINALIZED` was also found, use AskUserQuestion: > Found a prior finalized HTML from a previous session. Want to evolve it > (apply new changes on top, preserving your custom edits) or start fresh? > A) Evolve — iterate on the existing HTML > B) Start fresh — regenerate from the approved mockup If evolve: read the existing HTML. Apply changes on top during Step 3. If fresh or no finalized.html: proceed to Step 1 with the approved PNG as the visual reference. ### Case B: CEO plan and/or design variants exist, but no approved.json If `CEO_PLAN` or `VARIANTS` was found but no `APPROVED`: Read whichever context exists: - If CEO plan found: read it and summarize the product vision and design requirements. - If variant PNGs found: show them inline using the Read tool. - If DESIGN.md found: read it for design tokens and constraints. Use AskUserQuestion: > Found [CEO plan from /plan-ceo-review | design review variants from /plan-design-review | both] > but no approved design mockup. > A) Run /design-shotgun — explore design variants based on the existing plan context > B) Skip mockups — I'll design the HTML directly from the plan context > C) I have a PNG — let me provide the path If A: tell the user to run /design-shotgun, then come back to /design-html. If B: proceed to Step 1 in "plan-driven mode." There is no approved PNG, the plan is the source of truth. Ask the user for a screen name to use for the output directory (e.g., "landing-page", "dashboard", "pricing"). If C: accept a PNG file path from the user and proceed with that as the reference. ### Case C: Nothing found (clean slate) If none of the above produced any context: Use AskUserQuestion: > No design context found for this project. How do you want to start? > A) Run /plan-ceo-review first — think through the product strategy before designing > B) Run /plan-design-review first — design review with visual mockups > C) Run /design-shotgun — jump straight to visual design exploration > D) Just describe it — tell me what you want and I'll design the HTML live If A, B, or C: tell the user to run that skill, then come back to /design-html. If D: proceed to Step 1 in "freeform mode." Ask the user for a screen name. ### Context summary After routing, output a brief context summary: - **Mode:** approved-mockup | plan-driven | freeform | evolve - **Visual reference:** path to approved PNG, or "none (plan-driven)" or "none (freeform)" - **CEO plan:** path or "none" - **Design tokens:** "DESIGN.md" or "none" - **Screen name:** from approved.json, user-provided, or inferred from CEO plan --- ## Step 1: Design Analysis 1. If `$D` is available (`DESIGN_READY`), extract a structured implementation spec: ```bash $D prompt --image --output json ``` This returns colors, typography, layout structure, and component inventory via GPT-4o vision. 2. If `$D` is not available, read the approved PNG inline using the Read tool. Describe the visual layout, colors, typography, and component structure yourself. 3. If in plan-driven or freeform mode (no approved PNG), design from context: - **Plan-driven:** read the CEO plan and/or design review notes. Extract the described UI requirements, user flows, target audience, visual feel (dark/light, dense/spacious), content structure (hero, features, pricing, etc.), and design constraints. Build an implementation spec from the plan's prose rather than a visual reference. - **Freeform:** use AskUserQuestion to gather what the user wants to build. Ask about: purpose/audience, visual feel (dark/light, playful/serious, dense/spacious), content structure (hero, features, pricing, etc.), and any reference sites they like. In both cases, describe the intended visual layout, colors, typography, and component structure as your implementation spec. Generate realistic content based on the plan or user description (never lorem ipsum). 4. Read `DESIGN.md` tokens. These override any extracted values for system-level properties (brand colors, font family, spacing scale). 5. Output an "Implementation spec" summary: colors (hex), fonts (family + weights), spacing scale, component list, layout type. --- ## Step 2: Smart Pretext API Routing Analyze the approved design and classify it into a Pretext tier. Each tier uses different Pretext APIs for optimal results: | Design type | Pretext APIs | Use case | |-------------|-------------|----------| | Simple layout (landing, marketing) | `prepare()` + `layout()` | Resize-aware heights | | Card/grid (dashboard, listing) | `prepare()` + `layout()` | Self-sizing cards | | Chat/messaging UI | `prepareWithSegments()` + `walkLineRanges()` | Tight-fit bubbles, min-width | | Content-heavy (editorial, blog) | `prepareWithSegments()` + `layoutNextLine()` | Text around obstacles | | Complex editorial | Full engine + `layoutWithLines()` | Manual line rendering | State the chosen tier and why. Reference the specific Pretext APIs that will be used. --- ## Step 2.5: Framework Detection Check if the user's project uses a frontend framework: ```bash [ -f package.json ] && cat package.json | grep -o '"react"\|"svelte"\|"vue"\|"@angular/core"\|"solid-js"\|"preact"' | head -1 || echo "NONE" ``` If a framework is detected, use AskUserQuestion: > Detected [React/Svelte/Vue] in your project. What format should the output be? > A) Vanilla HTML — self-contained preview file (recommended for first pass) > B) [React/Svelte/Vue] component — framework-native with Pretext hooks If the user chooses framework output, ask one follow-up: > A) TypeScript > B) JavaScript For vanilla HTML: proceed to Step 3 with vanilla output. For framework output: proceed to Step 3 with framework-specific patterns. If no framework detected: default to vanilla HTML, no question needed. --- ## Step 3: Generate Pretext-Native HTML ### Pretext Source Embedding For **vanilla HTML output**, check for the vendored Pretext bundle: ```bash _PRETEXT_VENDOR="" _ROOT=$(git rev-parse --show-toplevel 2>/dev/null) [ -n "$_ROOT" ] && [ -f "$_ROOT/.claude/skills/gstack/design-html/vendor/pretext.js" ] && _PRETEXT_VENDOR="$_ROOT/.claude/skills/gstack/design-html/vendor/pretext.js" [ -z "$_PRETEXT_VENDOR" ] && [ -f ~/.claude/skills/gstack/design-html/vendor/pretext.js ] && _PRETEXT_VENDOR=~/.claude/skills/gstack/design-html/vendor/pretext.js [ -n "$_PRETEXT_VENDOR" ] && echo "VENDOR: $_PRETEXT_VENDOR" || echo "VENDOR_MISSING" ``` - If `VENDOR` found: read the file and inline it in a `` Add a comment: `` For **framework output**, add to the project's dependencies instead: ```bash # Detect package manager [ -f bun.lockb ] && echo "bun add @chenglou/pretext" || \ [ -f pnpm-lock.yaml ] && echo "pnpm add @chenglou/pretext" || \ [ -f yarn.lock ] && echo "yarn add @chenglou/pretext" || \ echo "npm install @chenglou/pretext" ``` Run the detected install command. Then use standard imports in the component. ### HTML Generation Write a single file using the Write tool. Save to: `~/.gstack/projects/$SLUG/designs/-YYYYMMDD/finalized.html` For framework output, save to: `~/.gstack/projects/$SLUG/designs/-YYYYMMDD/finalized.[tsx|svelte|vue]` **Always include in vanilla HTML:** - Pretext source (inlined or CDN, see above) - CSS custom properties for design tokens from DESIGN.md / Step 1 extraction - Google Fonts via `` tags + `document.fonts.ready` gate before first `prepare()` - Semantic HTML5 (`

`, `