Tgd Sketch

---
name: tgd-sketch
description: "Throwaway HTML mockups: 2-3 design variants to compare."
version: 1.0.0
author: Hermes Agent (adapted from gsd-build/get-shit-done)
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [sketch, mockup, design, ui, prototype, html, variants, exploration, wireframe, comparison]
    related_skills: [spike, claude-design, popular-web-designs, excalidraw]
---

# Sketch
## Overview

Generate 2-3 disposable HTML mockups to compare design directions before committing to implementation. Each variant is a self-contained HTML file with realistic content, inline CSS, and basic interactivity. The goal is visual comparison, not production code.

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.

## When to Use

- User wants to explore UI/UX directions before building
- User says "sketch this screen", "show me what X could look like", "compare layout A vs B"
- User wants 2-3 takes on a UI to compare visual directions
- User wants a quick mockup before committing to design
- Early-stage design exploration where speed matters more than polish

**Trigger phrases:** "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".

## Common Rationalizations

- **"I'll just build one version"** — Without comparison, you're guessing at the best direction. Two variants take 2x effort but eliminate 80% of redesign risk.
- **"I'll skip the README"** — The README captures *why* each variant makes its choices. Without it, you're comparing pixels, not principles.
- **"One variant is enough"** — One variant is a prototype, not a comparison. The skill's value is in the head-to-head evaluation.

## Red Flags

- Variants that differ only in color/accent — these aren't real alternatives, just recolors
- No interactivity — a static screenshot is worse than a wireframe you can click
- Skipping the intake questions — generating without understanding feel/references/core action produces generic output
- More than 3 variants — diminishing returns; the user can't compare meaningfully
- Production-quality code — sketches are disposable; don't over-invest

## Verification

- Open each variant in a browser and verify it renders correctly
- Check that each variant has a different design stance (not just different colors)
- Verify basic interactivity works (clicks, hovers, state transitions)
- Confirm the comparison table is opinionated — state which variant is strongest and why
- Ensure READMEs explain the trade-offs, not just list features

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

## Where variants live

- **Inside the tGD lifecycle** (called from `/tgd-define`'s UI Design Gate): save variants to `$TGD_DIR/<feature-name>/prototype/` — this is the directory the define/plan verification gates check. Name the three variants after the mandated stances: `conservative/`, `strong-fit/`, `divergent/` (see `tgd-spec-driven-development` Phase 1.5).
- **Ad-hoc sketching** (user just wants mockups, no feature in flight): ask where to put them, defaulting to a scratch location. **Never write into the code repo root** — sketches are throwaway artifacts, not source.

## If the user has the full GSD system installed

Outside the tGD lifecycle only: if `gsd-sketch` is installed (`npx get-shit-done-cc`), it offers persistent sketch state, MANIFEST, and consistency audits. Inside `/tgd-define`, always use THIS skill — the gates check `$TGD_DIR/<feature-name>/prototype/`, not GSD's `.planning/sketches/`.

## 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:** in the tGD lifecycle, use the mandated stance names; ad-hoc, describe the stance, not the number.

```
$TGD_DIR/<feature-name>/prototype/
├── conservative/
│   ├── index.html
│   └── README.md
├── strong-fit/
│   ├── index.html
│   └── README.md
└── divergent/
    ├── 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 the `tgd-agent-browser` skill** (or your platform's browser tooling). Don't just write HTML and hope it renders; open each variant over `file://`, take a screenshot, and look at it. This catches layout bugs that pure source inspection misses (a font import that silently failed, a flex container that collapsed). Fix and re-check 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 `prototype/themes/tokens.css` and `@import` them in each variant. Keep tokens minimal:

```css
/* prototype/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

- In the tGD lifecycle: variants under `$TGD_DIR/<feature-name>/prototype/` (see "Where variants live" above). Ad-hoc: the location the user chose — never the code repo root.
- One subdir per variant: `<stance>/index.html` + `README.md`
- Tell the user how to open them: `open .../prototype/conservative/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 sequence for one variant:** create the variant directory, write `index.html` and `README.md`, open the file in a browser via the `tgd-agent-browser` skill, screenshot, fix anything visibly broken. 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`.