# HTML Mockup Sketcher

> Generate 2-3 interactive HTML mockup variants to compare UI/UX design directions before committing to a single approach. Quickly explore different visual stances and gather feedback.

- Canonical: https://nanoskill.ai/skills/html-mockup-sketcher
- Markdown: https://nanoskill.ai/skills/html-mockup-sketcher.md
- Author: NousResearch
- Published: 2026-06-04T05:30:00.000Z
- Updated: 2026-07-21T18:34:02.819Z
- Language: en
- Source type: github
- Popularity signal: 2137

## Sources

- https://github.com/NousResearch/hermes-agent

## Install

```shell
npx skills add https://github.com/NousResearch/hermes-agent/tree/main/skills/creative/sketch
```

## About

The HTML Mockup Sketcher is a powerful skill designed to help users quickly explore and compare UI/UX design directions through disposable HTML mockups. Instead of committing to a single design, this tool generates 2-3 interactive variants, allowing for side-by-side comparison of different visual stances. It's ideal for early-stage design exploration, helping you visualize concepts and gather feedback before significant development investment.

This skill focuses on creating functional, interactive HTML mockups that go beyond static images. Each variant is a self-contained HTML file featuring inline CSS, system fonts, and realistic content. Crucially, the mockups include basic interactivity such as clickable links, hover states, and at least one state transition, providing a more tangible feel for the user experience. Integrated browser tools allow for visual verification, ensuring the mockups are clean and bug-free.

To facilitate informed decision-making, the HTML Mockup Sketcher provides a structured comparison. Each variant comes with a detailed \`README.md\` outlining its design principles, key choices, trade-offs, and best-fit use cases. After generation, a comparative table summarizes the differences across various design dimensions, accompanied by an opinionated analysis to help you select a winner, combine elements, or iterate further.

## Key features

- **Generate Multiple Design Variants**: Produce 2-3 distinct HTML mockup variants simultaneously, each exploring a different design stance (e.g., density, emphasis, aesthetic, layout) for side-by-side comparison.
- **Interactive HTML Mockups**: Create self-contained HTML files with inline CSS, system fonts, and realistic fake content. Mockups are interactive, allowing for clickable links, hovers, and at least one state transition.
- **Visual Verification with Browser Tools**: Utilize integrated browser navigation and vision tools to visually inspect and verify each HTML mockup, ensuring layouts are clean, readable, and free of bugs before presentation.
- **Structured Variant Documentation**: Each HTML mockup variant includes a \`README.md\` detailing its design stance, key choices (layout, typography, color, interaction), trade-offs, and ideal use cases to facilitate informed comparison.
- **Comparative Analysis Table**: Present all generated HTML mockup variants in a comparative table, highlighting differences across key dimensions like density, primary action visibility, scan-ability, and overall feel, along with an opinionated summary.

## Use cases

- **Explore UI/UX Design Directions**: Quickly generate and compare multiple HTML mockup variants to explore different user interface and user experience design ideas before investing significant development time.
- **Gather Feedback on Visual Concepts**: Present interactive HTML mockups to stakeholders or users to gather early feedback on various visual directions, helping to refine concepts and make informed design decisions.
- **Rapid Prototyping for New Features**: Create disposable HTML mockups to rapidly prototype new features or screens, focusing on core functionality and visual flow rather than production-ready code.

## Result preview

See real HTMLs about boutique hotel websites generated by this Agent Skill.

![the demo of HTML mockup Agent Skill](https://file.nanoskill.ai/HTML-mockup-demo-1.jpg)

![the demo of HTML mockup Agent Skill](https://file.nanoskill.ai/HTML-mockup-demo-2.jpg)

![the demo of HTML mockup Agent Skill](https://file.nanoskill.ai/HTML-mockup-demo-3.jpg)

![the demo of HTML mockup Agent Skill](https://file.nanoskill.ai/HTML-mockup-demo-4.jpg)

## Result walkthrough

### Step 1：Install

Add the skill to your agent.

![a simple demonstration of the first step in using HTML mockup](https://file.nanoskill.ai/HTML-mockup-step-1.jpg)

### Step 2：Describe Your Website

Explain the detailed information (e.g., style, type) of the website you want to create.

![a simple demonstration of the second step in using HTML mockup](https://file.nanoskill.ai/HTML-mockup-step-2.jpg)

### Step 3：Review Outcome

Review and compare the generated HTML mockups.

![a simple demonstration of the third step in using HTML mockup](https://file.nanoskill.ai/HTML-mockup-step-3.jpg)

## Skill definition

# Sketch

Use this skill when the user wants to **see a design direction before committing** to one — exploring a UI/UX idea as disposable HTML mockups. The point is to generate 2-3 interactive variants so the user can compare visual directions side-by-side, not to produce shippable code.

Load this when the user says things like "sketch this screen", "show me what X could look like", "compare layout A vs B", "give me 2-3 takes on this UI", "let me see some variants", "mockup this before I build".

## When NOT to use this

- User wants a production component — use `claude-design` or build it properly
- User wants a polished one-off HTML artifact (landing page, deck) — `claude-design`
- User wants a diagram — `excalidraw`, `architecture-diagram`
- The design is already locked — just build it

## If the user has the full GSD system installed

If `gsd-sketch` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-sketch`** for the full workflow: persistent `.planning/sketches/` with MANIFEST, frontier mode analysis, consistency audits across past sketches, and integration with the rest of GSD. This skill is the lightweight standalone version — one-off sketching without the state machinery.

