Schizza Mockup HTML

Sketch

Usa questa abilità quando l'utente vuole vedere una direzione di design prima di impegnarsi in una — esplorando un'idea UI/UX come mockup HTML usa e getta. Il punto è generare 2-3 varianti interattive in modo che l'utente possa confrontare le direzioni visive fianco a fianco, non produrre codice distribuibile.

Carica questa quando l'utente dice cose come "fammi uno sketch di questa schermata", "mostrami come potrebbe apparire X", "confronta il layout A con B", "dammi 2-3 interpretazioni su questa UI", "fammino vedere alcune varianti", "mockuppa questo prima che lo costruisca".

Quando NON usarla

• L'utente vuole un componente di produzione — usa claude-design o costruiscilo propriamente
• L'utente vuole un artefatto HTML rifinito una tantum (landing page, deck) — claude-design
• L'utente vuole un diagramma — excalidraw, architecture-diagram
• Il design è già definito — costruiscilo e basta

Se l'utente ha il sistema GSD completo installato

Se gsd-sketch appare come abilità sorella (installata tramite npx get-shit-done-cc --hermes), preferisci gsd-sketch per il flusso di lavoro completo: .planning/sketches/ persistente con MANIFEST, analisi in modalità frontiera, audit di coerenza tra gli sketch passati e integrazione con il resto di GSD. Questa abilità è la versione leggera standalone — sketching una tantum senza la macchina a stati.

Metodo principale

raccolta  →  varianti  →  testa a testa  →  scegli il vincitore (o itera)

