Generate self-contained HTML mockups for design review and serve them locally with clickable URLs. Use this skill whenever the user wants to visualize a design before implementing it, review UI states, compare layout options, or get sign-off on a proposed design. Triggers on phrases like "create mockups", "mock up", "show me what it looks like", "preview the design", "html mockup", "generate mockups", "let me see it first", "design preview", or any request to visualize proposed UI changes before coding them. Also use proactively when a design task is complex enough that visual review would prevent wasted iteration — mockups are cheap, implementation rework is expensive.
Generate high-fidelity HTML mockups for design review, serve them locally, and get sign-off before writing production code.
Design iteration in code is slow and expensive. A mockup you can click through in a browser takes minutes to create and saves hours of implementation rework. This skill front-loads visual alignment so that by the time you write real code, the design is already approved.
This phase has three steps in order. The goal is to extract only the design system knowledge that's relevant to what you're actually mocking up.
Step 1: Understand the work context. Read the source files that will be changed — components, pages, layouts. Look at screenshots if the user provided them. Understand what the mockup needs to represent: is it a form? a settings page? a dashboard? an action panel? What UI primitives does it need — buttons, cards, inputs, banners, tabs, modals?
Step 2: Discover the global design system. Now scan the project for its design language. The goal is to build a picture of the project's conventions:
tailwind.config.*app.cssDon't try to catalog everything. Focus on understanding the vocabulary.
Step 3: Extract what's relevant. Based on what the mockup needs (Step 1) and what the project provides (Step 2), pull the specific tokens and patterns that apply:
Build a tailwind.config block containing only the tokens the mockup needs.
This keeps the config focused and the mockup honest — it uses real project
tokens, not generic Tailwind defaults.
Read the actual component markup for class patterns and structure. The
mockup should mirror real patterns — if the project uses flex items-center gap-3 for action rows, the mockup should too. If there's a shared Button
component with specific classes, use those classes.
Before rendering a single pixel, present a state matrix to the user.
## State Matrix — [Feature Name]
| State | Description | Notes |
|-------|-------------|-------|
| Idle | Default, no action taken | Main CTA visible |
| Loading | Action in progress | Spinner, disabled buttons |
| Success | Action completed | Flash message, updated status |
| Error | Something went wrong | Error banner, retry option |
| Empty | No data yet | Empty state illustration |
| Mobile | All states at small viewport | Verify stacking/wrapping |
Ask the user to confirm the state list before proceeding. This is the cheapest possible checkpoint — a few lines of text that prevent hours of "you missed this state" iteration later.
If the user wants options mode, list the alternative design directions