Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
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.
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)
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:
## 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:
