Dhodraj/ui-design

Conception UI

Un agent à qui l'on demande un écran écrit l'écran. Cette compétence comble le fossé de chaque côté. D'abord, décider à quoi la surface sert et à quoi elle doit ressembler. Ensuite, vérifier si ce qui a été construit fait le travail.

Deux règles régissent tout ce qui suit. Nommez le résultat client avant le premier fichier. Pilotez le produit en fonctionnement avant de dire que ça marche.

Choisissez d'abord la profondeur

Le changement	Étapes
Copie, une couleur, une propriété	1, 7, puis regardez le résultat
Un composant, un état	1, 4, 6, 7, 9
Un écran, un formulaire, un flux	0 à 10, brièvement
Une nouvelle surface, ou "rendre ceci moderne"	0 à 10 en entier, avec l'étape 3 approuvée avant l'étape 7
"Auditez ceci"	Utilisez ui-review. Ne commencez pas à modifier
"Trouvez-moi un composant pour…"	Utilisez ui-find

Dites quelle profondeur vous avez choisie, en une ligne, avant de commencer. Une étape n'est ignorée que lorsque le changement ne peut pas atteindre ce que cette étape protège.

0. Pré-vol : lisez le projet avant de demander quoi que ce soit

Lisez, dans cet ordre, et arrêtez-vous dès que la question est résolue :

1. DESIGN.md à la racine du projet. Un système de design qui existe déjà prime sur toutes les valeurs par défaut de cette compétence et sur tous vos goûts personnels. Suivez-le. Lorsque le travail nécessite quelque chose que le fichier ne couvre pas, ajoutez-le au fichier plutôt que de l'inventer dans une feuille de style.
2. PRODUCT.md, README.md, .claude/, un brief existant.
3. La pile, le système de style et la bibliothèque de composants utilisés.
4. L'écran existant le plus proche et les tests qui le couvrent.

Un écran qui contredit le propre système du produit est un constat, pas une licence pour démarrer un troisième système.

1. Le système de design

references/design-system.md contient le format et les deux voies d'accès.

Le projet a	Faites ceci
Un DESIGN.md	Lisez-le, suivez-le, et dites-le en une ligne
Un vrai système de design dans le code : tokens, fichier de thème, config Tailwind	Codifiez-le dans DESIGN.md en lisant les valeurs du code, jamais en les devinant
Un produit en ligne ou une marque sans système écrit	Codifiez à partir du vrai produit : rendez-le, lisez les valeurs calculées, enregistrez-les
Rien	Écrivez-en un à l'étape 3, à partir de la direction choisie par l'utilisateur

N'écrivez jamais un DESIGN.md qui énonce des valeurs que le produit n'utilise pas. Un système codifié est un enregistrement de ce qui existe. Un nouveau système est une proposition, et est marqué comme tel jusqu'à ce que l'utilisateur le choisisse.

Validez le fichier avant de construire dessus :

pnpm dlx @google/design.md lint DESIGN.md

C'est un vrai paquet publié. Il détecte les références de tokens cassées, une primary manquante, une typographie jamais définie, et toute paire de couleur de composant en dessous du seuil de contraste 4.5:1. Corrigez ce qu'il signale avant l'étape 7.

2. Le résultat client

references/product-thinking.md contient la méthode. Le résultat métier, le client et sa tâche, et la plus petite version utile. Deux lignes chacun.

Écrivez le résultat comme quelque chose d'observable :

Un répartiteur avec 40 missions en cours peut voir quelle mission est en retard et la réaffecter sans quitter la liste.

Ensuite, des critères d'acceptation qui peuvent chacun être vérifiés dans un navigateur. "Ça a l'air bien" n'est pas un critère. "À 375px, le statut de chaque mission et son contrôle de réaffectation sont accessibles sans défilement horizontal" en est un.

Lorsqu'il n'y a pas de preuve, écrivez l'hypothèse et étiquetez-la. N'inventez jamais un persona, une citation ou un chiffre de conversion que personne n'a produit.

3. Directions, et le choix de l'utilisateur

references/directions.md contient la méthode et le vocabulaire.

Distribuez trois directions, pas une. Une seule proposition est l'esthétique par défaut du modèle revêtue d'une justification. Chaque direction reçoit un nom, la teinte d'ancrage, la paire typographique, la densité et la chose mémorable, en quatre lignes.

Ensuite, arrêtez-vous et présentez-les à l'utilisateur avec l'outil de question interactive. C'est une porte d'approbation : ne construisez pas au-delà sur une simple hypothèse. Si l'utilisateur dit "choisis toi-même", choisissez-en une, dites laquelle et pourquoi en une ligne, et continuez.

Sur un oui, écrivez ou mettez à jour DESIGN.md avec les vraies valeurs de la direction choisie, et validez-le.

4. Le parcours et ses états

references/journey-and-states.md.

