Communitygithub.com

mandasTeam/frontend-autoral

Utilisez cette compétence pour créer, redessiner ou réviser des sites web, des landing pages, des écrans d'application, des tableaux de bord ou des composants d'interface (HTML/CSS, React, Next, Vue, Angular, Tailwind), ainsi que pour créer un logo, une icône d'application ou un favicon. Elle définit une direction artistique unique pour chaque projet basée sur le sujet, applique les lois UX, l'accessibilité et le modèle d'animation d'Emil Kowalski, mesure le résultat dans un navigateur réel par rapport à une liste de clichés d'interface générée par IA, et corrige en regardant des captures d'écran.

Qu'est-ce que frontend-autoral ?

La compétence `mandasTeam/frontend-autoral` est conçue pour les développeurs et les designers qui souhaitent dépasser le 'look IA' générique pour créer des interfaces utilisateur originales, fonctionnelles et accessibles. Elle combine quatre sources d'expertise : la direction artistique basée sur le sujet (taste-skill), les animations d'interface avec fonction précise (Emil Kowalski), les lois UX vérifiables, et la création d'identité visuelle (logo, icône). Le processus est rigoureux : après avoir analysé le sujet et le public, elle rédige une direction artistique avant d'écrire le moindre CSS, puis construit le contenu et le code, avant de mesurer les résultats dans un navigateur réel (via un script d'inspection) et de les confronter à une liste de clichés d'interface. Trois cycles de correction maximum sont autorisés. La compétence fonctionne sur tout projet web (sites, apps, composants) et est documentée pour être utilisée avec Claude Code, Cursor ou tout agent compatible avec le format SKILL.md. Elle est particulièrement utile pour les projets où l'esthétique par défaut des modèles de langage échoue (sites sans direction artistique, interfaces ternes, animations inutiles). Les scripts nécessitent Node 22+ et un navigateur Chromium, Edge ou Chrome.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mandasTeam/frontend-autoral/tree/main/skills/frontend-autoral

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Frontend autoral

Répondez en français, directement. Livrez une interface fonctionnelle et vérifiée à l'écran, pas une ébauche.

Le problème que cette compétence résout : les sites générés par IA se ressemblent parce qu'ils naissent d'un plan vague, sans contenu réel, et personne ne regarde le résultat. Ici, chaque projet reçoit une direction artistique écrite avant le code, dérivée du sujet ; il est mesuré dans un navigateur réel et n'est livré qu'après avoir été vu rendu et comparé à la liste des clichés.

Quatre sources, déjà réconciliées, se rejoignent ici :

  • taste-skill (leonxlnx) : inventaire du sujet, argument, tirage au sort de compositions étudiées dans 247 sites primés, phrase de l'idée, chose vivante, images de collections ouvertes, lint et inspecteur dans un navigateur réel, critique par passes avec seuils de note. Outils dans vendor/taste-skill/.
  • Emil Kowalski (emilkowalski/skills) : décision d'animation, courbes, durées, physique, sensation d'application mobile, données du pire cas, révision dans un tableau Avant/Après.
  • Lois UX (lawsofux.com) : les 30 lois posées comme des questions à vérifier à l'écran.
  • logo-design (kaankiziltug) : processus de logo, d'icône d'application et de favicon, avec audit SVG et exportation de l'ensemble web. Outils dans vendor/logo-design/.

Quand les sources sont en désaccord : la demande actuelle > "Goût d'Igor" et references/cliches.md > ce fichier > references/movimento.md (commande sur le mouvement) > les références en anglais de vendor/. En particulier : ici, le mouvement n'a qu'une fonction, sans quota d'éléments animés et sans entrée dans chaque section ; les scènes de défilement du tirage n'apparaissent que si l'utilisateur le demande.

<skill> dans les commandes est le dossier de cette compétence. Les scripts nécessitent Node 22+ (lint : 18+) et un Chrome, Edge ou Chromium (celui de Playwright convient ; scripts/achar-chrome.mjs le trouve tout seul). Ceux pour l'icône nécessitent Python 3 (sous Windows, python).

Quand l'utiliser

  • Créer un site, une landing page, un portfolio, une page institutionnelle, un écran d'application, un tableau de bord, un formulaire.
  • Redessiner ou "rendre plus beau" une interface existante.
  • Réviser l'UI/UX d'un écran : hiérarchie, accessibilité, états, copy, responsivité, animation.
  • Créer un composant avec une identité (pas seulement fonctionnel) pour un produit.
  • Créer un logo, un symbole, une icône d'application ou un favicon pour un projet, ou générer les variantes d'un logo existant.

Ne pas utiliser pour : README et art de profil GitHub (compétence readme-designer), graphiques et visualisation de données (compétence dataviz), présentations et documents.

Choisir le mode

  • Créer une page (site, landing, portfolio ; nouveau projet ou refonte complète) : flux complet.
  • Écran d'application (tableau de bord, admin, paramètres, boîte de réception, liste avec filtres, éditeur) : lisez vendor/taste-skill/references/app-screens.md en entier avant de commencer. Il a sa propre séquence, son propre tirage (draw.mjs --app --kind <type>) et ses propres règles (bordures discrètes, petits libellés et panneaux répétés sont normaux ici ; gradient, brillance, icône dans un carré coloré, graphique arc-en-ciel et numéro de vanity inventé non). Utilisez le flux ci-dessous avec --app au portail ; la chose vivante et le socle d'images ne s'appliquent pas. Une page produit qui montre l'application est une page ; les fragments de l'application à l'intérieur suivent les règles de l'application et portent data-ui.
  • Évoluer (système visuel existant, DESIGN.md, BRAND.md, tokens, thème Tailwind, bibliothèque de composants) : la direction existante commande. Lisez d'abord, réutilisez les tokens et les composants, et ne proposez un changement d'identité que si l'utilisateur le demande. Sautez le tirage (ou utilisez --keep palette,type pour ne prendre que la composition), mais passez le portail et la liste des clichés.
  • Réviser (audit, "qu'est-ce qui est mauvais ici ?", "révise les animations") : seulement les étapes 1 et 5, dans l'état actuel. Résultats dans un tableau Où | Avant | Après | Pourquoi regroupé par gravité, sans préambule (references/revisao.md §11).
  • Ajustement ponctuel ("plus audacieux", "plus calme", "change la police", "anime ça") : ne modifiez que ce qui a été demandé, dans la direction existante. Voir "Ajustements" dans references/oficio.md et, pour l'animation, references/movimento.md.
  • Icône ou logo (logo, marque, icône d'application, favicon) : references/icones.md. Dans tout projet de site ou d'application, le mode léger de ce fichier s'exécute à l'étape 4 pour que le projet soit livré avec sa propre icône.

Flux

Chaque étape ne se termine que lorsque le critère de prêt est rempli.

  1. Comprendre le sujet. Lisez la demande et le code existant. Répondez-vous, en une ligne chacun : quel est le produit, à qui est-il destiné, quelle est la tâche principale, s'agit-il d'une page ou d'un écran d'application, quel contenu réel existe (textes, images, données, logo, marque) et quelle image existe vraiment. Complétez l'inventaire de 8 à 12 choses que seul ce client possède (references/direcao.md §1). Si l'essentiel manque (quel est le produit ou à qui il est destiné), faites une série de 4 questions maximum en lot. Si seul le goût manque, décidez et dites ce que vous avez décidé.

    • Prêt lorsque le produit, le public, la tâche, le type, l'inventaire et l'inventaire d'images sont clairs, et que les lacunes ont une réponse ou une décision enregistrée.
  2. Écrire la direction artistique avant tout CSS, dans DESIGN.md à la racine du projet (modèle dans assets/DESIGN.template.md ; dans un seul fichier, en haut de la réponse). Méthode dans references/direcao.md :

    • l'argument : la page comme affirmations avec preuve, une par section ; une section sans affirmation disparaît ;
    • le tirage de composition (vendor/taste-skill/scripts/draw.mjs ... --options 3), recommandé pour les pages : choisissez l'option qui porte quelque chose de l'inventaire, pas la plus familière, et filtrez la palette et le type par le sujet et par les clichés ;
    • concept en une phrase de scène, listes "ressemble / ne ressemble pas" ;
    • la phrase de l'idée ("Sur cette page, [quelque chose de l'inventaire] devient [la ressource]"), le test du concurrent et la chose vivante (une interaction faite de l'idée, avec du contenu réel) ;
    • signature ; palette de 4 à 6 couleurs nommées avec rôle et contraste ; 1 ou 2 familles avec échelle allant jusqu'à 5 tailles ; grille avec marges égales, rythme et règle de forme ; règle de mouvement ; source des images ; d'où vient l'icône ;
    • wireframe en ASCII de chaque section, voisines avec des formes différentes.

    Exécutez ensuite le test de remplacement : "si je changeais le nom du produit, cette direction conviendrait-elle à un concurrent quelconque ?" Si oui, révisez et dites ce qui a changé. Vérifiez par rapport à references/cliches.md, y compris le §11 (enlever un cliché ne doit pas laisser uniquement du vide).

    • Prêt lorsque chaque choix a une raison liée au produit, au public ou au contenu, que la phrase de l'idée réussit le test du concurrent et qu'aucun élément ne tombe dans un cliché sans justification.
  3. Écrire le contenu comme un script de texte pur avant le balisage, avec references/copy.md : titres qui tiennent en deux lignes sur toute la largeur (faites le calcul), la phrase de soutien juste en dessous, une action principale avec verbe et objet, chaque section avec le contenu complet. Là où manque une preuve (chiffre, témoignage, client, évaluation), utilisez un marqueur visible comme [témoignage réel ici] plutôt que d'inventer ; là où manque seulement un détail de contenu (nom de plat, de chambre), utilisez un échantillon plausible et listez-le pour confirmation.

    • Prêt lorsqu'aucun texte ne pourrait figurer sur le site d'une autre entreprise, qu'aucune preuve n'est inventée et que les échantillons sont listés.
  4. Construire, à l'arrêt. Avec le mouvement désactivé dans la tête : une page qui a besoin d'animation pour sembler prête n'est pas prête. Ordre : tokens (couleur, type, espace, forme, courbes), le hero exactement comme dessiné sur le bureau et le mobile, chaque section selon son wireframe portant l'idée jusqu'au prix, FAQ et pied de page, images (references/imagens.md : propres, générées, collections ouvertes avec assets.mjs, dessinées à partir du sujet), la chose vivante, le cadre (marges égales, titre dans chaque section, aucune partie vide), états et sémantique, favicon et icônes (references/icones.md, mode léger). Suivez references/oficio.md, references/ux.md et references/leis-ux.md. vendor/taste-skill/assets/base.css est une base neutre optionnelle.

    • Utilisez la stack que le projet a déjà. Pas de dépendance visuelle nouvelle sans raison fonctionnelle.
    • Prêt lorsque la page s'exécute sans erreur de console, sans défilement horizontal sur mobile, avec tous les états pertinents (hover, focus-visible, active, disabled, loading, erreur, vide), les données du pire cas testées (references/ux.md §9) et sa propre icône en place.
  5. Mesurer, regarder, corriger. Exécutez le portail : node <skill>/scripts/inspecionar.mjs <url-ou-index.html> --src <dossier-du-code> (avec --app pour un écran d'application). Il exécute le lint et l'inspecteur à 1440, 768 et 390 px et enregistre les captures d'écran dans .taste-skill/inspect/. Corrigez chaque FAIL. Ensuite, ouvrez toutes les captures d'écran et critiquez avec references/revisao.md : test IA, 15 passes, rubrique avec seuils, critique écrite au format de la série. Corrigez les 3 problèmes les plus graves, mesurez et regardez à nouveau ; maximum 3 séries.

    • Prêt lorsqu'il y a 0 FAIL, une note moyenne ≥ 8, aucun critère < 7 et la liste des problèmes vide. Si vous ne pouvez pas y arriver, dites ce qui reste en suspens et la note réelle.
  6. Déplacer, seulement avec fonction. Maintenant le mouvement, décidé par references/movimento.md : fréquence (une action clavier et quelque chose vu toute la journée ne s'anime pas), but, courbe (ease-out fort, jamais ease-in), durée (< 300 ms dans l'interface), pression (scale(0.97)), origine au déclencheur, hover seulement avec souris, prefers-reduced-motion. Au maximum un moment orchestré par page, en général la chose vivante ou la signature. Exécutez à nouveau le portail et vérifiez sur les captures d'écran que rien n'a disparu.

    • Prêt lorsque chaque animation répond "pourquoi ?" et que le portail continue d'afficher 0 FAIL.
  7. Vérifier et rapporter. Checklist finale et rapport de references/revisao.md §9 et §10.

Sans moyen de rendu (aucun navigateur et aucune façon d'en installer un) ? Exécutez seulement le lint, dites-le dans le rapport et faites la révision en lisant le code par rapport à la checklist. Ne dites pas que vous avez vérifié à l'écran.

Design en une seule page

Les détails sont dans references/oficio.md, references/cliches.md et references/leis-ux.md.

  • Toute décision visuelle a une raison liée au produit, à la marque, au contenu ou à l'usage. Avant d'ajouter un élément, demandez-vous s'il améliore la compréhension, la fonction, l'esthétique ou l'expérience. Si ce n'est pas le cas, il ne rentre pas.
  • L'identité vient du sujet, jamais de la tendance. Futuriste, tech ou minimaliste ne sont pas la norme ; ils n'entrent que si le sujet le demande. Le minimalisme n'est pas une absence de personnalité.
  • Visuel original, mécanique conventionnelle (Loi de Jakob). L'audace réside dans la typographie, la couleur, l'image et la composition ; le menu, le lien, le bouton et le formulaire fonctionnent comme sur n'importe quel site.
  • Audace à un seul endroit, dans l'idée-signature. Le reste reste discipliné. Avant de livrer, enlevez un accessoire. Mais enlever un ornement n'est pas laisser vide : l'espace va à l'échelle, au contenu complet, à l'image du sujet ou au champ de couleur.
  • La composition suit le contenu. Chaque section choisit sa forme par ce qu'elle montre : liste, séquence, comparaison, grande image, citation, tableau. Les voisines ne répètent pas la forme. Tout n'est pas carte, tout n'est pas centré, tout n'est pas grille de 3 colonnes.
  • Hiérarchie avant symétrie. Un élément principal par écran ; 2 ou 3 tailles font le travail, jusqu'à 5 au total ; titres en deux lignes maximum. Asymétrie dans la grille, marges extérieures toujours égales.
  • Couleur avec rôle. Un fond, une encre, 1 ou 2 neutres teintés, un accent dans 1 à 3 endroits (Von Restorff). Surfaces par palier de teinte, sans gradient, brillance, flou, verre ou ombre au repos.
  • Typographie comme voix. 1 ou 2 familles choisies par le caractère du produit, corps lisible (≥ 16 px, 45 à 75 caractères par ligne) à l'encre pleine.
  • Image qui montre. Réelle du projet, générée, de collection ouverte avec crédit, ou dessinée à partir du sujet lui-même ; une dominante gagne six petites ; jamais de boîte grise ni de banque générique.
  • Mouvement seulement avec fonction, rapide, interrompable, avec ease-out et origine correcte. Toujours prefers-reduced-motion.
  • Accessibilité non négociable : contraste AA, focus visible, navigation au clavier, sémantique correcte, alt sur une image avec contenu, cibles ≥ 44 px, zoom autorisé.

Goût d'Igor

Point de départ, pas une recette. La demande actuelle gagne toujours.

  • Le thème change à chaque projet. Ne réutilisez jamais la palette, la police, le motif ou le contenu d'un travail précédent sans qu'il le demande. (Le tirage de taste-skill aide : il se souvient des précédents.)
  • Aime les thèmes assumés et bien exécutés, présents dans l'ensemble, pas d'ornement timide.
  • Cohérence avant tout : une section "brute" au milieu de sections stylisées dérange. Si une détonne, refaîtes-la dans le même modèle.
  • Mouvement subtil. Un objet traversant l'écran est interdit.
  • Contenu naturel, sans phrase d'effet forcée, sans disclaimer ou pied de page que personne n'a demandé.
  • "Améliorer" une section, c'est refaire le visuel en conservant le contenu, pas supprimer.
  • Quand il oppose son veto à un élément, retirez seulement cet élément. Ne réinterprétez pas le reste.

Pièges

  • Le premier réflexe est le cliché. Hero centré avec titre, sous-titre, deux boutons et gradient ; trois cartes avec icône dans un carré coloré ; section de chiffres ; témoignages. Si la première idée est venue trop vite, c'est probablement le modèle. Revenez à l'inventaire.
  • Éviter un cliché en tombant dans un autre. Fuir le violet pour aller vers un fond crème + serif + terre cuite, ou vers du noir + vert acide, c'est échanger un modèle d'IA pour un autre. Voir les "cinq visuels standard" dans references/cliches.md.
  • Page épurée et vide. Sans ornements et sans rien à leur place, elle perd face à une page pleine de clichés. Contenu complet, grand type, images réelles.
  • Idée de catégorie. "Du pain" convient à toute boulangerie. Si la phrase de l'idée fonctionne avec le concurrent, revenez à l'inventaire.
  • Contenu inventé pour remplir. Nombre sans source, logo de client fictif, témoignage, avatar aléatoire, maquette de tableau de bord générique. Utilisez un marqueur ou supprimez la section.
  • Titre de trois lignes.

Skills associés