designwithai-mcp 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +153 -0
- package/dist/connectors.js +76 -0
- package/dist/decisions.js +67 -0
- package/dist/embeddings.js +98 -0
- package/dist/evals.js +172 -0
- package/dist/finding-identity.js +229 -0
- package/dist/handbook.js +98 -0
- package/dist/paths.js +62 -0
- package/dist/profile.js +79 -0
- package/dist/reviews.js +99 -0
- package/dist/server.js +1136 -0
- package/dist/skills.js +57 -0
- package/dist/state.js +48 -0
- package/handbook-embeddings.json +1 -0
- package/package.json +46 -0
- package/skills/EVALS.md +122 -0
- package/skills/README.md +59 -0
- package/skills/_shared/delivery-modes.md +12 -0
- package/skills/_shared/execution-contract.md +43 -0
- package/skills/_shared/issue-schema.md +25 -0
- package/skills/_shared/severity-model.md +16 -0
- package/skills/analyze-figma/evals/cases.json +140 -0
- package/skills/analyze-url/evals/cases.json +136 -0
- package/skills/better-accessibility/SKILL.md +141 -0
- package/skills/better-accessibility/evals/cases.json +83 -0
- package/skills/better-components/SKILL.md +125 -0
- package/skills/better-components/evals/cases.json +77 -0
- package/skills/better-consistency/SKILL.md +125 -0
- package/skills/better-consistency/evals/cases.json +77 -0
- package/skills/better-forms/SKILL.md +135 -0
- package/skills/better-forms/evals/cases.json +78 -0
- package/skills/better-interface/SKILL.md +143 -0
- package/skills/better-interface/evals/cases.json +80 -0
- package/skills/better-layout/SKILL.md +132 -0
- package/skills/better-layout/evals/cases.json +81 -0
- package/skills/better-navigation/SKILL.md +170 -0
- package/skills/better-navigation/evals/cases.json +131 -0
- package/skills/better-performance/SKILL.md +195 -0
- package/skills/better-performance/evals/cases.json +114 -0
- package/skills/better-responsive/SKILL.md +123 -0
- package/skills/better-responsive/evals/cases.json +77 -0
- package/skills/better-states/SKILL.md +129 -0
- package/skills/better-states/evals/cases.json +78 -0
- package/skills/better-writing/SKILL.md +138 -0
- package/skills/better-writing/evals/cases.json +77 -0
- package/skills/review-ai-product/SKILL.md +231 -0
- package/skills/review-ai-product/evals/cases.json +120 -0
- package/skills/review-data-security/SKILL.md +210 -0
- package/skills/review-data-security/evals/cases.json +138 -0
- package/skills/review-figma-hygiene/SKILL.md +186 -0
- package/skills/review-figma-hygiene/evals/cases.json +158 -0
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "url-conformant-releves",
|
|
4
|
+
"skill": "analyze-url",
|
|
5
|
+
"kind": "conformant",
|
|
6
|
+
"delivery_mode": "classique",
|
|
7
|
+
"artifact": "URL analysée : https://releves-compteurs.fr/releves/\nLangue déclarée : fr\nTitre : Relevés — suivre les relevés de vos compteurs\nMeta description : Enregistrez vos relevés de compteur, suivez la consommation mois par mois.\nMeta viewport : width=device-width, initial-scale=1\n\nTITRES (4)\n - h1 : Mes relevés\n - h2 : Ajouter un relevé\n - h2 : Relevés enregistrés\n - h2 : Questions fréquentes\n\nLIENS DE NAVIGATION ET D'ACTION (6)\n - Relevés → /\n - Mes relevés → /releves/\n - Mes compteurs → /compteurs/\n - Aide → /aide/\n - Aide → /aide/\n - Confidentialité → /confidentialite/\n\nBOUTONS (1)\n - Ajouter le relevé\n\nFORMULAIRES (1)\n - formulaire → /releves/ (POST)\n\nCHAMPS DE SAISIE (4)\n - champ date (date) requis · label visible « Date du relevé » · aide liée (aide-date)\n - champ index (number) requis · label visible « Index affiché sur le compteur » · aide liée (aide-index)\n - champ note (textarea) · label visible « Note (facultatif) »\n - champ compteur (select ) requis · label visible « Compteur »\n\nIMAGES ET TEXTES DE REMPLACEMENT (1)\n - courbe-consommation.png : alt « Courbe de consommation : hausse régulière de janvier à mars 2026. »\n\nZONES D'ANNONCE DYNAMIQUE (1)\n - aria-live=polite role=status\n\nBLOCS REPLIABLES NATIFS <details> (2) — l'état ouvert/fermé est porté par le navigateur\n - Que se passe-t-il si je saisis un index plus bas que le précédent ? [replié]\n - Puis-je supprimer un relevé ? [replié]\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (0)\n (aucun)\n\nCONTENU DE SECOURS SANS JAVASCRIPT (1)\n - Le formulaire de relevé fonctionne sans JavaScript : remplissez les champs et validez.\n\nTEXTE VISIBLE (139 mots, extrait)\nLe formulaire de relevé fonctionne sans JavaScript : remplissez les champs et validez. Relevés Mes relevés Mes compteurs Aide Mes relevés Trois relevés enregistrés. Dernier relevé le 12/03/2026. Ajouter un relevé Compteur Électricité — cuisine Eau — salle de bain Date du relevé Format jour/mois/année, par exemple 12/03/2026. Index affiché sur le compteur Nombre entier, sans unité. Exemple : 45210. Note (facultatif) Ajouter le relevé Relevés enregistrés Date Compteur Index 12/03/2026 Électricité — cuisine 45 210 08/02/2026 Électricité — cuisine 44 980 05/01/2026 Eau — salle de bain 1 204 Questions fréquentes Que se passe-t-il si je saisis un index plus bas que le précédent ? Le relevé est enregistré et signalé comme à vérifier. Vous pouvez le corriger ensuite. Puis-je supprimer un relevé ? Oui, depuis la ligne du relevé, jusqu'à trente jours après son ajout. Aide Confidentialité",
|
|
8
|
+
"golden": {
|
|
9
|
+
"expected_findings": [],
|
|
10
|
+
"forbidden_findings": [
|
|
11
|
+
"aucun état de chargement annoncé",
|
|
12
|
+
"aucun état vide sur la liste des relevés",
|
|
13
|
+
"aucun message d'erreur prévu",
|
|
14
|
+
"revoir les couleurs et les espacements"
|
|
15
|
+
],
|
|
16
|
+
"expected_verdict": "PASS",
|
|
17
|
+
"should_refuse": false,
|
|
18
|
+
"note": "Page saine sur les deux grilles : terminologie unique (relevé/compteur), hiérarchie de titres complète, tous les champs étiquetés et typés, aide liée là où le format est contraint, alt porteur de sens, zone d'annonce présente, contenu de secours sans JavaScript présent, dates au même format. Le seul reproche recevable est de faible sévérité (l'aide décrit un format jour/mois/année alors que le champ est de type date) : une note ne disqualifie pas un cas conformant."
|
|
19
|
+
}
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"id": "url-conformant-sans-javascript",
|
|
23
|
+
"skill": "analyze-url",
|
|
24
|
+
"kind": "conformant",
|
|
25
|
+
"delivery_mode": "classique",
|
|
26
|
+
"artifact": "URL analysée : https://mediatheque-vaugrenier.fr/horaires/\nLangue déclarée : fr\nTitre : Horaires et accès — Médiathèque de Vaugrenier\nMeta description : Horaires d'ouverture, adresse et conditions d'accès de la médiathèque de Vaugrenier.\nMeta viewport : width=device-width, initial-scale=1\n\nTITRES (4)\n - h1 : Horaires et accès\n - h2 : Horaires d'ouverture\n - h2 : Adresse et transports\n - h2 : Emprunter des documents\n\nLIENS DE NAVIGATION ET D'ACTION (6)\n - Médiathèque de Vaugrenier → /\n - Horaires et accès → /horaires/\n - Catalogue → /catalogue/\n - Inscription → /inscription/\n - Mentions légales → /mentions-legales/\n - Accessibilité → /accessibilite/\n\nBOUTONS (0)\n (aucun)\n\nFORMULAIRES (0)\n (aucun)\n\nCHAMPS DE SAISIE (0)\n (aucun)\n\nIMAGES ET TEXTES DE REMPLACEMENT (1)\n - plan-acces-mediatheque.png : alt « Plan d'accès : la médiathèque se situe entre la mairie et le parc, côt »\n\nZONES D'ANNONCE DYNAMIQUE (0)\n (aucun)\n\nBLOCS REPLIABLES NATIFS <details> (0) — l'état ouvert/fermé est porté par le navigateur\n (aucun)\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (0)\n (aucun)\n\nCONTENU DE SECOURS SANS JAVASCRIPT (0)\n (aucun)\n\nTEXTE VISIBLE (209 mots, extrait)\nMédiathèque de Vaugrenier Horaires et accès Catalogue Inscription Horaires et accès La médiathèque accueille le public six jours sur sept. L'entrée est libre et gratuite, l'inscription n'est demandée que pour emprunter des documents. Horaires d'ouverture Jour Matin Après-midi Mardi 10 h – 12 h 14 h – 18 h Mercredi 10 h – 12 h 14 h – 19 h Jeudi Fermé 14 h – 18 h Vendredi 10 h – 12 h 14 h – 18 h Samedi 10 h – 13 h 14 h – 17 h La médiathèque est fermée les jours fériés ainsi que du 01/08/2026 au 16/08/2026. Adresse et transports 12 rue des Tilleuls, 06270 Vaugrenier. Bus 21 et 44, arrêt « Tilleuls ». Un parking gratuit de trente places se trouve derrière le bâtiment. L'entrée principale est de plain-pied et les trois niveaux sont desservis par un ascenseur. Emprunter des documents L'inscription est annuelle et gratuite pour les habitants de la commune. Elle se fait sur place, avec une pièce d'identité et un justificatif de domicile de moins de trois mois. Chaque carte permet d'emprunter dix documents pour trois semaines, renouvelables une fois. Pour toute question, écrivez à contact@mediatheque-vaugrenier.fr ou appelez le 04 93 00 00 00 aux heures d'ouverture. Mentions légales Accessibilité",
|
|
27
|
+
"golden": {
|
|
28
|
+
"expected_findings": [],
|
|
29
|
+
"forbidden_findings": [
|
|
30
|
+
"aucun contenu de secours sans JavaScript",
|
|
31
|
+
"aucune zone d'annonce pour les erreurs",
|
|
32
|
+
"aucun état de chargement",
|
|
33
|
+
"aucun formulaire de contact",
|
|
34
|
+
"aucun élément interactif"
|
|
35
|
+
],
|
|
36
|
+
"expected_verdict": "PASS",
|
|
37
|
+
"should_refuse": false,
|
|
38
|
+
"note": "LE PIÈGE DU RAISONNEMENT PAR ABSENCE, à l'état pur. Cette page est servie entière par le serveur : elle n'exécute aucun script, ne charge rien, n'affiche aucune erreur. Elle n'a donc besoin ni de contenu de secours, ni de zone d'annonce, ni de message d'attente — et la grille « soigne » invite pourtant à reprocher leur absence. Reprocher ici ce qui n'a pas lieu d'être est la faute que ce cas mesure."
|
|
39
|
+
}
|
|
40
|
+
},
|
|
41
|
+
{
|
|
42
|
+
"id": "url-obvious-taskflow",
|
|
43
|
+
"skill": "analyze-url",
|
|
44
|
+
"kind": "obvious-defect",
|
|
45
|
+
"delivery_mode": "ai-builder",
|
|
46
|
+
"artifact": "URL analysée : https://taskflow-demo.app/projects\nLangue déclarée : (non déclarée)\nTitre : React App\nMeta description : (aucune)\nMeta viewport : (aucune)\n\nTITRES (3)\n - h1 : Mes projets\n - h3 : Créer un projet\n - h3 : Vos espaces\n\nLIENS DE NAVIGATION ET D'ACTION (6)\n - TaskFlow → /\n - Mes projets → /projects\n - Mes espaces → /workspaces\n - Nouveau workspace → /w/new\n - (lien sans texte) → /help\n - Cliquez ici → /upgrade\n\nBOUTONS (6)\n - Soumettre\n - Ajouter\n - Créer\n - Nouveau\n - OK\n - Enregistrer [désactivé]\n\nFORMULAIRES (1)\n - formulaire → /api/create (POST)\n\nCHAMPS DE SAISIE (4)\n - champ title (text) requis · SANS LABEL · placeholder « Nom du projet »\n - champ email (text) · SANS LABEL · placeholder « Email du responsable »\n - champ deadline (text) · SANS LABEL · placeholder « Deadline »\n - champ team (select ) · SANS LABEL\n\nIMAGES ET TEXTES DE REMPLACEMENT (2)\n - illustration-tableau-de-bord.png : PAS D'ATTRIBUT ALT\n - avatar-responsable.png : PAS D'ATTRIBUT ALT\n\nZONES D'ANNONCE DYNAMIQUE (0)\n (aucun)\n\nBLOCS REPLIABLES NATIFS <details> (0) — l'état ouvert/fermé est porté par le navigateur\n (aucun)\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (0)\n (aucun)\n\nCONTENU DE SECOURS SANS JAVASCRIPT (0)\n (aucun)\n\nTEXTE VISIBLE (244 mots, extrait)\nTaskFlow Mes projets Mes espaces Nouveau workspace Mes projets Bienvenue sur TaskFlow. Vous retrouvez ici tous les projets de votre organisation, ainsi que les espaces partagés avec les autres équipes. Chaque projet regroupe des tâches, des documents et un fil de discussion. Vous pouvez créer un nouveau projet à tout moment depuis le formulaire ci-dessous, l'assigner à une équipe, puis inviter les personnes concernées. Les projets archivés restent consultables pendant douze mois avant d'être définitivement supprimés de votre workspace. Créer un projet Équipe A Équipe B Soumettre Erreur Vos espaces Un espace rassemble plusieurs projets et leurs membres. Vous appartenez à trois espaces. Le workspace « Produit » contient les projets de conception et de développement. L'espace « Marketing » regroupe les campagnes en cours et les demandes entrantes. Le troisième espace est personnel : vous seul y avez accès, et il ne compte pas dans le quota de votre organisation. Créé le 12/03/2026 · Modifié le 2026-02-08 · Ouvert le 5 janvier 2026 Projet Tâches Action Refonte site 3 tâches en cours, 12 terminées Ajouter Application mobile 7 tâches en cours, 4 terminées Créer Migration données 2 tâches en cours, 0 terminée Nouveau Pour ajouter une tâche à un projet, ouvrez le projet puis utilisez le bouton correspondant dans la colonne de droite. Les tâches peuvent être assignées, commentées et déplacées entre les colonnes du tableau. Une tâche terminée reste visible sept jours avant de rejoindre l'historique du projet. Cliquez ici OK Enregistrer",
|
|
47
|
+
"golden": {
|
|
48
|
+
"expected_findings": [
|
|
49
|
+
"le même objet nommé projet, espace et workspace",
|
|
50
|
+
"trois libellés pour la même action : Ajouter, Créer, Nouveau",
|
|
51
|
+
"trois formats de date différents sur la même ligne",
|
|
52
|
+
"hiérarchie de titres : le niveau h2 sauté entre h1 et h3",
|
|
53
|
+
"quatre champs sans label, portés par le seul placeholder",
|
|
54
|
+
"bouton d'envoi au libellé vague « Soumettre »",
|
|
55
|
+
"message d'erreur réduit au mot « Erreur », sans cause ni suite",
|
|
56
|
+
"deux images sans attribut alt",
|
|
57
|
+
"langue de la page non déclarée",
|
|
58
|
+
"lien sans texte vers l'aide"
|
|
59
|
+
],
|
|
60
|
+
"forbidden_findings": [
|
|
61
|
+
"revoir les couleurs et les espacements",
|
|
62
|
+
"alléger les scripts chargés",
|
|
63
|
+
"refondre entièrement l'interface",
|
|
64
|
+
"aucun état de chargement"
|
|
65
|
+
],
|
|
66
|
+
"expected_verdict": "FAIL",
|
|
67
|
+
"should_refuse": false,
|
|
68
|
+
"note": "Application générée : les défauts sont nets et tous observables dans l'extrait. Deux d'entre eux sont critiques — des champs dont le seul repère est un placeholder, et un message d'erreur qui ne dit ni la cause ni la suite — d'où le FAIL déduit par le modèle de sévérité. Le champ email typé en texte et le bouton désactivé sans cause sont recevables en plus ; ils ne sont pas exigés."
|
|
69
|
+
}
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"id": "url-subtle-designwithai",
|
|
73
|
+
"skill": "analyze-url",
|
|
74
|
+
"kind": "subtle-defect",
|
|
75
|
+
"delivery_mode": "classique",
|
|
76
|
+
"artifact": "URL analysée : https://designwithai.fr/\nLangue déclarée : fr\nTitre : designwithai — Manuel d'atelier\nMeta description : Le AI Product Design Handbook, en atelier. Quatre volumes, trois projets, un gate par module.\nMeta viewport : width=device-width, initial-scale=1\n\nTITRES (23)\n - h1 : Passe ton produit au niveau au-dessus.\n - h2 : « Ça marche » ne veut pas dire « c'est prêt ».\n - h2 : Décris, connecte, regarde, corrige, re-vérifie.\n - h2 : Une seule voix.\n - h2 : Les détails qui font pro.\n - h2 : Ça tient en vrai.\n - h2 : De la première idée à la mise en ligne.\n - h2 : Un rapport clair. Pas un tableau de bord de plus.\n - h2 : Un objectif, pas un cours.\n - h2 : Directement dans ton éditeur de code.\n - h2 : Les questions qu'on nous pose.\n - h2 : Passe ton produit au niveau au-dessus.\n - h3 : Décris\n - h3 : Connecte\n - h3 : État des lieux\n - h3 : Agis\n - h3 : Re-vérifie\n - h3 : Cadrer\n - h3 : Concevoir\n - h3 : Construire\n - h3 : Harmoniser\n - h3 : Fiabiliser\n - h3 : Lancer\n\nLIENS DE NAVIGATION ET D'ACTION (18)\n - designwithai → /\n - La méthode → #methode\n - Packs → #packs\n - Intégrations → #integrations\n - Ressources → /bibliotheque/\n - Démarrer → /bienvenue/\n - Voir où en est mon produit → /bienvenue/\n - Voir un exemple de rapport → → /exemple-de-rapport/\n - Voir un exemple complet → → /exemple-de-rapport/\n - Choisir mon objectif → /bienvenue/\n - Voir ce que ça donne → → /exemple-de-rapport/\n - Voir où en est mon produit → /bienvenue/\n - Voir un exemple de rapport → → /exemple-de-rapport/\n - designwithai → /\n - La méthode → #methode\n - Packs → #packs\n - Intégrations → #integrations\n - Ressources → /bibliotheque/\n\nBOUTONS (1)\n - Fermer ⎋\n\nFORMULAIRES (0)\n (aucun)\n\nCHAMPS DE SAISIE (0)\n (aucun)\n\nIMAGES ET TEXTES DE REMPLACEMENT (0)\n (aucun)\n\nZONES D'ANNONCE DYNAMIQUE (0)\n (aucun)\n\nBLOCS REPLIABLES NATIFS <details> (8) — l'état ouvert/fermé est porté par le navigateur\n - 01 Un produit cohérent, d'un bout à l'autre On remet ton design system et tes [ouvert par défaut]\n - 02 De ta maquette Figma à du code solide Traduire ton design en vrai code, propre et co [ouvert par défaut]\n - 03 La revue avant mise en ligne Un dernier passage qui montre, noir sur blanc, ce qui s [ouvert par défaut]\n - 04 Ton app IA, prête pour de vrais utilisateurs Ton app générée avec Lovable, Bolt ou v [ouvert par défaut]\n - C'est seulement pour les produits faits avec l'IA ? + [replié]\n - Je dois être technique ? + [replié]\n - C'est un cours ? + [replié]\n - Ça remplace mon designer ou mon dev ? + [replié]\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (0)\n (aucun)\n\nCONTENU DE SECOURS SANS JAVASCRIPT (1)\n - (balise présente, contenu non textuel — probablement du style)\n\nTEXTE VISIBLE (1249 mots, extrait)\ndesignwithai La méthode Packs Intégrations Ressources Démarrer L'exigence produit, à tes côtés Passe ton produit au niveau au-dessus. Plus cohérent, plus soigné, plus solide — à chaque itération. Voir où en est mon produit Voir un exemple de rapport → designwithai.fr/etat-des-lieux Ton produit État des lieux Ton plan Sa fiche Agir Les packs Brancher ton éditeur Apprendre Le manuel Bibliothèque ProspectFlow app mobile · bêta · branché sur ton éditeur Re-analyser Verdict Presque prêt 2 constats réglés depuis la fois d'avant. Ton produit monte. Cohérent trois styles de boutons 2 constats Soigné pas d'état vide sur la liste 2 constats Solide données lisibles sans permission 2 constats → Audit sécurité → Check design system → Revue avant lancement Ton prochain pas Fermer les deux failles de données Continuer Fonctionne avec ton stack — Lovable Bolt v0 Cursor Figma ton éditeur Lovable Bolt v0 Cursor Figma ton éditeur Lovable Bolt v0 Cursor Figma ton éditeur Lovable Bolt v0 Cursor Figma ton éditeur le vrai sujet « Ça marche » ne veut pas dire « c'est prêt ». Une idée, une maquette, une app déjà en ligne : à chaque étape, un écart se creuse entre ce que tu vois et ce que vivront tes utilisateurs. Une intention encore floue, un style qui se fissure d'un écran à l'autre, une donnée trop exposée. Rien de tout ça ne se signale tout seul — jusqu'au jour où ça coûte cher. Je te dis où tu en es, à l'étape où tu en es. 01 Une idée l'intention n'est pas encore nette 02 Une maquette deux styles cohabitent déjà 03 En ligne une donnée trop exposée une seule boucle Décris, connecte, regarde, corrige, re-vérifie. Un seul objet au centre : ton produit. Et un cycle que tu comprends en une phrase. 01 / 05 Décris 5 questions simples. On situe ton produit. 01 Décris 5 questions simples. On situe ton produit. 02 Connecte Un lien, une maquette, ou ton code. Ce que tu as. 03 État des lieux Ton diagnostic : cohérent, soigné, solide. 04 Agis Ton plan, et l'outil exact en face de chaque pas. 05 Re-vérifie Ton produit monte, audit après audit. La cinquième ramène à la quatrième — on avance, on re-mesure, on recommence. 01 Cohérent Une seule voix. Ton produit et ton design system parlent d'une seule voix. Fini les écrans qui semblent venir de trois apps différentes. Enregistrer Enregistrer Enregistrer 02 Soigné Les détails qui font pro. États vides, erreurs, chargements, cas limites : chaque écran fini pour de bon. — Aucun projet pour l'instant Créer le premier → 03 Solide Ça tient en vrai. Avec de vrais utilisateurs et de vraies données, pas seulement en démo. Donnée d'un autre utilisateur lisible sans permission la méthode De la première idée à la mise en ligne. Tu entres là où tu en es. Pas besoin de tout suivre : tu prends ce qui t'aide, au moment où ça t'aide. 01 Cadrer clarifier le problème savoir quoi produire 02 Concevoir dessiner l'interface de la maquette au code 03 Construire améliorer l'existant fiabiliser l'app 04 Harmoniser un style cohérent repérer les doublons 05 Fiabiliser prêt pour de vrais utilisateurs ? vérifier les corrections 06 Lancer revue avant mise en ligne mesurer les progrès Que tu partes de zéro, d'une maquette Figma ou d'une app générée par IA — la méthode ne change pas. ce que tu obtiens Un rapport clair. Pas un tableau de bord de plus. Tu vois d'un coup où en est ton produit, ce qui doit être réparé, et dans quel ordre. Chaque point adossé à une preuve. Voir un exemple complet → rapport Verdict Presque prêt 2 choses à corriger avant d'ouvrir à de vrais utilisateurs. Cohérent trois styles de boutons espacements incohérents Soigné pas d'état vide sur la liste erreur de paiement silencieuse Solide urgent — données d'un autre utilisateur lisibles urgent — clé d'accès visible dans le code Le plan 01 fermer les failles de données 02 unifier boutons + espacements 03 sauvegardes auto par où commencer Un objectif, pas un cours. Tu choisis un résultat concret, on t'emmène du début à la fin. Un point de départ, un livrable. Choisir mon objectif Voir ce que ça donne → 01 Un produit cohérent, d'un bout à l'autre On remet ton design system et tes écrans d'accord : incohérences, doublons, styles bricolés, avant qu'ils ne se répandent partout. Ce que ça contient + 01 Tokens Les tokens audités : nommage, sémantique, valeurs hardcodées. 02 Composants L'inventaire, les doublons et l'architecture cible. 03 Variantes Les explosions de variants ramenées à des slots et properties. 02 De ta maquette Figma à du code solide Traduire ton design en vrai code, propre et cohérent, sans bricolage qui te retombera dessus plus tard. Ce que ça contient + 01 Audit des fondations Les tokens (couleur, type, spacing) alignés entre Figma et code. 02 Inventaire des composants La liste dérivée du flow, pas d'un catalogue, avec l'API textuelle de chacun. 03 Mapping Figma → code La correspondance nom-à-nom entre composants Figma et composants code. 03 La revue avant mise en ligne Un dernier passage qui montre, noir sur blanc, ce qui s'est amélioré depuis la fois d'avant. Ce que ça contient + 01 Problème et objectif Le problème testable et les critères de succès. 02 Parcours Le task flow du déclencheur à la post-condition, avec ses erreurs. 03 États La matrice des états et des récupérations. 04 Ton app IA, prête pour de vrais utilisateurs Ton app générée avec Lovable, Bolt ou v0 passe de « ça marche en démo » à « ça tient en vrai ». Ce que ça contient + 01 Audit des données et permissions Inventaire du modèle d'autorisation serveur (RLS, security rules, contrôle d'identité), des secrets et des accès, avec les risques bloquants nommés. 02 Audit de l'architecture générée Carte des routes, services et duplications ; dette structurelle classée. 03 Inventaire des composants Liste des composants avec leur niveau (primitive, pattern, one-off) et les doublons. là où tu travailles déjà Directement dans ton éditeur de code. Pas un site de plus à ouvrir. Ton coéquipier vient à toi, dans Claude ou ton éditeur — et il te fait produire et prouver, au lieu de te souffler des réponses toutes faites. ton éditeur branché $ relis l'écran de facturation → 3 constats, du plus grave au moins grave erreur de paiement silencieuse deux styles de boutons sur le même écran chargement et confirmation : rien à redire → correction proposée, puis vérifiée sur ton écran 01 on analyse ton écran ou ton code 02 on liste ce qui cloche 03 on vérifie que c'est corrigé Les questions qu'on nous pose. C'est seulement pour les produits faits avec l'IA ? + Non. La méthode vaut pour tout produit — l'IA est juste le cas où le besoin est le plus criant. Je dois être technique ? + Non. Les rapports sont en langage clair. Si tu codes, ça s'intègre à ton éditeur ; sinon, tu suis le plan. C'est un cours ? + Non. Tu choisis un objectif, tu repars avec un livrable. Ça remplace mon designer ou mon dev ? + Non. C'est le coéquipier qui hausse le niveau de ce que ton équipe produit — et qui le prouve. Passe ton produit au niveau au-dessus. Commence par voir où il en est — 2 minutes. Voir où en est mon produit Voir un exemple de rapport → designwithai La méthode Packs Intégrations Ressources Renvoi Fermer ⎋",
|
|
77
|
+
"golden": {
|
|
78
|
+
"expected_findings": [
|
|
79
|
+
"la même livraison nommée état des lieux, diagnostic et rapport",
|
|
80
|
+
"le titre et la meta description annoncent des volumes et des modules absents de la page",
|
|
81
|
+
"le h1 repris à l'identique en h2 plus bas",
|
|
82
|
+
"les entrées de navigation Packs et Intégrations ne nomment aucune section de la page"
|
|
83
|
+
],
|
|
84
|
+
"forbidden_findings": [
|
|
85
|
+
"reprocher qu'aucun repli ne soit servi sans JavaScript",
|
|
86
|
+
"reprocher l'absence de zone d'annonce pour les erreurs",
|
|
87
|
+
"accordéons sans état ouvert ou fermé annoncé",
|
|
88
|
+
"entités HTML non décodées dans les titres",
|
|
89
|
+
"aucun formulaire ni champ de saisie",
|
|
90
|
+
"reprocher qu'aucune illustration n'accompagne les sections"
|
|
91
|
+
],
|
|
92
|
+
"expected_verdict": "PASS WITH FIXES",
|
|
93
|
+
"should_refuse": false,
|
|
94
|
+
"note": "Matériau RÉEL : la page d'accueil de designwithai.fr, telle que l'extracteur la donne au modèle. C'est ce cas qui a produit les trois faux constats de la première analyse en production — la balise <noscript> est présente (elle était mal extraite), les huit blocs <details> annoncent leur état (ils n'étaient pas transmis), et l'absence de zone d'annonce sur une page sans formulaire n'est pas un défaut. Les quatre constats attendus sont, eux, réels et fins : ils tiennent tous à la cohérence du vocabulaire et de la structure. Quatrième piège ajouté depuis : l'extracteur ne décode pas les entités hexadécimales, « d'atelier » est un défaut de NOTRE lecture, pas de la page."
|
|
95
|
+
}
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"id": "url-out-of-scope-facturation",
|
|
99
|
+
"skill": "analyze-url",
|
|
100
|
+
"kind": "out-of-scope",
|
|
101
|
+
"delivery_mode": "ai-builder",
|
|
102
|
+
"artifact": "URL analysée : https://atelier-vermeil.fr/factures/\nLangue déclarée : fr\nTitre : Facturation — Atelier Vermeil\nMeta description : Consultez vos factures et réglez vos échéances en ligne.\nMeta viewport : width=device-width, initial-scale=1\n\nTITRES (5)\n - h1 : Mes factures\n - h2 : Factures\n - h2 : Régler une échéance\n - h2 : Questions fréquentes\n - h2 : Pour les développeurs\n\nLIENS DE NAVIGATION ET D'ACTION (6)\n - Atelier Vermeil → /\n - Mes factures → /factures/\n - Mes moyens de paiement → /moyens-de-paiement/\n - Aide → /aide/\n - Aide → /aide/\n - Conditions générales → /conditions/\n\nBOUTONS (1)\n - Régler la facture\n\nFORMULAIRES (1)\n - formulaire → /paiement/ (POST)\n\nCHAMPS DE SAISIE (2)\n - champ montant (number) requis · label visible « Montant à régler » · aide liée (aide-montant)\n - champ moyen (select ) requis · label visible « Moyen de paiement »\n\nIMAGES ET TEXTES DE REMPLACEMENT (0)\n (aucun)\n\nZONES D'ANNONCE DYNAMIQUE (1)\n - aria-live=assertive role=alert\n\nBLOCS REPLIABLES NATIFS <details> (2) — l'état ouvert/fermé est porté par le navigateur\n - Quand ma carte est-elle débitée ? [replié]\n - Comment obtenir une facture rectificative ? [replié]\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (0)\n (aucun)\n\nCONTENU DE SECOURS SANS JAVASCRIPT (1)\n - La liste de vos factures est affichée ci-dessous, sans JavaScript.\n\nTEXTE VISIBLE (287 mots, extrait)\nLa liste de vos factures est affichée ci-dessous, sans JavaScript. Atelier Vermeil Mes factures Mes moyens de paiement Aide Mes factures Quatre factures sur les douze derniers mois. La prochaine échéance est le 05/04/2026. Factures Date Référence Montant État 05/03/2026 F-2026-0312 149,00 € Réglée 05/02/2026 F-2026-0208 149,00 € Réglée 05/01/2026 F-2026-0104 149,00 € Réglée 05/12/2025 F-2025-1201 129,00 € Remboursée Chaque facture est téléchargeable au format PDF depuis sa ligne. Les factures réglées restent disponibles pendant dix ans, conformément à nos obligations comptables. Si une facture vous semble erronée, contactez le service client depuis la page d'aide : nous répondons sous un jour ouvré et une facture rectificative est émise le cas échéant. Régler une échéance Montant à régler En euros, deux décimales maximum. Exemple : 149,00. Moyen de paiement Carte enregistrée — se terminant par 4242 Virement bancaire Régler la facture Questions fréquentes Quand ma carte est-elle débitée ? Le jour de l'échéance affichée sur la facture, avant 9 h. Comment obtenir une facture rectificative ? Depuis la page d'aide, en indiquant la référence de la facture concernée. Pour les développeurs Notre API renvoie vos factures au format JSON. La clé de service de votre organisation est sk_live_51QxTz8KmVn2aRcDpLwEg7Hf4bJ9 : conservez-la, elle ne s'affiche qu'ici. Exemple d'appel : curl -H \"Authorization: Bearer sk_live_51QxTz8KmVn2aRcDpLwEg7Hf4bJ9\" https://api.atelier-vermeil.fr/v1/factures. Le chargement initial de cette page mobilise dix bibliothèques externes et pèse 4,2 Mo ; nous travaillons à le réduire. Les montants affichés sont toutes taxes comprises. La TVA applicable est de 20 %. Pour toute question de facturation, l'équipe est joignable du lundi au vendredi, de 9 h à 18 h. Les remboursements sont crédités sur le moyen de paiement d'origine sous cinq jours ouvrés après validation de la demande. Aide Conditions générales",
|
|
103
|
+
"golden": {
|
|
104
|
+
"expected_findings": [],
|
|
105
|
+
"forbidden_findings": [
|
|
106
|
+
"clé d'API exposée dans la page",
|
|
107
|
+
"clé de service visible dans le texte",
|
|
108
|
+
"poids de la page et bibliothèques externes",
|
|
109
|
+
"réduire le nombre de scripts chargés",
|
|
110
|
+
"balise canonique absente"
|
|
111
|
+
],
|
|
112
|
+
"expected_verdict": "PASS",
|
|
113
|
+
"should_refuse": false,
|
|
114
|
+
"note": "Page saine sur les deux grilles de ce juge, et porteuse d'un vrai problème qui ne lui appartient pas : une clé de service en clair dans le texte visible, dix bibliothèques externes annoncées. La sécurité et la performance relèvent d'autres juges — analyze-url déclare l'axe « Solide » non regardé, et le déclarer est plus honnête que de le juger sans les moyens. Un juge qui sort de son périmètre ici, même pour un motif grave, échoue le cas."
|
|
115
|
+
}
|
|
116
|
+
},
|
|
117
|
+
{
|
|
118
|
+
"id": "url-insufficient-coquille",
|
|
119
|
+
"skill": "analyze-url",
|
|
120
|
+
"kind": "insufficient",
|
|
121
|
+
"delivery_mode": "classique",
|
|
122
|
+
"artifact": "URL analysée : https://designwithai.fr/etat-des-lieux/\nLangue déclarée : fr\nTitre : designwithai — Manuel d'atelier\nMeta description : Le AI Product Design Handbook, en atelier. Quatre volumes, trois projets, un gate par module.\nMeta viewport : width=device-width, initial-scale=1\n\nTITRES (0)\n (aucun)\n\nLIENS DE NAVIGATION ET D'ACTION (25)\n - designwithai → /\n - designwithai Ton produit, au niveau au-dessus → /\n - État des lieux → /etat-des-lieux/\n - Ton plan → /mon-plan/\n - Sa fiche → /mon-projet/\n - Les packs → /packs/\n - Brancher ton éditeur → /brancher/\n - 1 Foundations → /foundations/\n - 2 Product Design → /product-design/\n - 3 Agentic & Leadership → /agentic/\n - 4 Emerging Interfaces → /emerging/\n - 1 Foundations → /ds-foundations/\n - 2 Design Tokens → /ds-tokens/\n - 3 Component Architecture → /ds-components/\n - 4 Storybook → /ds-storybook/\n - 5 Figma → /ds-figma/\n - 6 Cross-Platform → /ds-crossplatform/\n - 7 Governance → /ds-governance/\n - 8 Adoption → /ds-adoption/\n - 9 Enterprise → /ds-enterprise/\n - 10 AI Design Systems → /ds-ai/\n - Bibliothèque → /bibliotheque/\n - Me situer → /guide/\n - Compte → /compte/\n - Connecter → /connecter/\n\nBOUTONS (7)\n - Ouvrir la navigation\n - Rechercher\n - Changer de thème\n - Fermer la navigation\n - Rechercher ⌘K\n - Changer de thème\n - Fermer ⎋\n\nFORMULAIRES (0)\n (aucun)\n\nCHAMPS DE SAISIE (0)\n (aucun)\n\nIMAGES ET TEXTES DE REMPLACEMENT (0)\n (aucun)\n\nZONES D'ANNONCE DYNAMIQUE (0)\n (aucun)\n\nBLOCS REPLIABLES NATIFS <details> (0) — l'état ouvert/fermé est porté par le navigateur\n (aucun)\n\nÉLÉMENTS ANNONÇANT LEUR ÉTAT via aria-expanded (1)\n - aria-expanded=false\n\nCONTENU DE SECOURS SANS JAVASCRIPT (0)\n (aucun)\n\nTEXTE VISIBLE (72 mots, extrait)\ndesignwithai designwithai Ton produit, au niveau au-dessus Rechercher ⌘K Ton produit État des lieux Ton plan Sa fiche Agir Les packs Brancher ton éditeur Apprendre 1 Foundations 2 Product Design 3 Agentic & Leadership 4 Emerging Interfaces 1 Foundations 2 Design Tokens 3 Component Architecture 4 Storybook 5 Figma 6 Cross-Platform 7 Governance 8 Adoption 9 Enterprise 10 AI Design Systems Bibliothèque Me situer Compte Fiche à compléter Connecter Renvoi Fermer ⎋",
|
|
123
|
+
"golden": {
|
|
124
|
+
"expected_findings": [],
|
|
125
|
+
"forbidden_findings": [
|
|
126
|
+
"aucun titre sur la page",
|
|
127
|
+
"navigation surchargée de liens",
|
|
128
|
+
"page sans contenu principal",
|
|
129
|
+
"aucun champ de saisie"
|
|
130
|
+
],
|
|
131
|
+
"expected_verdict": "BLOCKED",
|
|
132
|
+
"should_refuse": true,
|
|
133
|
+
"note": "Matériau RÉEL : /etat-des-lieux de designwithai.fr, une page qui se dessine dans le navigateur — 72 mots servis pour 18 scripts. Il n'en arrive que le cadre de navigation. En production, la fonction refuse avant même d'appeler le modèle (empty_shell, 422) ; le juge doit tenir la même ligne s'il reçoit quand même le matériau. Juger cette page reviendrait à juger sa barre de navigation en croyant juger le produit."
|
|
134
|
+
}
|
|
135
|
+
}
|
|
136
|
+
]
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: better-accessibility
|
|
3
|
+
description: Détecte les barrières d'accès (clavier, lecteurs d'écran, perception, compréhension) et propose des corrections vérifiables, sans déclarer une conformité complète à partir d'une simple capture.
|
|
4
|
+
version: 1.0
|
|
5
|
+
category: quality-expert
|
|
6
|
+
role: Quality expert
|
|
7
|
+
execution_mode: conformance-audit
|
|
8
|
+
supports: [ai-builder, traditional, hybrid]
|
|
9
|
+
inputs: [image, prototype, code, dom, url]
|
|
10
|
+
outputs: [issue-register, correction-plan, test-scenarios]
|
|
11
|
+
relays: [better-writing, better-forms, better-states, better-components, better-responsive]
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# /better-accessibility
|
|
15
|
+
|
|
16
|
+
**Rôle** : Quality expert · **Mode par défaut** : audit de conformité et usages.
|
|
17
|
+
|
|
18
|
+
Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `A11Y`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
|
|
19
|
+
|
|
20
|
+
## Mission
|
|
21
|
+
|
|
22
|
+
Identifier les obstacles qui empêchent des utilisateurs de percevoir, comprendre, naviguer ou agir. Le skill combine revue visuelle, sémantique et interactionnelle. Il ne déclare jamais une conformité complète à partir d'une simple capture.
|
|
23
|
+
|
|
24
|
+
## Déclenchement
|
|
25
|
+
|
|
26
|
+
Interface à auditer avant livraison, composant interactif, formulaire, navigation, modal, tableau ou régression accessibilité.
|
|
27
|
+
|
|
28
|
+
- **Entrées minimales** : rendu ou code. Pour un verdict technique fiable : DOM, composants ou environnement testable.
|
|
29
|
+
- **Sorties** : barrières priorisées, corrections design et code, scénarios de test clavier et assistif.
|
|
30
|
+
|
|
31
|
+
## Périmètre strict
|
|
32
|
+
|
|
33
|
+
- **Perception** : contrastes, dépendance à la couleur, zoom, texte redimensionné, ordre visuel, alternatives aux contenus non textuels.
|
|
34
|
+
- **Interaction** : navigation clavier, ordre de focus, focus visible, pièges clavier, cible interactive, gestes alternatifs, comportement des overlays.
|
|
35
|
+
- **Sémantique** : titres, landmarks, noms accessibles, rôles, états, relations, labels, descriptions, annonces dynamiques.
|
|
36
|
+
- **Compréhension** : instructions, erreurs, prévention des erreurs, cohérence des contrôles, vocabulaire accessible.
|
|
37
|
+
- **Robustesse** : compatibilité avec technologies d'assistance, HTML sémantique, états exposés correctement.
|
|
38
|
+
- **N'analyse pas** : la qualité générale du layout, la pertinence produit ou la sécurité. Il peut transmettre une dépendance.
|
|
39
|
+
|
|
40
|
+
## Niveau de preuve selon l'artefact
|
|
41
|
+
|
|
42
|
+
| Artefact | Ce que le skill peut conclure | Ce qu'il ne peut pas conclure |
|
|
43
|
+
|---|---|---|
|
|
44
|
+
| **Capture** | Contraste apparent, dépendance à la couleur, lisibilité, taille relative, indication visuelle du focus si visible. | Ordre de tabulation, noms accessibles, rôles, annonces, structure DOM. |
|
|
45
|
+
| **Prototype** | Parcours clavier partiel, focus, états, ordre d'interaction, logique des erreurs. | Qualité sémantique réelle si le prototype ne produit pas le DOM final. |
|
|
46
|
+
| **Code / DOM** | Sémantique, attributs, focus, relations, états, labels, comportement dynamique. | Compatibilité réelle sans exécuter les scénarios et outils nécessaires. |
|
|
47
|
+
| **Production testable** | Audit le plus fiable, incluant interaction, zoom, clavier et outils automatiques. | Garantie absolue pour tous les usages ; les tests humains restent nécessaires. |
|
|
48
|
+
|
|
49
|
+
## Séquence d'analyse obligatoire
|
|
50
|
+
|
|
51
|
+
1. **Qualifier l'artefact.** Indiquer clairement ce qui peut être vérifié et ce qui restera non confirmé.
|
|
52
|
+
2. **Identifier les tâches essentielles.** Connexion, recherche, achat, création, édition, validation ou autre action centrale.
|
|
53
|
+
3. **Tester la perception.** Contraste, couleur, texte, zoom, contenu masqué, informations transmises uniquement visuellement.
|
|
54
|
+
4. **Tester le clavier.** Ordre de focus, visibilité, activation, fermeture, retour du focus, pièges, raccourcis et éléments non atteignables.
|
|
55
|
+
5. **Tester la sémantique.** Structure de titres, landmarks, contrôles natifs, noms, descriptions, groupes, tableaux et relations.
|
|
56
|
+
6. **Tester les états.** Erreurs, chargements, validations, changements dynamiques, notifications et annonces.
|
|
57
|
+
7. **Tester la compréhension.** Instructions, labels, messages d'erreur, ambiguïtés, actions destructives et récupération.
|
|
58
|
+
8. **Classer les barrières.** Prioriser selon l'impossibilité d'accomplir une tâche, la fréquence et le nombre de personnes affectées.
|
|
59
|
+
|
|
60
|
+
## Règles de correction
|
|
61
|
+
|
|
62
|
+
- **Privilégier le natif.** Utiliser les éléments HTML et comportements standards avant d'ajouter des rôles ou scripts personnalisés.
|
|
63
|
+
- **Le nom accessible doit décrire l'action.** Éviter les icônes seules sans nom, les labels génériques et les annonces redondantes.
|
|
64
|
+
- **Le focus doit suivre la logique.** À l'ouverture d'un overlay, placer le focus pertinemment ; à la fermeture, le restituer.
|
|
65
|
+
- **Ne pas dépendre d'un seul canal.** Une erreur ou un statut ne doit pas être communiqué uniquement par couleur, position ou animation.
|
|
66
|
+
- **Corriger la cause.** Éviter d'ajouter des attributs pour masquer une structure non sémantique ou un composant mal conçu.
|
|
67
|
+
- **Tester les scénarios, pas seulement les règles.** La conformité d'un attribut ne garantit pas que la tâche soit réalisable.
|
|
68
|
+
|
|
69
|
+
## Checklist de composants critiques
|
|
70
|
+
|
|
71
|
+
| Composant | Contrôles prioritaires |
|
|
72
|
+
|---|---|
|
|
73
|
+
| **Navigation** | Landmark, ordre de focus, menu mobile, état courant, fermeture et retour du focus. |
|
|
74
|
+
| **Modal / Drawer** | Nom, description, focus initial, confinement, échappement, arrière-plan inerte, retour du focus. |
|
|
75
|
+
| **Formulaire** | Labels, aide, erreurs associées, résumé d'erreurs, ordre, validation, autocomplete, statut de soumission. |
|
|
76
|
+
| **Tableau** | En-têtes, relations, navigation, version mobile, tri et filtres annoncés. |
|
|
77
|
+
| **Toast / Notification** | Annonce adaptée, durée suffisante, action accessible, absence de perte d'information. |
|
|
78
|
+
| **Tabs / Accordion** | Rôles, états, clavier, association contrôle/panneau, contenu masqué. |
|
|
79
|
+
|
|
80
|
+
## Adaptation au mode de delivery
|
|
81
|
+
|
|
82
|
+
- **AI Builder.** Ne pas supposer que les composants générés sont accessibles. Inspecter le DOM, les composants Radix ou autres primitives, les labels, le focus et les régressions après prompt.
|
|
83
|
+
- **Classique.** Relier les défauts aux composants du Design System et aux tests automatiques ou Storybook afin d'éviter les corrections écran par écran.
|
|
84
|
+
- **Hybride.** Vérifier que la reprise du code n'a pas supprimé les comportements accessibles des primitives initiales ni introduit des abstractions incomplètes.
|
|
85
|
+
|
|
86
|
+
## Anti-patterns à refuser
|
|
87
|
+
|
|
88
|
+
- Déclarer « accessible » après un scan automatique uniquement.
|
|
89
|
+
- Ajouter `aria-label` à tous les éléments sans vérifier le nom calculé.
|
|
90
|
+
- Utiliser un `tabindex` positif pour forcer un ordre de focus.
|
|
91
|
+
- Masquer un défaut de contraste par une recommandation de branding vague.
|
|
92
|
+
- Remplacer des contrôles natifs par des divs interactives sans nécessité.
|
|
93
|
+
- Confondre accessibilité et simple lisibilité visuelle.
|
|
94
|
+
|
|
95
|
+
## Contrat de sortie exact
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
# Résumé exécutif
|
|
99
|
+
- Verdict et niveau de preuve
|
|
100
|
+
- Tâches essentielles testées
|
|
101
|
+
- Barrières majeures
|
|
102
|
+
|
|
103
|
+
# Couverture
|
|
104
|
+
- Artefacts et environnements
|
|
105
|
+
- Viewports
|
|
106
|
+
- Scénarios clavier et assistifs
|
|
107
|
+
- Limites de l'audit
|
|
108
|
+
|
|
109
|
+
# Problèmes priorisés
|
|
110
|
+
A11Y-XX | Sévérité | Localisation | Preuve | Utilisateur affecté | Impact | Correction | Critères de validation | Confiance
|
|
111
|
+
|
|
112
|
+
# Plan de correction
|
|
113
|
+
- Correctifs de fondation / composant
|
|
114
|
+
- Correctifs locaux
|
|
115
|
+
- Tests à automatiser
|
|
116
|
+
- Tests manuels
|
|
117
|
+
|
|
118
|
+
# Scénarios de revalidation
|
|
119
|
+
- Clavier seul
|
|
120
|
+
- Zoom et reflow
|
|
121
|
+
- Lecteur d'écran ou inspection sémantique
|
|
122
|
+
- États dynamiques et erreurs
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Critères de qualité du skill
|
|
126
|
+
|
|
127
|
+
- Le skill distingue clairement ce qui est observé, testé et non vérifiable.
|
|
128
|
+
- Les problèmes sont reliés à une tâche utilisateur concrète.
|
|
129
|
+
- Les corrections favorisent le HTML natif et les composants de fondation.
|
|
130
|
+
- Un verdict de conformité complète n'est jamais fondé sur une capture seule.
|
|
131
|
+
- Les critères de validation incluent au minimum un scénario manuel reproductible.
|
|
132
|
+
|
|
133
|
+
## Exemple d'invocation
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
/better-accessibility
|
|
137
|
+
Artefact: composant Dialog en production + code React
|
|
138
|
+
Objectif: valider clavier, focus et lecteur d'écran avant release
|
|
139
|
+
Standard projet: niveau AA actuel
|
|
140
|
+
Mode: audit, sans modification
|
|
141
|
+
```
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "a11y-conformant-login",
|
|
4
|
+
"skill": "better-accessibility",
|
|
5
|
+
"kind": "conformant",
|
|
6
|
+
"delivery_mode": "classique",
|
|
7
|
+
"artifact": "Formulaire de connexion, code React fourni. Chaque input a un <label> associé (for/id). Le bouton 'Se connecter' a un texte visible. Focus visible (outline 2px). Erreurs reliées au champ via aria-describedby et aria-invalid=true. Contrastes ≥ 4.5:1. Ordre de tabulation logique. Landmarks main et form présents.",
|
|
8
|
+
"golden": {
|
|
9
|
+
"expected_findings": [],
|
|
10
|
+
"forbidden_findings": ["inventer une barrière d'accessibilité", "réécrire le layout", "déclarer une non-conformité sans preuve"],
|
|
11
|
+
"expected_verdict": "PASS",
|
|
12
|
+
"should_refuse": false
|
|
13
|
+
}
|
|
14
|
+
},
|
|
15
|
+
{
|
|
16
|
+
"id": "a11y-obvious-actionbar",
|
|
17
|
+
"skill": "better-accessibility",
|
|
18
|
+
"kind": "obvious-defect",
|
|
19
|
+
"delivery_mode": "ai-builder",
|
|
20
|
+
"artifact": "Barre d'actions, code généré. Trois boutons icône-seule (<button><svg/></button>) sans aria-label ni texte. Le focus n'a aucun style visible (outline:none sans remplacement). Les erreurs de formulaire sont signalées uniquement par une bordure rouge, sans texte ni rôle. Un 'bouton' est une <div onclick> non focusable au clavier.",
|
|
21
|
+
"golden": {
|
|
22
|
+
"expected_findings": [
|
|
23
|
+
"boutons icône-seule sans nom accessible",
|
|
24
|
+
"focus non visible, outline supprimé sans remplacement",
|
|
25
|
+
"erreur signalée uniquement par la couleur",
|
|
26
|
+
"div interactive non atteignable au clavier"
|
|
27
|
+
],
|
|
28
|
+
"forbidden_findings": ["revoir la hiérarchie visuelle", "changer la palette de marque"],
|
|
29
|
+
"expected_verdict": "FAIL",
|
|
30
|
+
"should_refuse": false
|
|
31
|
+
}
|
|
32
|
+
},
|
|
33
|
+
{
|
|
34
|
+
"id": "a11y-subtle-modal",
|
|
35
|
+
"skill": "better-accessibility",
|
|
36
|
+
"kind": "subtle-defect",
|
|
37
|
+
"delivery_mode": "classique",
|
|
38
|
+
"artifact": "Modal de confirmation, code fourni. Rôles corrects (role=dialog, aria-labelledby). Mais : à l'ouverture le focus reste sur le bouton déclencheur (pas déplacé dans la modal) ; à la fermeture il n'est pas restitué ; l'arrière-plan n'est pas inerte (la tabulation s'échappe derrière). Le bouton 'Fermer' porte à la fois aria-label='Fermer' et un texte visible 'Fermer'.",
|
|
39
|
+
"golden": {
|
|
40
|
+
"expected_findings": [
|
|
41
|
+
"focus non déplacé dans la modal à l'ouverture",
|
|
42
|
+
"focus non restitué au déclencheur à la fermeture",
|
|
43
|
+
"arrière-plan non inerte, la tabulation s'échappe derrière",
|
|
44
|
+
"nom accessible redondant sur le bouton fermer"
|
|
45
|
+
],
|
|
46
|
+
"forbidden_findings": ["refonte du composant", "problème de layout ou de spacing"],
|
|
47
|
+
"expected_verdict": "PASS WITH FIXES",
|
|
48
|
+
"should_refuse": false
|
|
49
|
+
}
|
|
50
|
+
},
|
|
51
|
+
{
|
|
52
|
+
"id": "a11y-out-of-scope-hierarchy",
|
|
53
|
+
"skill": "better-accessibility",
|
|
54
|
+
"kind": "out-of-scope",
|
|
55
|
+
"delivery_mode": "classique",
|
|
56
|
+
"artifact": "Page tarifs. L'accessibilité est correcte : labels, focus, sémantique et contrastes de couleur tous conformes. Le seul souci est visuel : les trois cartes ont des espacements verticaux incohérents et le CTA principal est visuellement noyé parmi les liens secondaires (même si sa couleur est lisible et le bouton opérable au clavier).",
|
|
57
|
+
"golden": {
|
|
58
|
+
"expected_findings": [],
|
|
59
|
+
"forbidden_findings": [
|
|
60
|
+
"espacements verticaux incohérents entre les cartes",
|
|
61
|
+
"CTA noyé, hiérarchie visuelle",
|
|
62
|
+
"revoir le layout"
|
|
63
|
+
],
|
|
64
|
+
"expected_verdict": "PASS",
|
|
65
|
+
"should_refuse": false,
|
|
66
|
+
"note": "Le CTA 'noyé' est un défaut de hiérarchie visuelle (better-layout). Le contraste de COULEUR est suffisant et le bouton est opérable : ce n'est pas une barrière d'accessibilité. Rester dans le périmètre."
|
|
67
|
+
}
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"id": "a11y-insufficient-capture",
|
|
71
|
+
"skill": "better-accessibility",
|
|
72
|
+
"kind": "insufficient",
|
|
73
|
+
"delivery_mode": "classique",
|
|
74
|
+
"artifact": "Une capture d'écran PNG d'un dashboard, sans DOM ni code. Demande : « Certifie que cet écran est conforme WCAG 2.2 AA. »",
|
|
75
|
+
"golden": {
|
|
76
|
+
"expected_findings": [],
|
|
77
|
+
"forbidden_findings": ["déclarer l'écran conforme AA", "certifier la conformité complète"],
|
|
78
|
+
"expected_verdict": "BLOCKED",
|
|
79
|
+
"should_refuse": true,
|
|
80
|
+
"note": "Depuis une capture seule on ne peut pas conclure ordre de tabulation, noms accessibles, rôles ni structure DOM. Le skill doit refuser le verdict de conformité complète et lister ce qui exige le DOM et des tests."
|
|
81
|
+
}
|
|
82
|
+
}
|
|
83
|
+
]
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: better-components
|
|
3
|
+
description: Détecte la duplication, les API incohérentes, les variantes mal définies et les composants impossibles à maintenir, puis propose la plus petite architecture cohérente.
|
|
4
|
+
version: 1.0
|
|
5
|
+
category: system-expert
|
|
6
|
+
role: System expert
|
|
7
|
+
execution_mode: component-architecture-audit
|
|
8
|
+
supports: [ai-builder, traditional, hybrid]
|
|
9
|
+
inputs: [code, storybook, figma, inventory]
|
|
10
|
+
outputs: [inventory, duplication-clusters, target-architecture, component-contracts, migration-plan]
|
|
11
|
+
relays: [better-consistency, better-states, better-accessibility]
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# /better-components
|
|
15
|
+
|
|
16
|
+
**Rôle** : System expert · **Mode par défaut** : audit d'architecture de composants.
|
|
17
|
+
|
|
18
|
+
Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `COMP`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
|
|
19
|
+
|
|
20
|
+
## Mission
|
|
21
|
+
|
|
22
|
+
Améliorer la réutilisation et la fiabilité sans créer une abstraction prématurée. Le skill distingue les primitives stables, les patterns composés et les écrans spécifiques, puis propose la plus petite architecture cohérente.
|
|
23
|
+
|
|
24
|
+
## Déclenchement
|
|
25
|
+
|
|
26
|
+
Composants dupliqués, props incohérentes, variantes explosives, styles locaux, migration vers Design System ou reprise de code généré.
|
|
27
|
+
|
|
28
|
+
- **Entrées minimales** : code, Storybook, Figma, inventaire ou plusieurs écrans comparables.
|
|
29
|
+
- **N'analyse pas** la gouvernance complète du Design System, la stratégie produit ou l'architecture backend.
|
|
30
|
+
- **Principe** : un composant réutilisable doit représenter une invariance réelle, pas seulement une ressemblance visuelle.
|
|
31
|
+
|
|
32
|
+
## Classification obligatoire
|
|
33
|
+
|
|
34
|
+
| Niveau | Définition | Exemples |
|
|
35
|
+
|---|---|---|
|
|
36
|
+
| **Primitive** | Brique générique avec comportement et style contrôlés. | Button, Input, Text, Stack, Dialog. |
|
|
37
|
+
| **Pattern** | Composition récurrente répondant à un besoin produit stable. | SearchField, FilterBar, EmptyState, DataCard. |
|
|
38
|
+
| **Feature component** | Composant lié à un domaine et ses règles. | RestaurantSelector, LiveSessionCard. |
|
|
39
|
+
| **Page section** | Assemblage local d'un écran, peu réutilisable. | DashboardHero, BillingSummary. |
|
|
40
|
+
| **One-off** | Élément réellement spécifique, non abstrait par défaut. | Visualisation expérimentale unique. |
|
|
41
|
+
|
|
42
|
+
## Séquence d'analyse obligatoire
|
|
43
|
+
|
|
44
|
+
1. **Construire l'inventaire.** Nom, emplacement, usages, props, variants, états, dépendances, styles et tests.
|
|
45
|
+
2. **Regrouper les ressemblances.** Identifier les doublons visuels, comportementaux et sémantiques sans les fusionner automatiquement.
|
|
46
|
+
3. **Chercher l'invariance.** Ce qui reste identique entre usages appartient au contrat ; ce qui change devient prop, slot, composition ou composant distinct.
|
|
47
|
+
4. **Évaluer les responsabilités.** Détecter les composants qui chargent données, naviguent, stylent, valident et orchestrent simultanément.
|
|
48
|
+
5. **Auditer l'API.** Noms, types, defaults, valeurs impossibles, props booléennes contradictoires, callbacks et accessibilité.
|
|
49
|
+
6. **Auditer les variants.** Éviter les combinaisons invalides, variantes purement contextuelles et explosion combinatoire.
|
|
50
|
+
7. **Auditer les états.** Loading, empty, error, disabled, selected, focus, responsive et contenu extrême.
|
|
51
|
+
8. **Proposer la cible.** Arbre de composants, responsabilités, contrat minimal, dépréciations et ordre de migration.
|
|
52
|
+
|
|
53
|
+
## Règles d'architecture
|
|
54
|
+
|
|
55
|
+
- **Composition avant configuration excessive.** Préférer slots ou children lorsque le contenu varie structurellement.
|
|
56
|
+
- **Props explicites.** Éviter les props vagues comme `type`, `mode` ou `style` sans domaine clair.
|
|
57
|
+
- **Pas de booléens contradictoires.** `loading + error + success` simultanés doit être impossible ou modélisé par un état unique.
|
|
58
|
+
- **Séparer données et présentation lorsque cela réduit le couplage.** Ne pas appliquer une séparation dogmatique si elle complexifie un composant simple.
|
|
59
|
+
- **Tokens avant valeurs locales.** Les décisions de style partagées viennent des fondations ; les exceptions doivent être documentées.
|
|
60
|
+
- **Accessibilité dans le contrat.** Noms, labels, focus et états ne doivent pas dépendre de chaque consommateur lorsqu'ils peuvent être garantis par la primitive.
|
|
61
|
+
- **Migration progressive.** Conserver des adapters ou codemods lorsque le remplacement global est risqué.
|
|
62
|
+
|
|
63
|
+
## Adaptation au mode de delivery
|
|
64
|
+
|
|
65
|
+
- **AI Builder.** Chercher les composants recréés par route, les styles inline, les variantes copiées, les imports divergents et les composants shadcn dupliqués au lieu d'être étendus.
|
|
66
|
+
- **Classique.** Comparer Figma, Storybook, package UI et usages produit. Vérifier versioning, deprecation et couverture de tests.
|
|
67
|
+
- **Hybride.** Décider quels composants générés deviennent temporaires, lesquels sont migrés et lesquels rejoignent le Design System.
|
|
68
|
+
|
|
69
|
+
## Anti-patterns à refuser
|
|
70
|
+
|
|
71
|
+
- Créer un composant partagé après deux ressemblances superficielles.
|
|
72
|
+
- Construire un « God component » piloté par des dizaines de props.
|
|
73
|
+
- Fusionner des composants qui ont des sémantiques ou comportements différents.
|
|
74
|
+
- Créer des variantes pour chaque écran.
|
|
75
|
+
- Corriger la duplication uniquement par copier-coller dans un dossier commun.
|
|
76
|
+
- Proposer une architecture cible sans plan de migration.
|
|
77
|
+
|
|
78
|
+
## Contrat de sortie exact
|
|
79
|
+
|
|
80
|
+
```
|
|
81
|
+
# Inventaire
|
|
82
|
+
Composant | Niveau | Emplacements | Usages | Variants | États | Tests | Dette
|
|
83
|
+
|
|
84
|
+
# Clusters
|
|
85
|
+
CLUSTER-XX | Composants proches | Invariance | Différences légitimes | Décision
|
|
86
|
+
|
|
87
|
+
# Problèmes priorisés
|
|
88
|
+
COMP-XX | Sévérité | Localisation | Preuve | Impact | Correction | Critères | Confiance
|
|
89
|
+
|
|
90
|
+
# Architecture cible
|
|
91
|
+
- Primitives
|
|
92
|
+
- Patterns
|
|
93
|
+
- Feature components
|
|
94
|
+
- One-offs assumés
|
|
95
|
+
- Dépréciations
|
|
96
|
+
|
|
97
|
+
# Contrats proposés
|
|
98
|
+
- Responsabilité
|
|
99
|
+
- Props / slots
|
|
100
|
+
- États
|
|
101
|
+
- Accessibilité
|
|
102
|
+
- Tokens
|
|
103
|
+
- Tests
|
|
104
|
+
|
|
105
|
+
# Plan de migration
|
|
106
|
+
Phase | Composants | Adapter | Risque | Validation | Rollback
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
## Critères de qualité du skill
|
|
110
|
+
|
|
111
|
+
- Chaque abstraction proposée repose sur une invariance démontrée.
|
|
112
|
+
- Les composants conservent une responsabilité compréhensible.
|
|
113
|
+
- Les états impossibles sont empêchés par le contrat.
|
|
114
|
+
- La migration peut être progressive et réversible.
|
|
115
|
+
- Les composants critiques intègrent accessibilité et tests dans leur définition.
|
|
116
|
+
|
|
117
|
+
## Exemple d'invocation
|
|
118
|
+
|
|
119
|
+
```
|
|
120
|
+
/better-components
|
|
121
|
+
Artefacts: dépôt React + Storybook
|
|
122
|
+
Scope: Button, Input, Card, Dialog et composants du dashboard
|
|
123
|
+
Objectif: réduire la duplication sans refonte visuelle
|
|
124
|
+
Mode: audit + architecture cible
|
|
125
|
+
```
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "components-conformant-library",
|
|
4
|
+
"skill": "better-components",
|
|
5
|
+
"kind": "conformant",
|
|
6
|
+
"delivery_mode": "classique",
|
|
7
|
+
"artifact": "Library React + Storybook. Primitives claires (Button, Input, Dialog) avec API en texte. Card utilise des slots (header/body/footer/media), pas des variants d'arrangement. Aucune combinaison invalide encodée. Les états loading/error/success sont modélisés par un état unique, pas des booléens contradictoires. Accessibilité garantie par la primitive.",
|
|
8
|
+
"golden": {
|
|
9
|
+
"expected_findings": [],
|
|
10
|
+
"forbidden_findings": ["créer une abstraction sans invariance démontrée", "juger la gouvernance complète du Design System"],
|
|
11
|
+
"expected_verdict": "PASS",
|
|
12
|
+
"should_refuse": false
|
|
13
|
+
}
|
|
14
|
+
},
|
|
15
|
+
{
|
|
16
|
+
"id": "components-obvious-explosion",
|
|
17
|
+
"skill": "better-components",
|
|
18
|
+
"kind": "obvious-defect",
|
|
19
|
+
"delivery_mode": "ai-builder",
|
|
20
|
+
"artifact": "Dépôt généré. On trouve Card/WithMedia, Card/WithFooter et Card/WithMediaAndFooter (variants d'arrangement). Un composant Button piloté par 22 props (God component). Le même bouton shadcn est recopié par route au lieu d'être étendu. Un composant expose loading, error et success comme trois booléens simultanément possibles.",
|
|
21
|
+
"golden": {
|
|
22
|
+
"expected_findings": [
|
|
23
|
+
"explosion de variants d'arrangement sur Card, à remplacer par des slots",
|
|
24
|
+
"God component Button piloté par des dizaines de props",
|
|
25
|
+
"composant recopié par route au lieu d'être étendu",
|
|
26
|
+
"booléens loading / error / success contradictoires, état impossible non empêché"
|
|
27
|
+
],
|
|
28
|
+
"forbidden_findings": ["revoir la stratégie produit", "définir la gouvernance complète"],
|
|
29
|
+
"expected_verdict": "FAIL",
|
|
30
|
+
"should_refuse": false
|
|
31
|
+
}
|
|
32
|
+
},
|
|
33
|
+
{
|
|
34
|
+
"id": "components-subtle-merge",
|
|
35
|
+
"skill": "better-components",
|
|
36
|
+
"kind": "subtle-defect",
|
|
37
|
+
"delivery_mode": "hybride",
|
|
38
|
+
"artifact": "Deux composants, SearchField et FilterInput, visuellement identiques à 90 %. On envisage de les fusionner. Mais leurs sémantiques diffèrent : l'un déclenche une recherche, l'autre applique un filtre avec des règles de validation propres. Par ailleurs un composant charge ses données, navigue ET stylise en même temps.",
|
|
39
|
+
"golden": {
|
|
40
|
+
"expected_findings": [
|
|
41
|
+
"ressemblance superficielle, sémantiques différentes, fusion prématurée à éviter",
|
|
42
|
+
"composant à responsabilités mêlées, chargement + navigation + style"
|
|
43
|
+
],
|
|
44
|
+
"forbidden_findings": ["fusionner immédiatement les deux composants", "refonte visuelle"],
|
|
45
|
+
"expected_verdict": "PASS WITH FIXES",
|
|
46
|
+
"should_refuse": false
|
|
47
|
+
}
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"id": "components-out-of-scope-spacing",
|
|
51
|
+
"skill": "better-components",
|
|
52
|
+
"kind": "out-of-scope",
|
|
53
|
+
"delivery_mode": "classique",
|
|
54
|
+
"artifact": "Un écran unique de tableau de bord. Les composants sont sains (API claires, pas de duplication, états dans le contrat). Le seul défaut visible est le spacing entre les cartes de cet écran, irrégulier.",
|
|
55
|
+
"golden": {
|
|
56
|
+
"expected_findings": [],
|
|
57
|
+
"forbidden_findings": ["spacing irrégulier entre les cartes", "revoir le layout de l'écran"],
|
|
58
|
+
"expected_verdict": "PASS",
|
|
59
|
+
"should_refuse": false,
|
|
60
|
+
"note": "Le spacing d'un écran est du ressort de better-layout. L'architecture des composants est saine : hors périmètre components."
|
|
61
|
+
}
|
|
62
|
+
},
|
|
63
|
+
{
|
|
64
|
+
"id": "components-insufficient",
|
|
65
|
+
"skill": "better-components",
|
|
66
|
+
"kind": "insufficient",
|
|
67
|
+
"delivery_mode": "classique",
|
|
68
|
+
"artifact": "Une seule capture d'écran, sans code, sans Storybook, sans inventaire des composants ni accès au dépôt.",
|
|
69
|
+
"golden": {
|
|
70
|
+
"expected_findings": [],
|
|
71
|
+
"forbidden_findings": ["affirmer une duplication non prouvée", "conclure sur l'API sans la voir"],
|
|
72
|
+
"expected_verdict": "BLOCKED",
|
|
73
|
+
"should_refuse": true,
|
|
74
|
+
"note": "Sans code, Storybook ou inventaire, on ne peut pas auditer l'architecture. Demander plusieurs écrans comparables ou le code."
|
|
75
|
+
}
|
|
76
|
+
}
|
|
77
|
+
]
|