Design · guide

Les 5 plugins design

Les liens, les commandes exactes, et les trois choses que la vidéo n'avait pas la place de dire : l'ordre d'installation, le prompt qui les active tous, et les conflits entre eux.

Lecture 11 min Niveau débutant Mis à jour le 8 septembre 2026
i am rankMon outil Sois la marque que recommande. Mesure et améliore ta visibilité IA dans ChatGPT, Gemini et les autres moteurs de recherche. Et transforme leurs réponses en clients. Analyser ma marque Sans carte. Ton premier score en 2 minutes.

Pourquoi ton interface a l'air générée

Tu décris une page, le modèle écrit du code qui marche, et le résultat ressemble à toutes les autres pages sorties du même modèle. Fond blanc, carte à coins arrondis, dégradé violet-bleu, un bouton plein et un bouton contour, Inter partout. Ça fonctionne, c'est propre, et ça n'a aucune identité.

La raison est la même que pour le texte. Un modèle de langage produit la suite la plus probable. En design, la suite la plus probable est la moyenne de tout ce qu'il a vu : le composant le plus courant, l'espacement le plus fréquent, la palette la plus consensuelle. Le résultat est une interface statistiquement moyenne.

Ce que les cinq plugins font vraiment

Aucun ne rend le modèle « plus créatif ». Ils lui donnent tous une contrainte extérieure qu'il n'avait pas : un goût de référence, un règlement, un système existant, une image à suivre, ou un retour visuel sur son propre travail. C'est la contrainte qui sort le résultat de la moyenne, pas le talent.

Ils se répartissent en trois familles, et c'est utile de le savoir avant d'installer quoi que ce soit : deux viennent du même dépôt (Taste et Image to Code), un est un registre de fichiers et non une skill (Awesome Design), et un est un outil en ligne de commande qui installe ses propres skills (Playwright CLI). Les mélanger sans le savoir est la première source de problèmes.

Les 5, en un coup d'œil

  1. Taste : le goût de designer

    Donne au modèle un goût de référence tiré d'interfaces premium. C'est celui qui change le plus le rendu dès le premier essai. Leonxlnx/taste-skill

  2. Web Design Guidelines : l'audit

    Relit ton code contre les règles d'interface publiées par Vercel et te sort la liste des points faibles. vercel-labs/agent-skills

  3. Awesome Design : le système complet

    67 systèmes de design prêts à l'emploi, tirés de vrais sites. Couleurs, typo, espacements, composants. bergside/awesome-design-skills

  4. Image to Code : la référence visuelle

    Génère d'abord des références de design, les analyse, puis code au plus près. Même dépôt que Taste. Leonxlnx/taste-skill

  5. Playwright CLI : la vérification

    Claude ouvre un vrai navigateur, capture ce qu'il vient de construire, et corrige ses erreurs avant que tu les voies. @playwright/cli

1. Taste : le goût

Site officiel : tasteskill.dev. Open source, gratuit, compatible Claude Code, Cursor, Codex, Gemini CLI, v0, Lovable et OpenCode.

La page d'accueil de Taste Skill, avec la commande d'installation
Taste se présente comme un « framework anti-slop ». La commande d'installation est sur la page d'accueil
npx skills add Leonxlnx/taste-skill

Cette commande installe la variante par défaut, dont le nom interne est design-taste-frontend. C'est celle qu'il te faut dans 90 % des cas.

Ce que la vidéo n'a pas dit

Taste n'est pas une skill mais une famille de treize variantes dans le même dépôt : une version stricte pour GPT et Codex, une version « audit et refonte » pour les projets existants, trois styles visuels (doux, minimaliste, brutaliste), une variante qui empêche le modèle de laisser des sections à moitié faites, et les variantes de génération d'images. On en choisit une avec le drapeau --skill :

npx skills add https://github.com/Leonxlnx/taste-skill \
  --skill "redesign-skill"

Les trois qui valent le détour après la variante par défaut : redesign-skill si tu reprends un projet existant plutôt que d'en démarrer un, output-skill si Claude a tendance à te rendre des pages avec des sections vides ou des « TODO », et minimalist-skill si le rendu par défaut te paraît trop chargé.

