Taste Skill : un framework anti-slop pour des interfaces vraiment propres générées par des agents

https://www.tasteskill.dev/ + https://github.com/Leonxlnx/taste-skill

📌 Taste Skill sert à donner du goût à un agent de code quand il fabrique une interface: moins de composants génériques, plus de cohérence visuelle, et surtout des décisions de design explicites plutôt que du « à peu près ».

Quand un agent écrit un frontend, il optimise naturellement pour aller vite: une grille, deux cartes, un bouton primaire bleu, et une page qui ressemble à toutes les autres. Taste Skill traite ce problème comme un sujet d’ingénierie: fournir un ensemble de règles et de garde-fous que l’agent applique à chaque itération pour produire un rendu plus « produit » et moins template.

L’idée est simple: au lieu d’espérer qu’un prompt ponctuel suffise, on installe une base persistante que l’agent relit et respecte. C’est particulièrement utile quand plusieurs agents ou plusieurs sessions se relaient sur le même repo et qu’il faut garder une signature visuelle stable sans repasser une revue UI à chaque commit.

La mise en route se fait en une commande, typiquement via un ajout de skill au projet (ex: npx skills add Leonxlnx/taste-skill). Une fois en place, l’agent peut s’appuyer dessus comme sur un cahier des charges: règles de typographie, densité, hiérarchie, micro-choix qui évitent le « slop » et poussent vers un rendu plus premium.

Le bénéfice au quotidien, c’est de réduire les allers-retours: moins de retouches sur les espacements, les tailles de police, l’alignement, la consistance des states, et plus de temps passé sur la fonctionnalité réelle. Quand l’agent propose un écran, il doit aussi justifier ses choix de structure plutôt que poser des blocs au hasard.

Points clés

• 🎯 Vise un rendu « produit » plutôt qu’une UI générique générée à la chaîne
• 🧭 Donne des règles persistantes à l’agent, utilisables sur toutes les sessions
• 🧱 Structure les décisions UI: hiérarchie, densité, composition, cohérence
• ⚙️ Installation rapide dans un repo, sans réécrire une charte à chaque prompt
• 🔁 Réduit les itérations de polish en imposant des garde-fous dès le premier jet

Au moment où le tooling devient multi-agents, l’intérêt est aussi opérationnel: une base de « goût » partagée sert de contrat implicite entre écrans, PRs et branches. Ça aide à éviter le mélange de styles quand on change de modèle, d’outil, ou simplement de session.

Côté confidentialité, l’approche est pragmatique: le cœur est un ensemble de fichiers/règles que l’agent lit localement dans le projet. L’impact sur les données dépend ensuite de l’agent utilisé, mais le principe de configuration reste le même: on encode des attentes de design dans le repo plutôt que dans une discussion éphémère.

Concrètement, Taste Skill est intéressant dès qu’un projet a besoin d’écrans qui se tiennent ensemble: dashboards, pages settings, flows d’onboarding, ou un marketing site où la crédibilité passe par la finition. C’est une manière de faire monter le standard de sortie des agents, sans devoir transformer chaque génération en séance de direction artistique.