En quoi cette liste diffère d’un classement frontend
Cette sélection suit une décision de conception depuis un brief incertain jusqu’à une transmission vérifiable. Ce n’est pas un nouveau classement de cinq prompts de réalisation. Elle privilégie livrables distincts, preuves sources visibles, permissions proportionnées et point clair où un humain peut accepter ou refuser le résultat.
L’ordre est éditorial et fondé sur les sources, pas sur un test d’exécution universel. Agent, modèle, contexte du dépôt, maturité du système de design et révision source peuvent modifier les résultats.
1. grill-me : clarifier la décision avant de dessiner
grill-me conduit un entretien ciblé qui insiste sur hypothèses, compromis et contraintes manquantes. Il occupe le premier rôle parce qu’un brief fragile entraîne ensuite des reprises visuelles coûteuses.
Son résultat est un raisonnement plus précis, pas une recherche utilisateur. L’entretien peut encore renforcer une prémisse erronée si l’équipe fournit des preuves incomplètes.
2. frontend-design : établir une direction visuelle
frontend-design apporte une couche de direction créative. Il peut orienter typographie, composition, couleur, mouvement et réalisation vers un concept délibéré plutôt qu’un collage générique de composants.
Fournissez-lui la décision produit clarifiée, les contraintes de marque et l’interface cible, pas une autorisation implicite de tout redessiner.
3. anti-ui-slop : relier l’interface au produit
anti-ui-slop transforme contexte du dépôt et références d’interface en un contrat de design propre au produit. Il sert quand le problème principal n’est pas la finition, mais des noms, actions, états et motifs génériques qui n’appartiennent pas au produit.
La source indexée est native à GitHub Copilot et peut accéder au réseau pour les références. Considérez les autres associations d’agents comme portables tant que leur découverte n’a pas été testée.
4. web-design-reviewer : examiner la réalisation responsive
web-design-reviewer contrôle une interface active à plusieurs largeurs, remonte des défauts visibles à la source et vérifie les corrections limitées. C’est le rôle le plus direct pour coupures, hiérarchie, espacements et ruptures de mise en page.
Les captures ne prouvent ni compréhension, ni prise en charge des technologies d’assistance, ni réussite réelle des utilisateurs. Reliez la revue à des largeurs et critères d’acceptation explicites.
5. pr-screenshots : conserver les preuves de transmission
pr-screenshots produit des preuves visuelles avant/après comparables pour une pull request. Il ferme la boucle en facilitant la comparaison des états modifiés pour designer, ingénieur ou relecteur.
Une preuve n’est pas une approbation. Capturez mêmes largeur, données et état d’interaction, sans informations sensibles dans les images téléversées.
Exemple : examiner une page de tarifs SaaS fictive
Imaginons qu’une équipe SaaS suppose que les visiteurs comparent difficilement trois offres. Ce scénario est illustratif : ce n’est ni un constat de recherche utilisateur, ni une mesure d’utilisabilité, ni la preuve que ces skills augmentent la conversion.
grill-me transforme cette inquiétude en brief limité : public prévu, choix à effectuer, détails vérifiés des offres, hypothèses encore sans preuve et exclusions. Dans cet exemple, aucun prix, terme de facturation ou critère d’éligibilité ne peut changer.
frontend-design propose une direction et une hiérarchie de comparaison plus claire ; anti-ui-slop vérifie noms d’offres, disponibilité des fonctions et vocabulaire du produit réel. Aucun ne peut inventer des bénéfices ou résoudre une question tarifaire non vérifiée en devinant.
web-design-reviewer examine le contenu inchangé à 1440px et 390px pour repérer comparaisons coupées, hiérarchie confuse, défauts de clavier/focus et états responsive absents. pr-screenshots capture avant/après à largeur et données identiques pour qu’un relecteur humain nommé examine le changement exact.
L’acceptation porte sur un livrable de conception vérifiable : faits vérifiés, prix et conditions intacts, version étroite lisible et images comparables. Elle ne prouve ni meilleure compréhension ni conversion accrue ; cela exigerait des preuves utilisateur distinctes.
- Chaque affirmation sur une offre correspond à une source produit approuvée.
- Aucun prix, terme de facturation ou critère d’éligibilité n’a changé.
- À 390px, les différences entre offres restent lisibles sans coupure.
- Les preuves avant/après utilisent mêmes contenu, largeur et état.
- Un relecteur nommé accepte ou refuse la conception avant publication.
Installer le rôle manquant, pas toute la liste
Si le concept est flou, commencez par grill-me et arrêtez-vous là. Pour un brief clair avec résultat générique, ajoutez frontend-design. Pour un produit existant dont l’interface fonctionne, la paire revue/preuves peut être plus utile qu’un autre skill générateur.
Une méthode à cinq rôles est une carte, pas une obligation d’installer cinq paquets. Chaque ajout doit avoir son livrable distinct, son périmètre de permissions, son relecteur et sa condition de retrait.
- Le brief consigne décision et alternatives écartées.
- La direction utilise contenu et contraintes du produit.
- Les largeurs cibles ne présentent ni coupure ni état manquant.
- La transmission compare des états avant/après équivalents.
- Un relecteur nommé peut refuser le résultat.