Listez les états que cette surface a réellement : vide, un élément, plusieurs, le cas réel le plus dense, chargement, échec partiel, erreur, pas d'autorisation. Un écran construit sur un seul fixture cache tous les autres états, et c'est la raison la plus courante pour laquelle un écran terminé échoue au contact d'un client.

5. Trouvez les composants avant de les écrire

Exécutez ui-find, ou son script directement :

node .claude/skills/ui-design/scripts/find-components.js <termes> --limit 15

Cherchez d'abord dans les composants du projet. Une seconde implémentation d'un composant que le produit possède déjà est un défaut. N'écrivez un composant à partir de zéro qu'après avoir nommé les candidats lus et expliqué pourquoi chacun était inadapté.

6. Maquette, ou le produit réel

Demandez lequel, en une ligne, sauf si l'utilisateur l'a déjà dit. Les deux voies construisent du vrai HTML et CSS ; la différence réside dans l'endroit où le fichier atterrit et à quoi il est connecté.

Voie	Quand	Où ça va
Maquette	Une nouvelle surface, une refonte, un partie prenante à convaincre, ou l'utilisateur le demande	Une page autonome dans mock/, avec les vrais tokens de design et des données d'exemple qui disent explicitement qu'elles sont des échantillons
Direct	Une modification dans un produit existant, ou l'utilisateur dit de construire	Les propres fichiers du produit

Une maquette est approuvée, puis reconstruite dans les composants du produit. Dites-le avant de la construire, afin que personne ne s'attende à ce que le fichier maquette soit livré.

7. Construire

Construisez les états de l'étape 4, pas seulement le chemin heureux. Utilisez les propres tokens et composants du produit.

Lisez references/gates.md et references/craft.md immédiatement avant la première édition UI, à chaque fois, même pour une petite modification.

gates.md est le plancher : les valeurs par défaut dans lesquelles chaque modèle tombe, et quoi faire à la place. craft.md est la couche au-dessus. La profondeur comme une ombre plutôt qu'une bordure. Des rayons concentriques. Des sorties en douceur sous 300ms. Des entrées qui ne se déclenchent qu'une fois et jamais lors d'une interaction répétée. Des chiffres tabulaires. Deux parties d'un écran connectées, pour que le client voit qu'elles ne font qu'un.

Construisez l'écran le plus important, ou le héros, seul et d'abord. Examinez-le avant de construire le reste, avec un regard neuf : un sous-agent sans mémoire des décisions repère ce que vous ne pouvez pas voir. Construisez ensuite le reste.

8. Exécutez-le et regardez-le

Pas une revue de code. Démarrez l'application, ouvrez-la dans un navigateur et utilisez-la à partir du point d'entrée réel comme le client le ferait.

references/playwright.md contient les mécanismes et la marche à suivre lorsque l'application ne démarre pas ici.

Regardez les captures d'écran. Lire une liste de fichiers n'est pas regarder.

9. Revue et correction

Exécutez ui-review sur ce que vous avez construit. Il mesure le rendu en direct, parcourt le parcours, vérifie le résultat par rapport à DESIGN.md, et trie les constats par gravité.

Corrigez dans l'ordre de gravité. Un changement que vous ne pouvez pas justifier par rapport au résultat de l'étape 2 est un périmètre que personne n'a demandé. Dites ce que vous avez laissé intact et pourquoi.

Ensuite references/regression.md : identifiez les parcours qui fonctionnaient déjà avant de toucher au code, et séparez les échecs causés par votre changement des échecs déjà présents.

10. Rapport

• Le résultat client, et s'il est atteint.
• La direction choisie, et par qui.
• Ce qui a été construit ou modifié, par fichier.
• Ce qui a été vérifié, par quel moyen, à quelles largeurs, dans quels états.
• Ce qui n'a pas été vérifié, et pourquoi.
• Les constats corrigés, et les constats laissés avec leur raison.
• Les hypothèses qui sont encore des hypothèses.

Honnêteté, qui prime sur toutes les étapes ci-dessus

• Ne rapportez jamais une mesure que vous n'avez pas prise ou un écran que vous n'avez pas rendu.
• Nommez chaque substitut. Un fixture pour des données en direct, une page statique pour l'application, une police locale pour celle de la marque.
• Lorsque l'application ne peut pas être démarrée ou atteinte, dites-le et marquez toute affirmation de parcours comme non vérifiée. Ne décrivez pas le code source comme si vous l'aviez vu s'exécuter.
• N'inventez jamais de métrique, de témoignage, de mur de logos ou de nombre de clients. Lorsque le chiffre réel manque, laissez un emplacement étiqueté et dites qu'il est vide.
• Un formulaire sans rien derrière le dit explicitement. Une page qui affiche "Envoyé" sans envoyer est un défaut, pas un espace réservé.
• Parcourir un parcours vous-même trouve des frictions. Cela ne mesure pas ce que font les clients.

Ce que cette compétence emprunte, et d'où

NOTICE l'enregistre. Les sources des composants et leurs licences sont dans sources.json ; scripts/check-sources.js valide ce fichier et tests/run.sh teste les scripts.