pretty-ui

Que fait pretty-ui ?

Les écrans créés par l'IA se ressemblent tous parce que personne n'a fait de choix. Le modèle comble chaque vide avec la réponse la plus courante qu'il a vue, et le résultat est une page qui pourrait appartenir à n'importe quel produit.

pretty-ui corrige cela dans l'ordre qu'un designer suivrait : choisir une direction, l'écrire, puis l'appliquer partout et vérifier le résultat. Le choix est fait par la personne, à partir d'options réelles qu'elle peut voir, et non par l'agent seul.

Le déroulement

Suivez ces étapes dans l'ordre. Dites à l'utilisateur sur quelle étape vous êtes.

1. Lire le projet

• Trouvez ce qui est construit : une page qui se lit et se défile (page d'accueil, site marketing, portfolio), un écran d'application web où les gens travaillent (tableau de bord, paramètres, boîte de réception), ou une application mobile.
• Trouvez la stack : HTML simple, Tailwind, shadcn/ui, React, Vue, Svelte, React Native, SwiftUI, Compose ou Flutter. Travaillez dans cette stack. Ne la migrez jamais.
• Cherchez un système visuel existant : DESIGN.md, AGENTS.md ou notes de design dans CLAUDE.md, variables de thème Tailwind ou shadcn, un guide de marque, un logo. Si la marque a déjà des couleurs et des polices, conservez-les. Les directions à l'étape 3 varient alors la mise en page, l'échelle typographique, la densité et les accents à l'intérieur de la marque, pas la marque elle-même.
• Collectez le contenu réel : le nom du produit, ce qu'il fait, à qui il s'adresse, des chiffres réels, des captures d'écran réelles. Le contenu factice rend tous les designs génériques.

2. Audit (uniquement lorsque l'interface existe déjà)

Lisez references/tells.md. Exécutez le vérificateur sur les fichiers qui rendent l'interface :

node <skill>/scripts/check.mjs <fichiers ou dossiers>

Listez les résultats pour l'utilisateur, groupés par sévérité, avec le fichier et la ligne. Ajoutez tout ce que le vérificateur ne peut pas voir en lisant le code : trois cartes identiques, tout centré, aucun point focal clair, texte de remplissage. Si l'écran est déjà bien conçu, dites-le et suggérez deux ou trois petites améliorations au lieu d'une refonte.

3. Proposer trois directions

Lisez references/systems.md. Il liste 24 systèmes de design complets, 12 pour le web et 12 pour les applications mobiles, chacun avec un DESIGN.md public.

1. Choisissez trois systèmes qui diffèrent volontairement : par exemple un clair et éditorial, un sombre et dense, un doux et amical. Faites correspondre la plateforme (web ou app) et l'univers du produit. Ne proposez jamais trois variations du même aspect.
2. Récupérez le DESIGN.md de chaque système depuis son URL.
3. Construisez le même écran clé dans chaque direction, avec le même contenu réel, sous forme de fichiers HTML autonomes :
   • pretty-ui/directions/a-<slug>.html, b-<slug>.html, c-<slug>.html
   • Pages web à 1440×900, écrans mobiles à 390×844. CSS en ligne, liens Google Fonts, aucune image externe.
4. Facilitez la comparaison :
   • Si les outils de canvas de Codex Design sont disponibles (par exemple create_canvas et add_node), placez les trois fichiers côte à côte sur un canvas et ouvrez-le.
   • Sinon, exécutez node <skill>/scripts/compare.mjs pretty-ui/directions/*.html --out pretty-ui/directions/index.html et dites à l'utilisateur d'ouvrir ce fichier.
5. Demandez à l'utilisateur d'en choisir une, ou de combiner des parties (« la typographie de A avec les couleurs de C »). S'il vous a demandé de décider, choisissez celle qui correspond le mieux au produit et dites pourquoi en une phrase.

Lorsque la marque est fixée, les trois directions utilisent ses couleurs et polices et diffèrent par la mise en page, l'échelle et la densité.

4. Écrire le système

• Enregistrez le système choisi sous forme de DESIGN.md à la racine du projet. Gardez son format : en-tête YAML avec les jetons, puis Aperçu, Couleurs, Typographie, Mise en page, Formes, Composants et À faire et À ne pas faire.
• Appliquez toute modification demandée par l'utilisateur (une couleur de marque, une police de titres différente) dans le fichier, pas seulement dans le code.
• Ajoutez une ligne dans AGENTS.md (et CLAUDE.md si le projet en a une) : Follow DESIGN.md for every screen: colors, type, spacing, radius and components. Codex lit AGENTS.md automatiquement mais pas DESIGN.md.
• Pour les projets shadcn ou Tailwind, mappez les jetons dans les variables de thème (--background, --primary, --radius et les autres). Chaque page de système lie un thème shadcn prêt : npx shadcn@latest add https://codexdesign.io/r/<slug>.json.

5. Appliquer, passe par passe

Travaillez sur tout l'écran une couche à la fois, comme une revue de design. Conservez les fonctionnalités, le contenu et l'ordre des sections sauf si l'utilisateur en a décidé autrement.

1. Jetons. Remplacez les couleurs, tailles et rayons codés en dur par les jetons du système.
2. Typographie. Deux familles au maximum. Utilisez l'échelle du système. Faites en sorte que la ligne la plus importante de l'écran soit clairement la plus grande. Chiffres tabulaires pour les nombres qui s'alignent.
3. Espacement et mise en page. Une unité d'espacement du système et ses multiples. Alignez tout sur la grille ou le remplissage de l'écran. Regroupez les éléments liés de manière serrée et séparez généreusement les groupes.
4. Couleur. Les neutres portent l'écran. La couleur primaire apparaît là où l'utilisateur agit, environ une fois par vue. Les graphiques utilisent les couleurs du système dans l'ordre.
5. Composants. Boutons, champs de saisie, cartes, listes et navigation suivent la section Composants du système. Icônes réelles (Lucide, Phosphor, SF Symbols, Material Symbols), jamais d'émoji comme icônes.
6. Texte. Des mots simples et spécifiques du produit. Coupez le remplissage (« inégalé », « débloquer », « propulser »). Les titres disent ce que la chose est ou fait.
7. Détails. États de survol, de focus et d'enfoncement ; états vides, de chargement et d'erreur ; contraste d'au moins 4.5:1 pour le texte.
8. Mouvement. Uniquement là où il explique quelque chose : un changement d'état, une transition entre écrans. Pas d'apparition en fondu sur chaque section, pas de décoration pulsante.

Pour les applications mobiles, lisez aussi references/app.md.

6. Vérifier

• Exécutez à nouveau le vérificateur sur les fichiers modifiés et corrigez chaque erreur et autant d'avertissements qu'il est raisonnable.
• Regardez le résultat. Si Playwright ou un outil de navigateur est disponible, prenez une capture d'écran à 1440 et 390 de large (ou la taille de l'appareil pour les apps) et corrigez ce qui ne va pas : pas de point focal, groupes serrés, texte qui se coupe mal, faible contraste.
• Pour une refonte, créez une page avant/après que l'utilisateur puisse partager :

node <skill>/scripts/compare.mjs before.html after.html --labels "Avant,Après" --out pretty-ui/avant-apres.html

7. Rapport

Dites à l'utilisateur, brièvement : la direction choisie et pourquoi, les fichiers modifiés, ce que le vérificateur a trouvé avant et après, et tout ce qui nécessite sa décision (photos réelles, un logo, du texte que seul lui peut écrire).

Règles qui s'appliquent toujours

• Montrez les options avant de vous engager sur l'une d'elles. Ne choisissez jamais un style en silence.
• Conservez la marque, le contenu et la stack de l'utilisateur.
• Un seul système de design par produit, écrit dans DESIGN.md, suivi partout.
• Pas de dégradés violets ou pourpres, de texte dégradé, de panneaux en verre dépoli, d'ombres lumineuses, d'icônes emoji, de badges en forme de pilule au-dessus de chaque titre, ou de rangées de cartes icônes identiques, sauf si l'utilisateur les veut explicitement.
• Ne remplacez pas un cliché par un autre. Le crème avec une police serif et un accent terre cuite, ou le presque noir avec un accent vert acide, sont les nouveaux défauts ; utilisez-les uniquement lorsque l'univers du produit les appelle.
• Supprimer la décoration est la moitié du travail. Remplissez l'espace avec du contenu réel, une typographie plus grande pour ce qui compte, et un élément mémorable issu du produit lui-même.

Fichiers

• references/systems.md : les 24 systèmes de design, avec plateforme, style et URL du DESIGN.md.
• references/tells.md : ce qui fait qu'une interface a l'air générée par IA, et quoi faire à la place.
• references/app.md : règles pour les écrans iOS, Android et cross-platform.
• scripts/check.mjs : vérificateur statique des artefacts IA dans les fichiers HTML, CSS, JSX, TSX, Vue et Svelte. Node 18+, aucune dépendance.
• scripts/compare.mjs : écrit une page HTML qui montre plusieurs écrans côte à côte, pour choisir une direction ou montrer un avant/après.