Esquisseur de maquettes HTML

Esquisse

Utilisez cette compétence lorsque l'utilisateur souhaite voir une direction de conception avant de s'engager sur une seule — en explorant une idée UI/UX sous forme de maquettes HTML jetables. L'objectif est de générer 2 à 3 variantes interactives pour que l'utilisateur puisse comparer les directions visuelles côte à côte, et non de produire du code livrable.

Chargez-la lorsque l'utilisateur dit des choses comme « esquisse cet écran », « montre-moi à quoi X pourrait ressembler », « compare la disposition A vs B », « donne-moi 2-3 versions de cette UI », « laisse-moi voir quelques variantes », « fais une maquette avant que je construise ».

Quand NE PAS utiliser cette compétence

• L'utilisateur veut un composant de production — utilisez claude-design ou construisez-le correctement
• L'utilisateur veut un artefact HTML ponctuel et soigné (page de destination, présentation) — claude-design
• L'utilisateur veut un diagramme — excalidraw, architecture-diagram
• La conception est déjà verrouillée — construisez-la simplement

Si l'utilisateur a le système GSD complet installé

Si gsd-sketch apparaît comme compétence sœur (installée via npx get-shit-done-cc --hermes), préférez gsd-sketch pour le flux de travail complet : dossier persistant .planning/sketches/ avec MANIFEST, analyse en mode frontière, audits de cohérence sur les esquisses passées, et intégration avec le reste de GSD. Cette compétence est la version autonome légère — esquisse ponctuelle sans la machine d'état.

Méthode de base

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

1. Prise d'informations (ignorer si l'utilisateur vous a déjà donné suffisamment)

Avant de générer des variantes, obtenez trois choses — une question à la fois, pas toutes en même temps :

1. Ressenti. « Quelle sensation cela doit-il donner ? Adjectifs, émotions, une ambiance. » — « calme, éditorial, comme Linear » vous en dit plus que « minimal ».
2. Références. « Quelles applications, sites ou produits capturent la sensation que vous imaginez ? » — les références concrètes valent mieux que les descriptions abstraites.
3. Action principale. « Quelle est la chose la plus importante qu'un utilisateur fait sur cet écran ? » — les variantes doivent toutes bien servir cela ; sinon, ce ne sont que des décorations.

Réfléchissez brièvement à chaque réponse avant la question suivante. Si l'utilisateur vous a déjà donné les trois dès le départ, passez directement aux variantes.

2. Variantes (2-3, jamais 1, rarement 4+)

Produisez 2-3 variantes en une seule fois. Chaque variante est un fichier HTML complet et autonome. Ne décrivez pas les variantes — construisez-les. L'intérêt est la comparaison.

Chaque variante doit adopter une position de conception différente, pas des valeurs de pixels différentes. Trois bons axes de variation :

• Densité : compact / aéré / ultra-dense (choisissez deux pôles contrastés)
• Accentuation : contenu d'abord / action d'abord / outil d'abord
• Esthétique : éditorial / utilitaire / ludique
• Disposition : colonne unique / barre latérale / volet divisé
• Ancrage : basé sur des cartes / contenu brut / style document

Choisissez un axe et écartez-vous de celui-ci. Deux variantes qui ne diffèrent que par la couleur d'accent sont un effort inutile — l'utilisateur ne peut pas les distinguer.

Nommage des variantes : décrivez la position, pas le nombre.

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

3. Rendez-les en HTML réel

Chaque variante est un fichier HTML unique et autonome :

• <style> en ligne — pas d'étape de construction, pas de CSS externe
• Polices système ou une police Google via <link>
• Tailwind via CDN (<script src="https://cdn.tailwindcss.com"></script>) est acceptable
• Contenu factice réaliste — phrases réelles, noms réels, pas "Lorem ipsum"
• Interactif : liens cliquables, survols réels, au moins une transition d'état (ouverture/fermeture, filtre, bascule). Une image statique figée est une pire exploration qu'une animation bâclée.

Ouvrez-le dans un navigateur. S'il semble cassé, corrigez-le avant de le montrer à l'utilisateur.

