Sketch: Generate throwaway HTML mockups with Hermes Agent

Sketch is a Hermes Agent skill for generating 2-3 disposable HTML mockups so you can compare visual directions before committing to a design. It is for the early exploration phase: when you want to see what a screen could look like, not when you need shippable code. Reach for it when you hear yourself say "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", or "mockup this before I build".

What it does

Sketch produces a small set of standalone HTML files, each representing a distinct design stance. The goal is not to polish one artifact but to create a head-to-head comparison that helps you pick a direction. The skill guides you through intake (gathering the feel, references, and core action), variant generation (2-3 files with different design axes), visual verification using Hermes' browser tools, and a structured comparison table. Variants are meant to be thrown away once you decide; if you want to keep one, promote it into real project code.

Before you start

Hermes Agent must be installed and running. Sketch is a bundled skill, so no extra installation is needed.
The skill works on Linux, macOS, and Windows.
You need a browser to open the generated HTML files. The skill uses Hermes' browser_navigate and browser_vision tools to verify variants visually.
If you have the full GSD system installed (via npx get-shit-done-cc --hermes), the sibling skill gsd-sketch offers a fuller workflow with persistent state and consistency audits. This standalone sketch skill is the lightweight, maintained path and needs nothing extra.

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:

Feel. "What should this feel like? Adjectives, emotions, a vibe.", "calm, editorial, like Linear" tells you more than "minimal".
References. "What apps, sites, or products capture the feel you're imagining?", actual references beat abstract descriptions.
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:

<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:

## 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:

## 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:

/* 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:

Click a primary action and something visible happens (state change, modal, toast, navigation feint)
See one meaningful state transition (filter a list, toggle a mode, open/close a panel)
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.

When not to use it

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

Limits and gotchas

Variants are throwaway by design. Do not treat them as assets to curate; promote a winner into real code if you want to keep it.
The upstream GSD project (gsd-build/get-shit-done) is archived / no longer maintained on GitHub. The npm package (get-shit-done-cc) still installs, but treat it as an archived community project, this standalone sketch skill is the maintained path and needs nothing extra.
Two variants that differ only in accent color are wasted effort, the user can't distinguish them.
A frozen static image is a worse spike than a sloppy animated one. Ensure at least one state transition.
Over-tokenizing a throwaway sketch is counterproductive. Three colors and one font is usually enough.

Related skills

spike, for broader technical exploration
claude-design, for production components or polished HTML artifacts
popular-web-designs, for inspiration from existing patterns
excalidraw, for diagrams and wireframes

Attribution

Adapted from the GSD (Get Shit Done) project's /gsd-sketch workflow, MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). The upstream GSD repo is now archived/unmaintained on GitHub; the get-shit-done-cc npm package still installs (npx get-shit-done-cc --hermes --global) and ships persistent sketch state, theme/variant pattern references, and consistency-audit workflows, but treat it as an archived community project.

Sketch: Generate throwaway HTML mockups for UI/UX design exploration