Le plugin frontend-design de Claude Code : installation, fonctionnalités et limites

Anthropic livre la compétence de design frontend via le plugin frontend-design, distribué sur la marketplace officielle de plugins Claude Code (vérifié par Anthropic, avec plus d'un million d'installations). Les termes peuvent prêter à confusion : le *plugin* est l'unité d'installation, la *skill* (compétence) est ce qu'il contient et ce qui s'active lors de travaux d'UI. L'installation nécessite deux commandes slash dans une session Claude Code :

1. 1

   Ajouter la marketplace officielle

   Configuration unique ; elle enregistre le catalogue de plugins d'Anthropic.

   Copy

   /plugin marketplace add anthropics/claude-code

2. 2

   Installer le plugin

   Dès lors, la compétence se charge automatiquement dès que votre demande concerne le frontend ; il n'y a rien à invoquer manuellement.

   Copy

   /plugin install frontend-design@claude-code-plugins

Ce que vous obtenez ne sont ni des scripts ni des composants : l'intégralité du contenu du plugin est un fichier SKILL.md de 55 lignes dans le dépôt public d'Anthropic. Nous l'avons analysé, c'est pourquoi la suite de cette page décrit le fichier réel, et non son résumé marketing.

Une compétence est un ensemble d'instructions qui se charge lorsqu'elle est pertinente plutôt qu'à chaque requête : c'est la partie à la demande de la pile agent-file. Celle-ci s'active quand votre demande concerne l'UI (sa description couvre la « création d'une nouvelle UI ou la refonte d'une existante ») et place le modèle dans un rôle spécifique : celui d'un lead design dans un petit studio dont le client a déjà rejeté les propositions basées sur des templates. Les instructions qui suivent sont inhabituellement concrètes :

• Elle identifie les standards de l'IA pour les interdire. Le fichier décrit les trois styles autour desquels le design par IA a tendance à « s'agglutiner » : crème chaud proche de #F4F1EA avec une police serif et un accent terracotta, presque noir avec un accent vert acide ou vermillon, et mise en page type journal à lignes fines sans arrondis. Le modèle est instruit de traiter ces styles comme des défauts à éviter, et non comme des choix. C'est l'équipe d'Anthropic elle-même qui confirme pourquoi les sites web générés par IA se ressemblent tous.
• Elle impose un plan avant le code. Deux étapes : d'abord, brainstormer un système de tokens compact (4 à 6 valeurs hexadécimales nommées, deux rôles typographiques ou plus, un concept de mise en page, un « élément signature » pour lequel la page sera mémorisée), puis critiquer ce plan par rapport au brief en se demandant si le même résultat apparaîtrait pour n'importe quel prompt similaire, et seulement alors, coder.
• Elle traite la typographie et la structure comme des vecteurs de sens. L'association typographique doit porter la personnalité de la page, et les dispositifs structurels comme la numérotation 01 / 02 / 03 ne sont autorisés que lorsque le contenu est réellement une séquence.
• Elle fixe un seuil de qualité. Responsive jusqu'au mobile, focus clavier visible, respect de la réduction des mouvements, ainsi qu'une section entière sur la rédaction d'interface (voix active, « Enregistrer les modifications » plutôt que « Valider », erreurs expliquant ce qui s'est passé).

C'est un brief de design véritablement solide, et c'est la raison pour laquelle le plugin vaut la peine d'être installé. Notez cependant ce que le processus produit : un nouveau système de tokens, inventé pour chaque brief. C'est là que s'arrête son champ d'action, et le fichier lui-même le suggère : « Les créateurs humains ont une mémoire et essaient toujours de faire quelque chose de nouveau ». La compétence n'a pas de mémoire. La vôtre doit résider ailleurs.

Une compétence définit *comment décider*. Elle ne définit pas *ce qui a été décidé*. Cette distinction semble académique jusqu'à ce que l'on compare deux sessions côte à côte.

Relisez le processus en deux étapes : la compétence demande au modèle d' *inventer* un système de tokens de 4 à 6 couleurs et un élément signature pour chaque brief, et de rejeter tout plan ressemblant à ce qu'il produirait pour un prompt similaire. Par session, c'est exactement la bonne instruction ; c'est ce qui rend les écrans uniques. D'une session à l'autre, c'est un moteur de divergence : la compétence n'a aucun moyen de savoir que votre couleur primaire est oklch(0.55 0.19 45), car vous ne lui avez jamais dit et il n'y a aucun endroit dans le fichier pour stocker cette information. Son propre processus pousse chaque nouvelle session vers un système différent, justifiable et inédit.

Ne nous croyez pas sur parole. Le test est court et le résultat sans ambiguïté.

1. 1

   Demandez une carte de tarification dans une nouvelle session

   Avec la compétence active et sans design system présent. Conservez le résultat.

2. 2

   Démarrez une session réellement nouvelle

   Pas un nouveau message : une nouvelle session, afin que rien ne soit conservé.

   Copy

   claude

3. 3

   Demandez un panneau de paramètres pour le même produit

   Même formulation concernant le produit, sans référence au premier composant.

4. 4

   Comparez les deux (diff)

   Comparez la couleur primaire, le border radius, la taille de police de base et l'espacement vertical entre le label et le contrôle.

5. 5

   Analysez le résultat objectivement

   Les deux paraîtront professionnels. Dans nos tests, trois ou quatre de ces quatre valeurs divergent, bien que chacune soit individuellement un choix raisonnable.

Gardez la compétence. Elle remplit une fonction qu'aucun autre outil ne remplace. Ajoutez la couche qu'elle ne peut contenir : un ensemble de tokens plus un fichier DESIGN.md dans le repo, que l'agent lit au début de chaque session.