## Core method

```
intake  →  variants  →  head-to-head  →  pick winner (or iterate)
```

### 1. Intake (skip if the user already gave you enough)

Before generating variants, get three things — one question at a time, not all at once:

1. **Feel.** "What should this feel like? Adjectives, emotions, a vibe." — *"calm, editorial, like Linear"* tells you more than *"minimal"*.
2. **References.** "What apps, sites, or products capture the feel you're imagining?" — actual references beat abstract descriptions.
3. **Core action.** "What's the single most important thing a user does on this screen?" — the variants should all serve this well; if they don't, they're just decoration.

Reflect each answer briefly before the next question. If the user already gave you all three upfront, skip straight to variants.

### 2. Variants (2-3, never 1, rarely 4+)

Produce **2-3 variants** in one go. Each variant is a complete, standalone HTML file. Don't describe variants — build them. The point is comparison.

Each variant should take a **different design stance**, not different pixel values. Three good variant axes:

- **Density:** compact / airy / ultra-dense (pick two contrasting poles)
- **Emphasis:** content-first / action-first / tool-first
- **Aesthetic:** editorial / utilitarian / playful
- **Layout:** single-column / sidebar / split-pane
- **Grounding:** card-based / bare-content / document-style

Pick one axis and pull apart from it. Two variants that differ only in accent color are wasted effort — the user can't distinguish them.

**Variant naming:** describe the stance, not the number.

```
sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md
```

### 3. Make them real HTML

Each variant is a **single self-contained HTML file**:

- Inline `<style>` — no build step, no external CSS
- System fonts or one Google Font via `<link>`
- Tailwind via CDN (`<script src="https://cdn.tailwindcss.com"></script>`) is fine
- Realistic fake content — actual sentences, actual names, not "Lorem ipsum"
- **Interactive**: links clickable, hovers real, at least one state transition (open/close, filter, toggle). A frozen static image is a worse spike than a sloppy animated one.

Open it in a browser. If it looks broken, fix it before showing the user.

**Verify variants visually — use Hermes' browser tools.** Don't just write HTML and hope it renders; load each variant and look at it:

```
browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")
```

`browser_vision` returns an AI description of what's actually on the page plus a screenshot path — catches layout bugs that pure source inspection misses (e.g. a font import that silently failed, a flex container that collapsed). Fix and re-navigate until each variant looks right.

**Default CSS reset + system font stack** for fast starts:

