Skills d’audit de design : Impeccable, Vercel

Demandez à un agent de code de relire une page de tarifs, et sa réponse ressemble souvent à des impressions : la hiérarchie pourrait être plus nette, les cartes semblent lourdes, il faudrait plus d’espace blanc. Aucun fichier n’est cité, et rien ne dit quelle remarque compte le plus. Plusieurs skills ouverts transforment ça en vraie revue. Pour l’audit en profondeur d’un composant ou d’une route, j’installerais design-grill, de molveau/skills : sept angles d’analyse en lecture seule, un vérificateur pour chaque problème objectif et un seul rapport classé, avec un file:line pour chaque défaut. C’est aussi l’option la plus coûteuse de la liste, et pour une passe rapide sur une branche ou pour vérifier une page affichée, un autre skill fera mieux l’affaire. Les sections plus bas disent lequel.

Les outils en lice

Skill	Auteur	Licence	Sa force	Ses limites
Impeccable (critique, audit)	Paul Bakaus	Apache-2.0	Une critique UX notée, un audit technique classé de P0 à P3, un détecteur qui analyse aussi une URL en ligne	Aucune contre-vérification de chaque problème ; il faut l’installer, l’initialiser et lui fournir des fichiers de contexte
skills (better-interface, interface-review)	Jakub Krehel	MIT	Une revue classée d’un écran, et une revue limitée à ce qu’une branche a changé	Ni script ni vérificateur : chaque problème relève du jugement du modèle
web-design-guidelines	Vercel	MIT	Une passe rapide des fichiers selon les Web Interface Guidelines de Vercel, avec une sortie file:line concise	Aucun jugement sur la hiérarchie ou la direction ; il télécharge ses règles à chaque exécution
web-quality-skills	Addy Osmani	MIT	Des mesures prises sur une page qui tourne : Lighthouse, traces de performance, Core Web Vitals	Aucun jugement sur le design visuel, et il ne prétend pas en avoir
design-review	Patrick Ellis (OneRedOak)	MIT	Un sous-agent Claude Code qui navigue dans une préversion en ligne avec Playwright, sur trois largeurs d’écran	Pas un skill à installer : il faut copier ses fichiers, et il lui faut une préversion qui tourne et le MCP Playwright
design-grill	Molveau Studio	MIT	Sept angles sur une même cible, des problèmes objectifs vérifiés, un seul rapport classé selon les variables de design du projet	Ne voit pas la page affichée ; son mode par défaut exige l’outil Workflow de Claude Code et beaucoup d’appels d’agents

Chacun, sans parti pris

critique et audit, de l’Impeccable de Paul Bakaus

critique note un design selon des heuristiques d’utilisabilité et classe ce qu’il faut corriger en premier. audit vérifie l’accessibilité, la performance, les thèmes et l’adaptation aux écrans, et classe les problèmes de P0 (bloquant) à P3 (finition). Son détecteur fonctionne sans modèle ni clé d’API et, si vous lui donnez une URL, il vérifie aussi ce que seule une page affichée révèle, comme un contraste trop faible ou un texte minuscule. Une extension Chrome superpose les mêmes constats à n’importe quelle page en ligne. Installez Impeccable si vous voulez la critique notée, le détecteur dans votre intégration continue ou la superposition dans le navigateur. Quand la page tourne déjà, c’est par cette revue que je commencerais.

better-interface et interface-review, de Jakub Krehel

better-interface fait passer un écran par chacun de ses skills better-* (accessibilité, mise en page, écriture, typographie, couleur, interface) et rend un seul verdict classé, d’au plus 15 problèmes, une ligne par cause. Il repère d’abord les variables de design et les composants du projet, et il écrit chaque correction dans les conventions du projet. interface-review pose une question plus étroite : est-ce que cette branche, cette demande de fusion ou ce changement non commité a empiré l’interface ? Il lit les deux côtés du diff et range chaque problème parmi les nouveaux, les régressions ou ceux qui existaient déjà, ce qui garde la revue avant la fusion centrée sur le changement lui-même. Pour ce travail-là, installez son dépôt.

web-design-guidelines, de Vercel

Un skill court, qui télécharge la dernière version des Web Interface Guidelines de Vercel à chaque exécution, lit les fichiers que vous lui indiquez et signale ce qui enfreint les règles dans un format file:line très concis. Les règles sont publiques, dans leur propre dépôt. Il coûte assez peu pour être lancé à chaque changement d’interface. Comme il vérifie des règles, il a peu à dire sur la hiérarchie ou sur le point de vue de la page, et il a besoin d’un accès réseau pour aller les chercher.

web-quality-skills, d’Addy Osmani