1. Raccolta (salta se l'utente ti ha già dato abbastanza)

Prima di generare varianti, ottieni tre cose — una domanda alla volta, non tutte insieme:

1. Sensazione. "Che sensazione dovrebbe dare? Aggettivi, emozioni, un'atmosfera." — "calmo, editoriale, come Linear" ti dice più di "minimale".
2. Riferimenti. "Quali app, siti o prodotti catturano la sensazione che immagini?" — i riferimenti concreti battono le descrizioni astratte.
3. Azione principale. "Qual è la singola cosa più importante che un utente fa su questa schermata?" — le varianti dovrebbero tutte servirla bene; se non lo fanno, sono solo decorazioni.

Rifletti brevemente su ogni risposta prima della domanda successiva. Se l'utente ti ha già dato tutte e tre in anticipo, salta direttamente alle varianti.

2. Varianti (2-3, mai 1, raramente 4+)

Produci 2-3 varianti in un colpo solo. Ogni variante è un file HTML completo e autonomo. Non descrivere le varianti — costruiscile. Il punto è il confronto.

Ogni variante dovrebbe assumere una posizione di design diversa, non valori di pixel diversi. Tre buoni assi di varianti:

• Densità: compatto / arioso / ultra-denso (scegli due poli contrastanti)
• Enfasi: contenuto-prima / azione-prima / strumento-prima
• Estetica: editoriale / utilitaristica / giocosa
• Layout: singola colonna / barra laterale / pannello diviso
• Fondamento: basato su card / contenuto nudo / stile documento

Scegli un asse e tira da esso. Due varianti che differiscono solo per il colore dell'accento sono uno sforzo sprecato — l'utente non può distinguerle.

Nomenclatura delle varianti: descrivi la posizione, non il numero.

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

3. Rendili HTML reale

Ogni variante è un singolo file HTML autocontenuto:

• <style> inline — nessun passo di build, nessun CSS esterno
• Font di sistema o un Google Font tramite <link>
• Tailwind via CDN (<script src="https://cdn.tailwindcss.com"></script>) va bene
• Contenuto falso realistico — frasi reali, nomi reali, non "Lorem ipsum"
• Interattivo: link cliccabili, hover reali, almeno una transizione di stato (apri/chiudi, filtro, toggle). Un'immagine statica congelata è un picco peggiore di uno animato trasandato.

Aprilo in un browser. Se appare rotto, sisteMalo prima di mostrarlo all'utente.

Verifica visivamente le varianti — usa gli strumenti del browser di Hermes. Non scrivere solo HTML e sperare che venga renderizzato; carica ogni variante e guardala:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Questo layout sembra pulito e leggibile? Qualche bug visibile (testo sovrapposto, elementi non stilizzati, immagini rotte)?")

browser_vision restituisce una descrizione AI di ciò che è effettivamente sulla pagina più un percorso allo screenshot — cattura i bug di layout che l'ispezione pura del sorgente perde (es. un import di font silenziosamente fallito, un contenitore flex collassato). Sistema e ri-naviga finché ogni variante sembra a posto.

Reset CSS predefinito + stack di font di sistema per inizi rapidi:

<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. README della variante

Il README.md di ogni variante risponde:

## Variant: {nome posizione}

### Posizione di design
Una frase sul principio che guida questa variante.

### Scelte chiave
- Layout: ...
- Tipografia: ...
- Colore: ...
- Interazione: ...

### Compromessi
- Forte in: ...
- Debole in: ...

### Ideale per
- Il tipo di utente o caso d'uso che questa variante serve effettivamente

5. Testa a testa

Dopo che tutte le varianti sono state costruite, presentale come un confronto. Non limitarti a elencare — esprimi un'opinione:

## Tre interpretazioni per la schermata home

| Dimensione | Calmo editoriale | Utilitaristico denso | Giocoso diviso |
|-----------|---------------------|----------------------|---------------|
| Densità   | Bassa                | Alta                  | Media          |
| Visibilità azione principale | Bassa | Alta | Media |
| Scansionabilità | Alta | Media | Bassa |
| Sensazione | Calma, fidata | Tagliente, simile a uno strumento | Invitante, energica |

**Il mio parere:** Utilitaristico denso per power user, calmo editoriale per pubblici orientati ai contenuti. Giocoso diviso è il più debole — cerca di fare entrambi e non si impegna in nessuno.

Lascia che l'utente scelga un vincitore, o combini due in un ibrido, o chieda un altro giro.

Tematizzazione (quando il progetto ha un'identità visiva)

Se l'utente ha un tema esistente (colori, font, token), metti i token condivisi in sketches/themes/tokens.css e fai @import in ogni variante. Mantieni i token minimi:

/* 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;
}

Non tokenizzare eccessivamente uno sketch usa e getta — tre colori e un font di solito sono sufficienti.

Barra di interattività

Uno sketch è abbastanza interattivo quando l'utente può:

1. Cliccare un'azione primaria e qualcosa di visibile succede (cambio di stato, modale, toast, finta navigazione)
2. Vedere una transizione di stato significativa (filtrare una lista, togglare una modalità, aprire/chiudere un pannello)
3. Hover su affordance riconoscibili (pulsanti, righe, tab)

Più di questo è sovra-ingegnerizzare un usa e getta. Meno di questo è uno screenshot.

Modalità frontiera (scegliere cosa sketchare dopo)

Se gli sketch esistono già e l'utente dice "cosa dovrei sketchare dopo?":

• Lacune di coerenza — due varianti vincenti da sketch diversi hanno fatto scelte indipendenti che non sono state ancora composte insieme
• Schermate non sketchate — referenziate ma mai esplorate
• Copertura degli stati — percorso felice sketchato, ma non vuoto / caricamento / errore / 1000 elementi
• Lacune responsive — validato solo a un viewport; regge su mobile / ultra-wide?
• Schemi di interazione — esistono layout statici; transizioni, trascinamento, comportamento di scroll no

Proponi 2-4 candidati nominati. Lascia che l'utente scelga.

Output

• Crea sketches/ (o .planning/sketches/ se l'utente sta usando convenzioni GSD) nella radice del repo
• Una sottocartella per variante: NNN-nome-posizione/index.html + README.md
• Di' all'utente come aprirli: open sketches/001-calm-editorial/index.html su macOS, xdg-open su Linux, start su Windows
• Mantieni le varianti usa e getta — uno sketch che hai sentito il bisogno di preservare dovrebbe essere promosso a codice di progetto reale, non curato come un asset

Sequenza tipica di strumenti per una variante:

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="Come appare? Problemi di layout ovvi?")

Ripeti per ogni variante, poi presenta la tabella di confronto.

Attribuzione

Adattato dal flusso di lavoro /gsd-sketch del progetto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Il sistema GSD completo offre stato dello sketch persistente, riferimenti a pattern di tema/variante e flussi di lavoro di audit di coerenza; installa con npx get-shit-done-cc --hermes --global.