```html
<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>
```

### 4. Variant README

Each variant's `README.md` answers:

```markdown
## Variant: {stance name}

### Design stance
One sentence on the principle driving this variant.

### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...

### Trade-offs
- Strong at: ...
- Weak at: ...

### Best for
- The kind of user or use case this variant actually serves
```

### 5. Head-to-head

After all variants are built, present them as a comparison. Don't just list — **opinionate**:

```markdown
## Three takes on the home screen

| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density   | Low            | High              | Medium        |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |

**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.
```

Let the user pick a winner, or combine two into a hybrid, or ask for another round.

## Theming (when the project has a visual identity)

If the user has an existing theme (colors, fonts, tokens), put shared tokens in `sketches/themes/tokens.css` and `@import` them in each variant. Keep tokens minimal:

```css
/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}
```

Don't over-tokenize a throwaway sketch — three colors and one font is usually enough.

## Interactivity bar

A sketch is interactive enough when the user can:

1. **Click a primary action** and something visible happens (state change, modal, toast, navigation feint)
2. **See one meaningful state transition** (filter a list, toggle a mode, open/close a panel)
3. **Hover recognizable affordances** (buttons, rows, tabs)

More than that is over-engineering a throwaway. Less than that is a screenshot.

## Frontier mode (picking what to sketch next)

If sketches already exist and the user says "what should I sketch next?":

- **Consistency gaps** — two winning variants from different sketches made independent choices that haven't been composed together yet
- **Unsketched screens** — referenced but never explored
- **State coverage** — happy path sketched, but not empty / loading / error / 1000-items
- **Responsive gaps** — validated at one viewport; does it hold at mobile / ultrawide?
- **Interaction patterns** — static layouts exist; transitions, drag, scroll behavior don't

Propose 2-4 named candidates. Let the user pick.

## Output

- Create `sketches/` (or `.planning/sketches/` if the user is using GSD conventions) in the repo root
- One subdir per variant: `NNN-stance-name/index.html` + `README.md`
- Tell the user how to open them: `open sketches/001-calm-editorial/index.html` on macOS, `xdg-open` on Linux, `start` on Windows
- Keep variants disposable — a sketch that you felt the need to preserve should be promoted into real project code, not curated as an asset

**Typical tool sequence for one variant:**

```
terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")
```

Repeat for each variant, then present the comparison table.

## Attribution

Adapted from the GSD (Get Shit Done) project's `/gsd-sketch` workflow — MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done)). The full GSD system ships persistent sketch state, theme/variant pattern references, and consistency-audit workflows; install with `npx get-shit-done-cc --hermes --global`.

## FAQ

### What is an HTML mockup?

An HTML mockup is a disposable, interactive web page built with HTML and basic styling (often inline CSS) to quickly visualize and compare different UI/UX design ideas. It's not meant for production but for early-stage design exploration.

### How many HTML mockup variants does this skill generate?

This skill typically generates 2-3 interactive HTML mockup variants at a time. The goal is to provide contrasting design stances for comparison, not an exhaustive list of minor variations.

### Can I use this skill to create production-ready code?

No, this skill is specifically designed for 'throwaway' HTML mockups to explore design directions. For production-ready components or polished artifacts, you should use other tools or skills like \`claude-design\`.

### What kind of interactivity do the HTML mockups have?

The generated HTML mockups are interactive, meaning links are clickable, hovers are real, and there's at least one state transition (e.g., open/close a panel, filter a list). This allows for a more realistic feel than static images.

### How does this skill help me compare different designs?

After generating the HTML mockups, the skill provides a comparative table that highlights key differences across various design dimensions (e.g., density, layout, aesthetic). It also offers an opinionated summary to guide your decision-making.

### What information do I need to provide to generate an HTML mockup?

To generate effective HTML mockups, you'll be asked about the desired 'feel' (adjectives, vibe), reference apps/sites that capture that feel, and the single most important 'core action' a user performs on the screen.