2. Web Design Guidelines : l'audit

Publié par Vercel Labs, dans un dépôt qui contient plusieurs skills : github.com/vercel-labs/agent-skills.

npx skills add vercel-labs/agent-skills

Cette commande installe toute la collection : les bonnes pratiques React, les tokens CSS, les transitions de vue, l'optimisation Vercel, les règles d'écriture, et celle qui nous intéresse. Si tu ne veux que celle-là :

npx skills add vercel-labs/agent-skills \
  --skill "web-design-guidelines"

Son fonctionnement mérite d'être compris, parce qu'il est inhabituel. La skill ne contient pas les règles. Elle contient l'adresse des règles, et elle va les chercher à chaque relecture :

https://raw.githubusercontent.com/vercel-labs/
  web-interface-guidelines/main/command.md

Conséquence pratique : tu n'as jamais besoin de la mettre à jour, et elle ne fonctionne pas hors ligne. Les règles portent sur l'accessibilité au clavier, le contraste, la taille des cibles tactiles, les états de focus, le comportement des formulaires et les animations. Ce sont des points mesurables, pas des questions de goût. C'est pour ça que cette skill et Taste ne se marchent pas dessus.

On l'appelle en demandant une relecture : « relis mon interface », « vérifie l'accessibilité », « audite le design de cette page ».

3. Awesome Design : le système complet

Dépôt : github.com/bergside/awesome-design-skills. C'est le plugin que presque personne n'installe, et c'est celui qui change le plus le résultat sur un projet neuf.

Le registre des 67 systèmes de design, chacun avec sa commande
67 systèmes de design, chacun avec sa vignette et sa commande
Ce n'est pas une skill, et ça ne s'installe pas pareil

Les quatre autres s'ajoutent à ton agent une fois pour toutes. Awesome Design est un registre de fichiers que tu tires dans un projet précis, à chaque fois. La commande n'est pas npx skills add mais :

npx typeui.sh pull <nom>

Par exemple npx typeui.sh pull glassmorphism, ou npx typeui.sh pull editorial. Pour voir la liste complète en interactif :

npx typeui.sh list

Chaque système arrive sous forme de dossier contenant deux fichiers : un SKILL.md avec les instructions pour l'agent (tokens, règles de composants, contraintes d'accessibilité) et un DESIGN.md lisible par un humain, qui explique l'intention et le raisonnement derrière le style.

Les 67 vont de brutalism à claymorphism en passant par editorial, corporate, terracotta, neon, vintage ou paper. Le catalogue avec les aperçus visuels est sur typeui.sh/design-skills : regarde les vignettes avant de choisir, les noms seuls ne veulent pas dire grand-chose.

4. Image to Code : la référence visuelle

C'est le plugin sur lequel tout le monde se trompe, parce qu'il n'a pas de dépôt à lui.

Si tu cherches « image to code » sur GitHub ou dans les annuaires de skills, tu ne trouveras rien. C'est normal : ce n'est pas un dépôt indépendant, c'est une variante de Taste. Le premier et le quatrième plugin de la liste viennent du même endroit.

npx skills add https://github.com/Leonxlnx/taste-skill \
  --skill "image-to-code-skill"
Ce qu'elle fait exactement

Contrairement à ce que le nom laisse croire, elle ne se contente pas de convertir une image que tu lui donnes. Sa description officielle est : « génère d'abord des références de design, les analyse en profondeur, puis implémente le frontend au plus près ». L'étape que les gens ratent est la première : elle fabrique la référence avant de coder, au lieu de coder directement.

Les deux façons de s'en servir :

  1. Avec ta propre référence

    Tu déposes une capture d'écran, une maquette Figma exportée, ou une photo d'un site que tu aimes, et tu demandes de l'implémenter. Elle analyse la hiérarchie, les espacements et le rythme typographique avant d'écrire une ligne.

    Implémente cette page en suivant fidèlement