La division du travail est claire une fois les deux éléments en place. Le fichier répond à la question : *quel* bleu, *quel* radius, *quelle* échelle typographique. La compétence répond à la question : comment les composer pour créer un écran lisible. L'un ne remplace pas l'autre, et l'erreur courante est de supposer que la compétence rend le fichier inutile.

1. 1

   Installez un kit dans le repo

   Ceci génère le fichier DESIGN.md ainsi que les fichiers de tokens que votre agent lira.

   Copy

   npx --yes identityforge@latest install --client claude-code

2. 2

   Appliquez le kit souhaité

   Les kits gratuits ne nécessitent aucun compte.

   Copy

   identityforge apply ambient-sage

3. 3

   Liez AGENTS.md à celui-ci

   Une seule ligne, pour que le contrat de design soit découvrable plutôt qu'accidentel.

   Copy

   Never hardcode theme colors. Use the semantic tokens in DESIGN.md.

4. 4

   Relancez le test des deux sessions

   Même procédure que précédemment. Les valeurs devraient maintenant concorder exactement, car elles sont lues et non redécidées.

C'est la question que les gens posent réellement sur les compétences de design, et presque rien de ce qui est écrit ne permet d'y répondre. La réponse honnête : une compétence ne respecte votre thème que dans la mesure où celui-ci existe sous forme de valeurs qu'elle peut lire. Une compétence est un ensemble d'instructions sur la manière de travailler. Elle n'est pas la source de vos valeurs.

Cette distinction détermine le résultat dans une base de code existante :

Il existe une version mesurable de ce phénomène. Nous avons analysé 299 fichiers DESIGN.md publics et avons constaté que sur les 72 décrivant un système visuel, 86 % n'utilisent aucun nom de rôle de couleur sémantique : ils listent des codes hexadécimaux ou nomment les couleurs par leur teinte. Une compétence à laquelle on donne --primary peut appliquer votre système à un composant que personne n'a décrit. Une compétence à laquelle on donne un tableau de codes hexadécimaux ne peut que copier, et c'est là qu'elle commence à improviser.

1. 1

   Vérifiez si votre thème est lisible

   Cherchez un fichier DESIGN.md ou un fichier de tokens à la racine du dépôt. Si la seule source est Figma, la compétence n'a aucune base de travail.

2. 2

   Rendre les valeurs sémantiques

   Utilisez des rôles plutôt que des teintes, afin que la compétence puisse les placer correctement dans des cas que vous n'avez jamais spécifiés.

3. 3

   Les pointer depuis AGENTS.md comme une interdiction

   Copy

   Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md.

4. 4

   Relancer le même build dans une nouvelle session

   Même couleur primaire, même rayon : cela signifie que le modèle lit les instructions. Des approximations signifient qu'il s'appuie sur sa mémoire, et que celle-ci s'estompe.

La plupart des articles à ce sujet sont des comparatifs qui utilisent ces trois termes indifféremment. Ils ne désignent pas la même chose, et cette différence détermine si l'élément que vous avez installé peut même être chargé.

La conséquence concrète réside dans la condition de chargement. Un skill est sélectionné par le modèle d'après sa description ; il n'intervient donc que si votre requête ressemble à un travail de design. Demandez « une page de paramètres » et il s'active. Demandez de « corriger le padding à la ligne 40 » et il se peut qu'il ne le fasse pas, car cela ressemble à une édition plutôt qu'à une tâche de design, et vous obtiendrez une modification ordinaire sans le soin pour lequel vous avez installé le skill.

C'est la question que les comparatifs ignorent totalement, et c'est pourtant celle qui importe une fois que vous possédez les deux. Ils entrent en conflit car ils sont écrits par des personnes différentes pour des objectifs différents. Votre fichier indique que la couleur primaire est oklch(0.55 0.19 45). Le jugement du skill indique qu'une couleur primaire doit respecter un seuil de contraste avec la surface sur laquelle elle repose. Sur une carte claire, ils sont d'accord. Sur votre surface sombre surélevée, ce n'est peut-être plus le cas.

Aucune des deux couches n'a tort, et il n'y a pas d'arbitre intégré : le modèle tranche, et par défaut, il privilégie l'instruction la plus spécifique et la plus récemment lue. C'est pourquoi la résolution doit être consignée par écrit plutôt que supposée :

1. Les valeurs ne sont pas négociables ; la composition, si. Précisez-le ainsi dans AGENTS.md. Le hex, le rayon et l'échelle typographique proviennent du fichier. La manière dont ils sont agencés sur un écran relève du skill.
2. Offrez au fichier la porte de sortie dont le skill a besoin. Le conflit mentionné ci-dessus n'existe que parce que le système n'a qu'une seule couleur primaire. Proposez une couleur primaire lisible également sur vos surfaces sombres, ou un couple documenté, et le désaccord disparaît au lieu d'être arbitré session après session.
3. Rédigez des interdictions, pas des préférences. « Préférer les tokens sémantiques » perd face à un argument de contraste spécifique. « Ne jamais coder en dur les couleurs du thème » ne perd pas, car cela ne laisse aucune place à l'interprétation.
4. Attendez-vous à un silence en cas de conflit. Le modèle ne vous préviendra pas qu'il a outrepassé votre token. La seule détection fiable consiste à passer un grep sur le diff pour rechercher des valeurs littérales de couleur et d'espacement.

# the only conflict detector that actually fires: literals in the diff
git diff | grep -nE '#[0-9a-fA-F]{3,8}|oklch\(|rgb\(|[0-9]+px'

Faites cela sur chaque diff généré par un agent. Un résultat vide signifie que les valeurs ont été respectées. Tout résultat indique un endroit où un jugement a discrètement remplacé une décision que vous aviez déjà prise ; c'est la même dérive que celle du test des deux sessions, mais arrivant par une autre porte.