La compétence de design frontend de Claude Code : ses forces et ses lacunes

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. La compétence de design frontend se charge lorsque vous demandez un travail d'UI et oriente le modèle vers des choix par défaut plus robustes.

En pratique, les différences les plus systématiques sont les suivantes, et elles sont structurelles plutôt que cosmétiques :

• L'espacement gagne en rythme. Les valeurs proviennent d'une échelle plutôt que d'être choisies élément par élément, préservant ainsi le rythme vertical sur toute la page.
• La hiérarchie devient délibérée. La taille, la graisse et la couleur sont utilisées conjointement pour séparer les niveaux, et non plus la taille seule.
• Moins de mises en page génériques. La grille réflexe de trois cartes identiques apparaît moins souvent lorsque le contenu ne suggère pas réellement trois éléments pairs.
• La gestion des états est intégrée. Le survol (hover), le focus, l'état désactivé et l'erreur apparaissent sans être demandés, là où la plupart des composants générés sont lacunaires.

C'est une amélioration significative, et c'est pourquoi cette compétence vaut la peine d'être installée. C'est également l'intégralité de son périmètre.

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

La compétence indiquera systématiquement au modèle qu'une action primaire nécessite un contraste suffisant avec sa surface et ne doit pas entrer en compétition avec une action secondaire. Elle 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 une compétence pour stocker cela. Elle choisit donc une valeur justifiable. À la session suivante, elle en choisira une autre, tout aussi justifiable.

Ne vous fiez pas uniquement à cela — le test est court et le résultat est sans ambiguïté.

1. 1

   Demandez une carte de tarification dans une nouvelle session

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

2. 2

   Démarrez une session véritablement nouvelle

   Pas un nouveau message — une nouvelle session, pour qu'aucun élément 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 via un 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 avec honnêteté

   Les deux seront d'un aspect professionnel. Lors de nos tests, trois ou quatre de ces quatre valeurs divergeaient — et chacune d'elles constituait un choix raisonnable individuellement.

Conservez la compétence. Elle accomplit une tâche que rien d'autre ne fait. Ajoutez la couche qu'elle ne peut contenir : un ensemble de tokens plus un DESIGN.md dans le repo, que l'agent lira au début de chaque session.

La répartition des tâches est claire une fois que les deux sont en place. Le fichier définit *quel* bleu, *quel* radius, *quelle* échelle typographique. La compétence détermine comment les composer pour obtenir un écran lisible. L'un ne remplace pas l'autre, et l'erreur classique est de supposer que la compétence rend le fichier inutile.

1. 1

   Installer un kit dans le repo

   Ceci écrit 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

   Pointez AGENTS.md vers celui-ci

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

   Copy

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

4. 4

   Relancez le test sur deux sessions

   Même procédure que précédemment. Les valeurs devraient maintenant être exactement identiques, car elles sont lues et non décidées à nouveau.

C'est la question que les gens se 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 lisibles. 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

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

2. 2

   Rendez 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 mentionner dans AGENTS.md comme étant interdits

   Copy

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

4. 4

   Relancez le même build dans une nouvelle session

   Un même primary et un même rayon signifient que la lecture est effective. Des approximations signifient que l'agent se souvient, et la mémoire s'altère.

La plupart des articles à ce sujet sont des compilations 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 pratique réside dans la condition de chargement. Une skill est sélectionnée par le modèle à partir de sa description ; elle n'intervient donc que lorsque votre demande s'apparente à un travail de design. Demandez « une page de paramètres » et elle s'active. Demandez de « corriger le padding à la ligne 40 » et elle pourrait ne pas s'activer, car cela ressemble davantage à une modification qu'à une tâche de design — vous obtiendrez alors une simple modification, sans le savoir-faire pour lequel vous avez installé la skill.

C'est la question que les comptes rendus comparatifs ignorent totalement, alors qu'elle est cruciale une fois que vous possédez les deux. Ils entrent en conflit car ils sont rédigés 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 de la skill stipule qu'une couleur primaire doit respecter un seuil de contraste par rapport à la surface sur laquelle elle repose. Sur une carte claire, ces deux éléments concordent. Sur votre surface sombre et surélevée, ils peuvent diverger.

Aucune des deux couches n'est erronée et il n'existe pas d'arbitre intégré — le modèle tranche, et par défaut, il tranche en faveur de l'instruction la plus spécifique et la plus récente. 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 l'est. Énoncez-le ainsi dans AGENTS.md. Le hex, le radius et l'échelle typographique proviennent du fichier. La manière dont ils sont disposés sur un écran relève du choix de la skill.
2. Offrez à la skill l'échappatoire dont elle a besoin. Le conflit ci-dessus n'existe que parce que le système n'a qu'une seule couleur primaire. Proposez une primaire qui soit également lisible sur vos surfaces sombres, ou une paire documentée, et la divergence disparaîtra au lieu d'être arbitrée à chaque session.
3. Rédigez des interdictions, pas des préférences. « Préférer les tokens sémantiques » perd face à un argument spécifique sur le contraste. « Ne jamais hardcoder les couleurs du thème » ne perd pas, car cela ne laisse rien à évaluer.
4. Attendez-vous à un silence en cas de conflit. Le modèle ne vous dira pas qu'il a outrepassé votre token. Le seul moyen fiable de détection est de chercher dans le diff les valeurs littérales de couleur et d'espacement via un grep.

# 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'

Exécutez cela sur chaque diff généré par un agent. Un résultat propre signifie que les valeurs ont été lues. Tout ce qui est retourné est un endroit où le jugement a discrètement remplacé une décision que vous aviez déjà prise — c'est le même décalage que le test sur deux sessions, mais arrivant par une porte différente.