Le « Taste Skill » : pourquoi l'intention de design se décide en phase Plan

L'intention de design d'un produit (son design-system, son registre visuel, l'émotion qu'il vise) n'est pas un détail de finition à corriger en Review. C'est un arbitrage qui appartient à la phase Plan. Le « Taste Skill », un petit objet open-source apparu ce printemps, le démontre concrètement.

Dans notre cartographie du SDLC piloté par l'IA, le Plan est l'un des trois gates humains inviolables : le moment où l'intention devient un contrat exécutable, avant qu'une seule ligne ne soit produite. La décision de design, elle, continue d'être reléguée en aval, là où elle coûte le plus cher. Un objet open-source rend cette erreur visible, et réparable. Il mérite qu'on s'y arrête pour ce qu'il révèle du point de levier.

Ce qu'est le Taste Skill, concrètement

Le Taste Skill est un ensemble de fichiers SKILL.md open-source, publiés par un développeur indépendant (Leon Lin) sous le nom de dépôt Leonxlnx/taste-skill, et présentés comme un « anti-slop frontend framework for AI agents ». L'installation tient en une commande : npx skills add https://github.com/Leonxlnx/taste-skill, ou sa forme explicite ciblant un skill précis : npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend". Aucune clé d'API, aucune configuration : le CLI scanne le dossier skills/ du dépôt, dépose le fichier dans le projet, et l'agent le lit automatiquement. On peut aussi copier un SKILL.md dans son repo, ou le coller dans une conversation ChatGPT ou Codex.

Pour comprendre l'objet, il faut comprendre le mécanisme des Agent Skills d'Anthropic. Un Skill est un dossier contenant un fichier SKILL.md, un en-tête YAML (nom, description) suivi d'instructions en Markdown, que l'agent charge dynamiquement quand la tâche s'y prête. Le format repose sur une « divulgation progressive » à trois niveaux : les métadonnées restent toujours en contexte pour environ 100 tokens, le corps du SKILL.md n'est chargé que si la tâche est jugée pertinente, et les fichiers de référence ne sont navigués qu'à la demande. C'est un standard ouvert et portable : le même fichier fonctionne dans Claude Code, Codex, Cursor et d'autres harnais. Le README revendique une compatibilité « framework agnostic », les règles visant l'intention de design et non l'API d'un framework donné, que l'on travaille en React, Vue ou Svelte. La mécanique est désormais éprouvée à l'échelle : la skill officielle frontend-design d'Anthropic, première skill de design largement utilisée et matrice de plusieurs concurrents, a dépassé 277 000 installations. Le Taste Skill relève donc d'une autre catégorie que le modèle ou le plugin propriétaire : de l'instruction versionnée, exactement la matière du Context Engineering.

Le dépôt n'est pas un fichier unique mais un catalogue de sous-skills, chacun pour un usage précis ; on ne les charge pas tous à la fois. Le cœur, design-taste-frontend, est le défaut « le plus sûr » ; sa v2, qualifiée d'expérimentale, est une réécriture substantielle de la v1, devenue le défaut au prochain install, tandis que design-taste-frontend-v1 reste préservée pour qui dépend du comportement exact de l'ancienne. gpt-taste (dossier gpt-tasteskill) est une variante plus stricte pour GPT et Codex, à variance de layout plus haute et direction GSAP plus forte. redesign-existing-projects audite un codebase existant avant d'y toucher ; high-end-visual-design, minimalist-ui et industrial-brutalist-ui imposent une direction visuelle déjà choisie ; full-output-enforcement empêche l'agent de livrer du travail à moitié fait truffé de placeholders ; stitch-design-taste fait le pont avec Google Stitch et un export optionnel DESIGN.md ; image-to-code génère des références visuelles puis les implémente. À part, trois skills de génération d'images (imagegen-frontend-web, imagegen-frontend-mobile, brandkit) produisent des planches de référence, comps web, écrans mobiles, kits de marque, sans code, à passer ensuite à l'agent d'implémentation.