La collection d’Addy mise d’abord sur la mesure. Avant de fouiller le code, web-quality-audit prend des mesures de référence sur la page en ligne : Lighthouse pour l’accessibilité, le référencement et les bonnes pratiques, une trace de performance pour les Core Web Vitals, des données d’utilisateurs réels quand Chrome en a. Il sépare les problèmes mesurés des hypothèses tirées du code seulement, et il utilise le MCP Chrome DevTools quand il est disponible. Installez-le quand la question porte sur la vitesse, les scores d’accessibilité ou le référencement. Il laisse le design visuel à d’autres skills.

design-review, de Patrick Ellis

Celui-ci est un sous-agent Claude Code accompagné d’une commande /design-review, publiés comme modèles dans son dépôt de méthodes de travail. Il ouvre une préversion en ligne avec le MCP Playwright, suit le parcours principal de l’utilisateur, teste les états survol, actif et désactivé, puis vérifie la mise en page à 1440, 768 et 375 pixels avant de lire le code. Vous copiez ses fichiers dans le projet et vous gardez vos principes de design dans CLAUDE.md. Utilisez-le si vous avez un environnement de préversion et que vous voulez une revue qui navigue dans la page comme une personne le ferait.

Ce que design-grill ajoute

• Sept angles aux frontières écrites. Variables de design, finition, animation, mise en page, accessibilité, textes et heuristiques ont chacun leurs consignes. Les frontières sont explicites : tokens signale une valeur hors de l’échelle déclarée, layout signale des valeurs qui respectent toutes l’échelle et qui ne créent quand même aucun rythme.
• Le système de design du projet comme étalon. Un script repère, au moment de l’exécution, ce que la cible déclare (propriétés personnalisées CSS, configuration Tailwind, modules de thème). L’audit n’apporte aucune valeur de son cru : il fonctionne sur le dépôt de n’importe qui sans configuration, et une variable déclarée l’emporte toujours sur son avis.
• Une vérification là où elle a du sens. Chaque problème objectif est confié à son propre agent vérificateur. Les jugements de goût de craft, layout et heuristics ne lui sont jamais envoyés, parce qu’un vérificateur chargé de contredire les réfuterait tous. Un problème objectif finit confirmé, réfuté puis retiré, ou non vérifié et marqué comme tel, et le bas du rapport compte à part les réfutés et les non vérifiés.
• Un seul rapport classé, issu d’une fusion testée. merge-findings.mjs regroupe les problèmes qui partagent un file:line et une même affirmation ou un même sujet, garde la gravité la plus haute, nomme chaque angle qui l’a relevé, et classe le tout en bloquant, majeur, mineur et détail. Le rapport est enregistré dans docs/design-grills/ et nomme tout angle qui n’a pas pu s’exécuter.
• Une vérification de plateforme qui demande au besoin. Il déduit du dépôt s’il s’agit du Web ou du mobile. S’il n’arrive pas à trancher, il s’arrête et vous pose la question, pour qu’une app mobile ne reçoive jamais de conseils ARIA pensés pour le Web.
• Un coût annoncé et une voie moins chère. Une exécution Workflow sur une route peut demander des dizaines d’appels d’agents, et le skill dit à l’agent de vous l’annoncer et d’obtenir votre accord d’abord. Sans l’outil Workflow, l’agent applique les sept consignes une à la fois et contre-vérifie à la main un échantillon des problèmes objectifs : le même terrain, plus lentement et avec moins de vérification indépendante.
• Des limites assumées. Il ne fait que lire le code source et n’écrit qu’un seul fichier. C’est une lecture statique, qui ne voit ni la page affichée, ni le vrai contraste, ni l’ordre du focus, et le rapport le dit à la fin. Pour ça, lancez l’analyse d’URL d’Impeccable ou l’audit d’Addy.

Installer

Le skill seul, avec la CLI skills :

npx skills add molveau/skills -s design-grill

Le lot Design :

npx skills add molveau/skills -s anti-slop -s ui -s ux -s motion -s design-grill -s design-inspiration-index

Dans Claude Code, les onze skills dans un seul plugin :

/plugin marketplace add molveau/skills
/plugin install molveau-skills@molveau

Tous les skills et tous les lots sont sur la page des skills, et le code source est sur github.com/molveau/skills. À lire aussi : les skills anti-slop, les skills d’interface, les skills UX et accessibilité.

Liste de vérification

• La cible est un seul composant ou une seule route, pas toute l’app.
• Vous avez accepté le coût avant une exécution Workflow, ou choisi la voie manuelle.
• Le rapport énumère les variables de design trouvées, ou dit que le projet n’en déclare aucune.
• Les problèmes non vérifiés sont marqués et comptés à part des réfutés.
• Le contraste, l’ordre du focus et les Core Web Vitals viennent d’un outil qui affiche la page.
• Pour la revue d’une seule branche avant la fusion, on prend un skill limité au changement, comme interface-review.