la référence : [ton image]

  2. Sans référence, en la laissant la créer

    Tu décris ce que tu veux, elle génère d'abord une image de référence, te la montre, puis code d'après. C'est plus lent, et nettement meilleur que de coder à l'aveugle.

    Crée une page de tarifs pour un outil B2B.
Commence par générer la référence visuelle.

5. Playwright CLI : la vérification

Documentation : playwright.dev/agent-cli. Publié par Microsoft, c'est l'outil le plus solide des cinq et le seul qui ne soit pas une skill communautaire.

L'installation se fait en trois temps, et c'est la troisième commande que tout le monde oublie :

npm install -g @playwright/cli@latest
playwright-cli install-browser
playwright-cli install --skills
La troisième commande n'est pas facultative

Les deux premières installent l'outil et le navigateur. Sans install --skills, Claude ne sait pas que l'outil existe : tu auras un navigateur parfaitement installé que ton agent n'utilisera jamais. C'est la panne la plus fréquente sur ce plugin, et elle ne produit aucun message d'erreur.

Une fois en place, Claude dispose d'un vrai navigateur : il ouvre ta page, la capture, lit l'arbre d'accessibilité, clique, remplit des formulaires, lit la console et le réseau. Concrètement, il voit son propre travail au lieu de le supposer.

La boucle qui vaut le coup :

Ouvre localhost:3000, capture la page,
et corrige ce qui ne va pas visuellement.
Vérifie aussi en 375 px de large.

C'est là qu'il attrape ce que tu aurais trouvé toi-même vingt minutes plus tard : un bouton qui déborde sur mobile, une image qui casse la grille, un texte illisible sur son fond, un état de survol oublié.

Playwright CLI ou Playwright MCP ?

Les deux existent et font des choses proches. Le CLI consomme beaucoup moins de contexte : il rend une sortie texte courte, alors que le serveur MCP charge le schéma de tous ses outils dans chaque conversation. Pour du design au quotidien, prends le CLI. Le MCP se justifie sur de l'automatisation exploratoire complexe.

L'ordre d'installation, et pourquoi

L'ordre compte, pour une raison simple : les deux premiers changent le rendu immédiatement, les trois autres ne servent à rien tant que tu n'as pas quelque chose à améliorer.

  1. Taste, en premier, tout seul

    Installe-le, relance une page que tu as déjà faite, et compare. C'est le seul des cinq dont l'effet se voit sans rien changer à ta façon de demander. Si tu installes les cinq d'un coup, tu ne sauras jamais lequel a fait quoi.

  2. Playwright CLI, en deuxième

    Contre-intuitif, mais c'est le bon ordre : il te donne le retour visuel qui rend tous les autres évaluables. Sans lui, tu juges le travail de Claude à l'œil, une page à la fois. Avec lui, il se juge lui-même.

  3. Web Design Guidelines, en troisième

    Une fois que tu produis des pages correctes, l'audit devient utile. Avant, il te sort trente points faibles sur une page qui est de toute façon à refaire.

  4. Awesome Design, au démarrage d'un projet

    Pas au moment où tu installes les autres : au moment où tu commences un projet et où tu sais quelle direction visuelle tu veux. Tiré au milieu d'un projet déjà stylé, il entre en conflit avec l'existant.

  5. Image to Code, quand tu as une référence

    Le dernier, parce qu'il suppose que tu sais déjà à quoi tu veux que ça ressemble. Tant que tu ne le sais pas, la variante par défaut de Taste fait un meilleur travail toute seule.

Le prompt de démarrage

Une fois les cinq en place, ils ne se déclenchent pas tous seuls au bon moment. Ce prompt les met dans le bon ordre sur un projet neuf. Colle-le tel quel au démarrage :

Je démarre une nouvelle interface : [décris le projet].

Procède dans cet ordre :
1. Tire le système de design le plus adapté avec
   typeui.sh et explique-moi ton choix en deux lignes
2. Génère une référence visuelle et montre-la-moi
   avant d'écrire du code
