Vibe UI Design Workflow

Problem

Web UI generation often fails less because it cannot render a page and more because it drifts into default LLM styling: indigo gradients, emoji-as-icon decoration, invented metrics, filler copy, arbitrary glass, and unsupported shadows. vibe-ui treats visual constraints as file-level artifacts, using DESIGN.md as the source of truth for color, typography, spacing, radius, shadows, layout rhythm, density, and interaction style. Its Vibe Gate loop checks the work before implementation and reviews it after code is produced.

Workflow and Key Components

• Read the brief first: read writes .vibe-ui/brief-read.json and .vibe-ui/product-context.json with audience, buyer anxiety, register, dials, proof strategy, and section strategy.
• Lock the style: if a style is named, use writes DESIGN.md; otherwise recommend selects from built-in curated styles, with --source open-design for the broader bundled resource library.
• Generate page work: supported page types include landing, dashboard, pricing, login, docs, settings, profile, and chrome-extension-landing; template, like, and browse --source all help compare patterns or produce a local static browser.
• Review after implementation: check or report gives the first pass; if the result is not Ready or still feels generic, critique and polish create a repair prompt.

Boundaries

This is a design-workflow aid, not a replacement for project tests or visual inspection. DESIGN.md should constrain generated UI, not copy real logos, trademarks, proprietary assets, or official brand claims. Internal scaffold text such as Design Read, dials, and prompts should stay in JSON, reports, comments, or prompts rather than production UI.