Le skill cœur expose trois « molettes de design » réglables de 1 à 10, déclarées en tête de fichier : DESIGN_VARIANCE (du centré et propre à l'asymétrique et moderne), MOTION_INTENSITY (du simple hover au scroll magnétique) et VISUAL_DENSITY (du luxe aéré au dashboard dense).

Les techniques anti-slop de la v2 sont documentées dans le SKILL.md lui-même. L'inférence de brief : avant tout code, l'agent lit la pièce (type de page, mots d'ambiance, audience, références) puis infère un langage de design, au lieu de basculer par défaut vers le gradient violet et les trois cartes centrées. La cartographie des design-systems : l'agent va chercher le système officiel pertinent plutôt que d'approximer en Tailwind générique. Le README détaille aussi des règles précises et opinionnées : un bannissement strict du tiret cadratin (l'em-dash, tic typographique caractéristique des sorties LLM), des squelettes de code GSAP canoniques pour le motion, un protocole d'audit-redesign pour les projets existants, et surtout une pré-flight check dure : la partie la plus anti-slop, une checklist que chaque case doit franchir honnêtement avant que l'agent ne livre. Le projet se déclare « actively iterating toward v2.0.0 stable » ; la numérotation des sections est donc à considérer comme mouvante.

Sur la traction : le projet est réel et très populaire (MIT, environ 51,8 k étoiles et 3,6 k forks fin juin 2026, une valeur qui monte vite). Le dépôt prend d'ailleurs soin d'avertir qu'il n'a aucun token ni projet crypto affilié, signe à la fois de sa visibilité et de l'écosystème opportuniste qui gravite autour. Quant au récit viral qui a accompagné sa diffusion (un tweet promu, une citation enthousiaste, des métriques de bookmarks et de vues), il reste invérifiable et absent de toute documentation officielle. On retient l'objet technique, pas le bruit.

L'intention de design se décide au Plan, pas en Review

Le « slop » frontend n'est pas un accident esthétique : c'est la conséquence mécanique de la manière dont un LLM génère. Un modèle prédit le token le plus probable ; pour du code d'interface, cette masse de probabilité se concentre sur les conventions qui dominaient GitHub, Dribbble et Tailwind UI entre 2019 et 2024. Anthropic nomme ce phénomène la « convergence distributionnelle ». Demander « fais une belle landing page » sans contrainte, c'est demander la médiane statistique de toutes les landing pages : police Inter, gradient violet-bleu, hero centré, trois cartes à coins arrondis, et le fameux tiret cadratin partout.

Le 7 août 2025, Adam Wathan, co-fondateur de Tailwind CSS, l'a reconnu en public dans un message vu plus d'un million de fois : il s'excusait d'avoir rendu chaque bouton de Tailwind UI bg-indigo-500 cinq ans plus tôt, ce qui a conduit la quasi-totalité des UI générées par IA à virer à l'indigo. Le slop est le comportement par défaut du modèle, sa pente naturelle.

Le réflexe classique consiste à corriger en aval : en revue, on dit « ça fait générique », et l'agent re-génère. À la vitesse de l'IA, ce réflexe est ruineux. Si l'agent produit du slop plus vite qu'un humain ne peut le relire, le goulot devient l'application de l'intention. C'est exactement le piège que décrit notre SDLC : greffer l'IA sur un cycle pensé pour des humains produit un goulot qui répète ses erreurs dix fois plus vite. La revue de design qui arrive après que la page existe arrive trop tard : la direction est déjà figée, et le feedback « this feels off » coûte d'autant plus qu'il intervient après l'engagement de l'agent sur une voie.

D'où le déplacement décisif : l'intention de design relève du Plan. Dans notre cycle, le Plan ouvre des explorations parallèles (code existant, pratiques, frameworks) dont les conflits sont mis à plat avant l'arbitrage humain. La sélection d'un design-system, le registre visuel, les anti-patterns bannis sont précisément des arbitrages de ce type. Les encoder en amont relève du Context Engineering au sens strict de notre Software Factory : verser l'essentiel de l'effort dans la spécification et le contexte structurés, pour que la première passe soit la bonne. Le Taste Skill est donc une brique de la phase Plan : un fichier versionné qui transforme « j'aimerais que ce soit premium », une intention vague que le modèle interprète vers sa médiane, en contraintes lisibles par la machine. Son inférence de brief agit comme un mini-gate de Plan déplacé dans l'outil : décider l'intention avant de coder, puis attendre validation.

Pourquoi un skill, à lui seul, ne suffit pas

Le Taste Skill ne suffit pas, et c'est cohérent avec notre doctrine de l'intention non délégable. La communauté a vu fleurir des approches voisines. La plus aboutie, Impeccable, est éditée par la société Renaissance Geek de Paul Bakaus (créateur de jQuery UI), avec un financement d'a16z et un partenariat GitHub. Impeccable n'est pas une bibliothèque de composants mais un « vocabulaire de design » partagé : des commandes (polish, audit, critique, distill), des fichiers de référence, et un détecteur en ligne de commande qui applique des règles déterministes sans LLM. npx impeccable detect src/ renvoie un code d'erreur exploitable en CI.

La leçon commune de ces outils est nette, et elle borne leur portée : le vocabulaire n'est pas l'intention. Une fois qu'un pattern est partout, il cesse de signaler une décision de design et se met à signaler son absence ; l'antidote au slop d'aujourd'hui devient le slop de demain dès que tout le monde l'adopte. Ces skills relèvent le plancher de qualité ; ils ne décident pas l'intention. Celle-ci reste la prérogative du gate humain. Le Taste Skill encode des règles génériques (« évite le violet », « bannis l'em-dash ») ; ce qu'une équipe doit y ajouter, c'est son design-system, sa marque, ses anti-références.

Installer l'intention de design dans sa phase Plan

Concrètement, comment une équipe installe-t-elle l'intention de design dans sa phase Plan ?

1. Faire du design-system un actif de contexte versionné, pas un PDF dans Figma. Un design-system qui ne vit que dans Figma et Notion est invisible pour les agents. Le principe directeur de notre Software Factory s'applique tel quel : on standardise le contexte et le code en sortie, pas l'outil. Le design-system doit devenir un artefact Markdown (un DESIGN.md, que le skill stitch-design-taste sait exporter, ou un SKILL.md maison), déposé dans le dépôt, chargé automatiquement, et traité comme une dépendance logicielle : versionné, empaqueté, distribué. C'est sa place naturelle dans notre architecture mémoire à trois étages.

2. Forcer l'inférence de brief comme étape de Plan. Avant tout code, l'agent doit produire et faire valider une lecture de design. Un prompt-type, à committer dans le repo : « Avant d'écrire le moindre code : déclare le type de page, l'audience, l'ambiance en trois mots, le design-system retenu (ou son absence justifiée), les anti-patterns bannis, et l'émotion visée. Ne génère aucun code. Sors uniquement la stratégie de design et attends validation. » C'est l'équivalent, côté front, de notre discipline de spec : on capture une décision, on ne croit pas l'agent sur parole quand il affirme avoir « compris le brief ».

3. Transformer la pré-flight check en gate de capitalisation. La checklist anti-slop du Taste Skill ne doit pas rester décorative. Branchée en CI, sur le modèle du detect d'Impeccable qui renvoie un code d'erreur exécutable, elle devient un rail de revue automatisé, et chaque slop attrapé deux fois devient une règle versionnée. C'est notre boucle Compound appliquée au design : un défaut vu deux fois signale un trou dans le système, qu'on rebouche au Plan du cycle suivant.

4. Confier la maille à un rôle clair : le Product Engineer. Dans la Sandwich Team, l'App Owner couvre l'essentiel du périmètre : UX, UI, Front, API, Back, Sécurité. L'intention de design compte parmi ses leviers, pas dans un département à part. Le Product Engineer ne « designe » pas chaque pixel ; il calibre les contraintes (DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY), choisit le design-system, et reste responsable de l'arbitrage que la machine exécute. Comme un bûcheron qui coordonne la machine, pas un artisan qui taille chaque branche à la main.

L'implication dépasse le frontend. Le Taste Skill est le cas d'école d'un mouvement plus profond : rendre le jugement portable. Hier le prompt, puis le contexte, puis le harnais, puis la boucle. À chaque étage, l'ingénieur recule d'un cran et se réinvestit dans le système qui exécute son jugement. Encoder l'intention de design en fichiers, c'est admettre qu'une équipe ne peut pas réexpliquer ses standards à chaque session d'agent. Le code reste le sous-produit ; l'actif réel, c'est le contexte que le projet accumule, y compris son intention de design. La vraie question n'est pas « quel skill installer ? », mais : votre intention de design est-elle décidée au Plan, ou découverte en Review quand il est déjà trop tard ?

Ce qu'on recommande

Cette semaine, pour un coût quasi nul. Installez le Taste Skill v2 sur un projet pilote (npx skills add https://github.com/Leonxlnx/taste-skill) et exécutez la même tâche front avec et sans le skill, dans une session fraîche, pour mesurer l'écart : c'est la méthode d'évaluation qu'Anthropic recommande pour toute skill. Auditez le SKILL.md avant usage. Une skill issue d'une source tierce peut invoquer des outils ; ne l'intégrez pas en production sans relecture.

Ce trimestre. Convertissez votre design-system en artefact Markdown versionné (DESIGN.md ou SKILL.md maison) et placez-le en mémoire chaude. Ajoutez à l'inférence de brief vos anti-références propres. Branchez une pré-flight check en CI. Le seuil de décision est simple : si l'inférence de brief n'est pas validée par un humain avant génération, vous n'avez pas déplacé l'intention au Plan, vous l'avez seulement déguisée.

À l'échelle. Faites du calibrage des molettes et du choix de design-system une responsabilité explicite du Product Engineer et de l'App Owner. L'indicateur de bascule : le jour où le nombre d'itérations « ça fait générique » en Review chute après quelques cycles, votre boucle Compound capitalise réellement l'intention de design. S'il stagne, c'est que vos règles restent génériques et qu'il manque votre contexte de marque.

Quand reconsidérer. Le design-taste-frontend cible le greenfield (landing, portfolio) ; pour un codebase existant, préférez redesign-existing-projects, et quand la direction est déjà arrêtée, l'un des skills dédiés (minimalist-ui, industrial-brutalist-ui, high-end-visual-design). Pour des dashboards ou des UI produit multi-étapes, un design-system officiel (Material, Fluent) doublé de règles maison tient mieux la distance qu'un skill générique.

À garder en tête

• Métrique de notoriété à dater. Environ 51,8 k étoiles fin juin 2026, une valeur qui évolue vite. Ne citez aucun chiffre de popularité sans le dater.
• Le récit viral est invérifiable. Les métriques de bookmarks et de vues qui ont accompagné sa diffusion n'ont pas de source traçable et sont absentes de la documentation officielle. Bruit, pas validation indépendante.
• Projet jeune et mouvant. La v2 est explicitement « expérimentale » et « activement itérée vers la v2.0.0 stable » ; numéros de section et formulation des règles peuvent changer. Épinglez design-taste-frontend-v1 si vous dépendez d'un comportement exact.
• Le vocabulaire n'est pas l'intention. Ces skills relèvent le plancher de qualité et neutralisent les tics du modèle (em-dash, indigo) ; ils ne remplacent ni le jugement humain ni un design-system propre. Adopter un skill, c'est aussi adopter les opinions esthétiques de son auteur, et tout anti-slop générique devient lui-même du slop dès qu'il se généralise.
• Sécurité. Anthropic recommande de ne charger des Skills que de sources de confiance et de les auditer : une skill malveillante peut détourner les outils auxquels l'agent a accès. Règle simple : « treat like installing software ».

Sources

1. Leon Lin, taste-skill (dépôt GitHub, licence MIT) · github.com/Leonxlnx/taste-skill · site officiel : tasteskill.dev. Métriques de popularité lues fin juin 2026.
2. Anthropic, Agent Skills (documentation : format SKILL.md, divulgation progressive, recommandations de sécurité) et skill officielle frontend-design.
3. Adam Wathan (co-fondateur de Tailwind CSS), message public du 7 août 2025 sur bg-indigo-500 et la convergence des UI générées par IA.
4. Renaissance Geek (Paul Bakaus), Impeccable : vocabulaire de design partagé et détecteur CLI déterministe (npx impeccable detect).