3. Implémente en suivant la référence et le système
4. Ouvre le résultat dans le navigateur, capture-le,
   et corrige ce qui ne va pas, vérifie aussi en 375 px
5. Termine par une relecture selon les règles
   d'interface, et donne-moi la liste des points faibles

Ne passe pas à l'étape suivante sans avoir fini
la précédente.
Pourquoi ça marche mieux qu'une demande normale

Chaque étape correspond à un plugin, dans l'ordre où leurs contraintes doivent s'appliquer : le système d'abord, la référence ensuite, le code après, la vérification visuelle, puis l'audit. La dernière ligne est celle qui compte le plus : sans elle, le modèle enchaîne les cinq étapes en une seule réponse et n'en fait correctement aucune.

Les conflits dont personne ne parle

Les cinq ne sont pas indépendants. Trois frictions reviennent souvent, et aucune n'est documentée dans les dépôts.

  1. Taste et Awesome Design se disputent la direction visuelle

    Les deux imposent un système. Taste applique son goût de référence, Awesome Design applique le système que tu as tiré. Sur un même projet, le résultat oscille entre les deux d'une page à l'autre.

    Ce qu'il faut faire : décide lequel commande. Si tu as tiré un système avec typeui.sh, dis-le explicitement : « respecte le DESIGN.md du projet, il fait autorité sur le style ». Sinon, laisse Taste seul aux commandes.

  2. L'audit Vercel contredit certains partis pris esthétiques

    Les systèmes à faible contraste (soft, paper, plusieurs styles minimalistes) produisent des textes gris clair sur fond clair. L'audit les signalera systématiquement, et il a raison sur l'accessibilité.

    Ce qu'il faut faire : ne « corrige » pas en assombrissant tout, tu détruirais le style. Assombris seulement le texte courant et les libellés d'action, garde le gris clair pour le décor. Le contraste ne se négocie que sur ce qui est purement décoratif.

  3. Le navigateur ne voit pas ce que tu vois

    Playwright ouvre une page vierge : pas ta session, pas tes cookies, pas tes données. Sur une page derrière une authentification, il capture l'écran de connexion et déclare que tout va bien.

    Ce qu'il faut faire : donne-lui une page publique à vérifier, ou une route de démonstration avec des données d'exemple. Et lis toujours la capture qu'il produit : c'est elle qui te dit ce qu'il a réellement regardé.

Les erreurs du premier essai

  1. Installer les cinq d'un coup

    Tu ne sauras pas lequel a produit quoi, et au premier résultat bizarre tu n'auras aucune idée de quoi désinstaller. Un par un, avec un vrai test entre chaque. Compte une demi-heure, pas plus.

  2. Oublier install --skills sur Playwright

    Ça mérite d'être répété : sans cette commande, l'outil est installé et l'agent l'ignore. Aucun message d'erreur, aucun symptôme, juste un plugin qui ne sert à rien.

  3. Chercher un dépôt « Image to Code »

    Il n'existe pas. C'est une variante de Taste, et elle s'installe avec le drapeau --skill sur le dépôt de Taste. Ceux qui cherchent un dépôt séparé finissent par installer un outil de génération d'images qui n'a rien à voir.

  4. Choisir un système de design sur son nom

    Sur les 67, les noms sont trompeurs : corporate est bien plus élégant qu'il n'en a l'air, creative est souvent trop chargé pour un vrai produit. Ouvre typeui.sh/design-skills et regarde les vignettes. Deux minutes qui t'évitent de refaire ton interface.

  5. Croire qu'un plugin remplace une décision

    Les cinq améliorent l'exécution. Aucun ne décide à quoi ressemble ton produit, à qui il parle, ni ce qui doit sauter aux yeux en premier sur la page. Une interface techniquement irréprochable qui met en avant la mauvaise chose reste une mauvaise interface.

Le vrai critère

La question n'est pas « est-ce que ça a l'air fait par un designer ». C'est « est-ce qu'un utilisateur trouve en trois secondes ce qu'il est venu chercher ». Les plugins règlent l'apparence ; la hiérarchie de l'information reste ton travail.