Vérifiez visuellement les variantes — utilisez les outils de navigateur d'Hermes. Ne vous contentez pas d'écrire du HTML en espérant qu'il s'affiche ; chargez chaque variante et regardez-la :

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 renvoie une description IA de ce qui se trouve réellement sur la page plus un chemin de capture d'écran — détecte les bogues de mise en page que l'inspection pure du source manque (par exemple, une importation de police qui a silencieusement échoué, un conteneur flex qui s'est effondré). Corrigez et re-naviguez jusqu'à ce que chaque variante semble correcte.

Réinitialisation CSS par défaut + pile de polices système pour des démarrages rapides :

<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 de la variante

Le README.md de chaque variante répond :

## Variante : {stance name}

### Position de conception
Une phrase sur le principe qui motive cette variante.

### Choix clés
- Disposition : ...
- Typographie : ...
- Couleur : ...
- Interaction : ...

### Compromis
- Fort pour : ...
- Faible pour : ...

### Idéal pour
- Le type d'utilisateur ou de cas d'utilisation que cette variante sert réellement

5. Comparaison directe (Head-to-head)

Une fois toutes les variantes construites, présentez-les sous forme de comparaison. Ne vous contentez pas de lister — donnez votre avis :

## Trois versions de l'écran d'accueil

| Dimension | Éditorial calme | Utilitaire dense | Divisé ludique |
|-----------|-----------------|------------------|----------------|
| Densité   | Faible          | Élevée           | Moyenne        |
| Visibilité de l'action principale | Faible | Élevée | Moyenne |
| Scannabilité | Élevée | Moyenne | Faible |
| Ressenti | Calme, fiable | Tranchant, comme un outil | Invitant, énergique |

**Mon avis :** Utilitaire dense pour les utilisateurs avancés, éditorial calme pour les publics axés sur le contenu. Divisé ludique est le plus faible — essaie de faire les deux et ne s'engage dans aucun.

Laissez l'utilisateur choisir un gagnant, ou combinez deux en un hybride, ou demandez un autre tour.

Thématisation (quand le projet a une identité visuelle)

Si l'utilisateur a un thème existant (couleurs, polices, jetons), placez les jetons partagés dans sketches/themes/tokens.css et @importez-les dans chaque variante. Gardez les jetons minimaux :

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

Ne sur-tokenisez pas une esquisse jetable — trois couleurs et une police sont généralement suffisantes.

Barre d'interactivité

Une esquisse est suffisamment interactive lorsque l'utilisateur peut :

1. Cliquer sur une action principale et quelque chose de visible se produit (changement d'état, modale, toast, feinte de navigation)
2. Voir une transition d'état significative (filtrer une liste, basculer un mode, ouvrir/fermer un panneau)
3. Survoler des affordances reconnaissables (boutons, lignes, onglets)

Plus que cela, c'est de la sur-ingénierie pour un jetable. Moins que cela, c'est une capture d'écran.

Mode frontière (choisir ce qu'il faut esquisser ensuite)

Si des esquisses existent déjà et que l'utilisateur dit « que dois-je esquisser ensuite ? » :

• Lacunes de cohérence — deux variantes gagnantes d'esquisses différentes ont fait des choix indépendants qui n'ont pas encore été composés ensemble
• Écrans non esquissés — référencés mais jamais explorés
• Couverture d'état — chemin heureux esquissé, mais pas vide / chargement / erreur / 1000 éléments
• Lacunes responsives — validé à une seule fenêtre d'affichage ; tient-il sur mobile / ultra-large ?
• Modèles d'interaction — des mises en page statiques existent ; les transitions, le glisser, le comportement de défilement n'existent pas

Proposez 2-4 candidats nommés. Laissez l'utilisateur choisir.

Sortie

• Créez sketches/ (ou .planning/sketches/ si l'utilisateur utilise les conventions GSD) à la racine du dépôt
• Un sous-dossier par variante : NNN-stance-name/index.html + README.md
• Dites à l'utilisateur comment les ouvrir : open sketches/001-calm-editorial/index.html sur macOS, xdg-open sur Linux, start sur Windows
• Gardez les variantes jetables — une esquisse que vous avez ressenti le besoin de préserver doit être promue en code de projet réel, pas conservée comme un artefact

Séquence d'outils typique pour une 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="How does this look? Any obvious layout issues?")

Répétez pour chaque variante, puis présentez le tableau de comparaison.

Attribution

Adapté du flux de travail /gsd-sketch du projet GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Le système GSD complet fournit un état persistant des esquisses, des références de modèles de thème/variante et des flux de travail d'audit de cohérence ; installez avec npx get-shit-done-cc --hermes --global.