designwithai-mcp 0.1.0

package/skills/better-consistency/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: better-consistency
+description: Détecte les divergences accidentelles de termes, composants, comportements, états et règles visuelles à l'échelle du produit, et définit une règle canonique par pattern sans uniformiser aveuglément.
+version: 1.0
+category: system-expert
+role: System expert
+execution_mode: cross-product-audit
+supports: [ai-builder, traditional, hybrid]
+inputs: [code, storybook, figma, url, inventory]
+outputs: [divergence-map, canonical-registry, exceptions, normalization-plan]
+relays: [better-components, better-writing, better-states, better-layout]
+---
+
+# /better-consistency
+
+**Rôle** : System expert · **Mode par défaut** : audit transversal.
+
+Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `CONS`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
+
+## Mission
+
+Rendre le produit prévisible sans l'uniformiser aveuglément. Le skill distingue les incohérences accidentelles des variations justifiées par le contexte, puis définit une règle canonique par pattern.
+
+## Déclenchement
+
+Produit construit rapidement, plusieurs contributeurs, routes hétérogènes, migrations partielles ou duplication issue d'un AI Builder.
+
+- **Entrées minimales** : plusieurs écrans, routes ou composants comparables. Une capture isolée ne suffit pas.
+
+## Dimensions analysées
+
+| Dimension | Exemples de divergences |
+|---|---|
+| **Terminologie** | Créer/Ajouter/Nouveau pour la même action ; projet/espace/workspace pour le même objet. |
+| **Composants** | Plusieurs boutons, modals, cards, inputs ou tables pour le même usage. |
+| **Comportement** | Retour, sauvegarde, filtres, fermeture, confirmation ou navigation différents selon les routes. |
+| **États** | Loading, empty, error et success traités différemment sans raison. |
+| **Visuel** | Spacing, radius, ombres, couleurs, icônes, typographies ou densité divergents. |
+| **Données** | Formats de date, nombre, devise, unités, labels et ordre de colonnes. |
+| **Accessibilité** | Focus, labels, noms accessibles et clavier variables selon les implémentations. |
+
+## Séquence d'analyse obligatoire
+
+1. **Définir l'échantillon.** Routes, écrans, composants, périodes et plateformes comparés.
+2. **Créer la matrice des patterns.** Lister chaque besoin récurrent et les implémentations existantes.
+3. **Identifier les divergences.** Comparer visuel, texte, comportement, états, données et accessibilité.
+4. **Qualifier l'intention.** Variation légitime, expérimentation, legacy, contrainte locale ou incohérence accidentelle.
+5. **Choisir le canonique.** S'appuyer sur source de vérité, fréquence, qualité, accessibilité, maintenabilité et contexte.
+6. **Définir les exceptions.** Une exception doit avoir une raison, un owner et une durée ou condition de réévaluation.
+7. **Planifier la normalisation.** Corriger d'abord les fondations et composants les plus diffusés.
+8. **Prévenir la récidive.** Tokens, composants, documentation, lint, tests visuels ou règles de contribution.
+
+## Règles de décision
+
+- **Même besoin, même pattern par défaut.** La variation doit être justifiée par une différence de tâche ou de contexte.
+- **Canonique ne signifie pas le plus ancien.** Choisir la meilleure implémentation, puis migrer les autres.
+- **Ne pas uniformiser les cas différents.** Une action destructive ne doit pas reprendre le pattern d'une action secondaire simplement pour être cohérente.
+- **Corriger à la racine.** Quand une divergence vient d'un token ou composant, ne pas patcher chaque écran.
+- **Stabiliser le vocabulaire.** Un terme produit doit posséder une définition et des contextes autorisés.
+- **Mesurer le rayon d'impact.** Prioriser les incohérences fréquentes et visibles sur les parcours principaux.
+
+## Adaptation au mode de delivery
+
+- **AI Builder.** Comparer les routes générées à des moments différents, les composants copiés, les styles locaux, les termes modifiés par prompt et les patterns recréés.
+- **Classique.** Comparer produit, Figma, Design System, documentation et Storybook. Identifier les versions obsolètes encore consommées.
+- **Hybride.** Créer un registre de décisions canoniques par couche et désigner la source de vérité après migration.
+
+## Anti-patterns à refuser
+
+- Uniformiser tout écart sans vérifier son intention.
+- Choisir comme canonique la version la plus fréquente même si elle est défectueuse.
+- Créer un nouveau composant « final » sans plan de retrait des anciens.
+- Se limiter aux couleurs et espacements en ignorant le comportement et le vocabulaire.
+- Produire un audit sur une capture unique.
+- Accepter des exceptions sans owner ni justification.
+
+## Contrat de sortie exact
+
+```
+# Échantillon
+- Routes / écrans / composants
+- Sources comparées
+- Limites
+
+# Matrice des patterns
+Pattern | Implémentations | Différences | Intention | Canonique | Exceptions
+
+# Problèmes priorisés
+CONS-XX | Sévérité | Pattern | Localisations | Preuve | Impact | Décision | Critères | Confiance
+
+# Registre canonique
+- Terme
+- Composant
+- Comportement
+- État
+- Format de données
+- Source de vérité
+
+# Plan de normalisation
+Lot | Racine | Consommateurs | Migration | Test | Dépréciation
+
+# Prévention
+- Tokens
+- Documentation
+- Tests / lint
+- Règles de contribution
+```
+
+## Critères de qualité du skill
+
+- Le skill compare plusieurs occurrences du même besoin.
+- Chaque variation est qualifiée comme légitime, temporaire ou accidentelle.
+- Le canonique est choisi selon des critères explicites.
+- Les corrections ciblent la racine lorsque possible.
+- Les exceptions sont documentées et gouvernées.
+
+## Exemple d'invocation
+
+```
+/better-consistency
+Échantillon: onboarding, dashboard, settings, billing
+Objectif: unifier actions, modals, empty states et vocabulaire
+Sources: production + Storybook
+Mode: audit transversal
+```

package/skills/better-consistency/evals/cases.json

@@ -0,0 +1,77 @@
+[
+  {
+    "id": "consistency-conformant-product",
+    "skill": "better-consistency",
+    "kind": "conformant",
+    "delivery_mode": "classique",
+    "artifact": "Onboarding, dashboard et settings comparés. Même pattern de confirmation partout, même vocabulaire (« projet » partout), mêmes traitements de loading/empty/error, formats de date identiques. Les rares variations sont justifiées par la tâche (une action destructive a un pattern distinct, à raison).",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["uniformiser une variation justifiée", "auditer un défaut d'un seul écran"],
+      "expected_verdict": "PASS",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "consistency-obvious-divergence",
+    "skill": "better-consistency",
+    "kind": "obvious-defect",
+    "delivery_mode": "ai-builder",
+    "artifact": "Produit construit vite, plusieurs routes générées à des moments différents. La même confirmation de suppression utilise trois modals différentes selon l'écran. La même action est nommée « Créer », « Ajouter » et « Nouveau ». Les dates sont au format JJ/MM/AAAA à un endroit, MM/DD/YYYY ailleurs. Les empty states sont traités différemment sans raison.",
+    "golden": {
+      "expected_findings": [
+        "trois composants de modal différents pour la même confirmation",
+        "terminologie divergente Créer / Ajouter / Nouveau pour la même action",
+        "formats de date incohérents entre écrans",
+        "empty states traités différemment sans raison"
+      ],
+      "forbidden_findings": ["revoir la stratégie produit", "auditer l'accessibilité d'un écran"],
+      "expected_verdict": "FAIL",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "consistency-subtle-drift",
+    "skill": "better-consistency",
+    "kind": "subtle-defect",
+    "delivery_mode": "hybride",
+    "artifact": "Deux parcours proches. Le comportement de « retour » diffère subtilement : sur l'un il sauvegarde le brouillon, sur l'autre il l'abandonne sans avertissement — divergence accidentelle, pas une décision. Un même terme, « espace », désigne un workspace sur une route et un projet sur une autre.",
+    "golden": {
+      "expected_findings": [
+        "comportement de retour divergent, sauvegarde vs abandon sans raison",
+        "même terme espace utilisé pour deux objets différents"
+      ],
+      "forbidden_findings": ["uniformiser les cas réellement différents", "refonte visuelle"],
+      "expected_verdict": "PASS WITH FIXES",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "consistency-out-of-scope-single",
+    "skill": "better-consistency",
+    "kind": "out-of-scope",
+    "delivery_mode": "classique",
+    "artifact": "Trois écrans parfaitement cohérents entre eux (vocabulaire, composants, comportements alignés). Le seul défaut est isolé à un écran : un bouton icône-seule sans nom accessible.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["bouton icône-seule sans nom accessible", "auditer l'accessibilité de l'écran"],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "Un défaut isolé d'un seul écran relève des skills experts (ici better-accessibility). La cohérence transversale est bonne : hors périmètre consistency."
+    }
+  },
+  {
+    "id": "consistency-insufficient",
+    "skill": "better-consistency",
+    "kind": "insufficient",
+    "delivery_mode": "classique",
+    "artifact": "Une capture d'un seul écran, sans autre route, écran ni composant comparable.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["conclure à une incohérence sur un seul écran"],
+      "expected_verdict": "BLOCKED",
+      "should_refuse": true,
+      "note": "La cohérence se mesure entre plusieurs occurrences. Une capture isolée ne suffit pas : demander plusieurs écrans ou routes."
+    }
+  }
+]

package/skills/better-forms/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: better-forms
+description: Améliore la collecte de données, la compréhension, la validation, la progression et la récupération dans les formulaires, en traitant le formulaire comme un parcours complet.
+version: 1.0
+category: ux-expert
+role: UX expert
+execution_mode: field-by-field-audit
+supports: [ai-builder, traditional, hybrid]
+inputs: [image, prototype, code, url]
+outputs: [field-audit, target-structure, validation-rules, states, acceptance-criteria]
+relays: [better-writing, better-states, better-accessibility, better-responsive]
+---
+
+# /better-forms
+
+**Rôle** : UX expert · **Mode par défaut** : audit champ par champ.
+
+Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `FORM`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
+
+## Mission
+
+Réduire l'effort de saisie et les erreurs tout en collectant uniquement les données réellement nécessaires. Le skill traite le formulaire comme un parcours complet, pas comme une suite de champs.
+
+## Déclenchement
+
+Formulaire long, abandons, erreurs fréquentes, champs ambigus, validation tardive, multi-step ou données sensibles.
+
+- **Entrées minimales** : capture, prototype ou code du formulaire avec objectif, audience et contraintes de données.
+- **N'analyse pas** la légitimité juridique de la collecte ou le modèle de données complet. Il signale les questions de conformité ou minimisation à valider.
+- **Principe** : chaque champ doit avoir une raison produit ou opérationnelle explicite.
+
+## Séquence d'analyse obligatoire
+
+1. **Définir le résultat.** Création de compte, paiement, configuration, recherche, publication, demande ou autre objectif.
+2. **Inventorier les données.** Champ, source, caractère obligatoire, usage, sensibilité, format, dépendance et possibilité de préremplissage.
+3. **Supprimer ou différer.** Identifier les champs non nécessaires à cette étape, déjà connus ou collectables plus tard.
+4. **Structurer.** Ordre logique, groupes, étapes, progression, dépendances et visibilité conditionnelle.
+5. **Choisir les contrôles.** Type natif ou composant approprié, options, recherche, date, montant, téléphone, upload, adresse ou autre donnée.
+6. **Définir la validation.** Moment, message, emplacement, format accepté, serveur, conflit, doublon et correction.
+7. **Définir la persistance.** Autosave, brouillon, retour arrière, refresh, reconnexion et reprise après erreur.
+8. **Tester la soumission.** Double clic, latence, échec, succès partiel, confirmation et prochaine étape.
+
+## Règles de conception
+
+- **Label toujours explicite.** Le placeholder ne remplace pas le label et disparaît pendant la saisie.
+- **Aide au bon moment.** Placer format, exemple ou contrainte avant l'erreur lorsque l'utilisateur peut l'anticiper.
+- **Validation proportionnée.** Valider tôt ce qui peut être corrigé immédiatement, sans interrompre chaque frappe ni afficher des erreurs prématurées.
+- **Erreur proche et résumée.** Associer l'erreur au champ ; pour les longs formulaires, proposer un résumé navigable.
+- **Préremplir sans surprendre.** Afficher les valeurs connues, permettre la modification et expliquer les données sensibles.
+- **Préserver le travail.** Ne jamais perdre une saisie importante après erreur réseau, expiration ou navigation accidentelle sans avertissement.
+- **Un seul choix principal par étape.** La soumission doit être claire ; les actions secondaires ne doivent pas concurrencer.
+- **Mobile réel.** Clavier adapté, autocomplete, champs de date et montant utilisables, CTA non masqué.
+
+## Audit champ par champ
+
+| Dimension | Questions |
+|---|---|
+| **Nécessité** | Pourquoi ce champ est-il demandé maintenant ? Peut-il être supprimé, prérempli ou différé ? |
+| **Compréhension** | Le label et l'aide permettent-ils de savoir quoi saisir et pourquoi ? |
+| **Contrôle** | Le type de champ correspond-il à la donnée et aux usages mobile/clavier ? |
+| **Validation** | Quand l'erreur apparaît-elle ? Est-elle précise et corrigeable ? |
+| **Accessibilité** | Nom, relation label/erreur, ordre, focus, annonce et cible interactive. |
+| **Persistance** | La valeur est-elle conservée lors des transitions et erreurs ? |
+| **Confidentialité** | La sensibilité est-elle signalée et la collecte minimisée ? |
+
+## Adaptation au mode de delivery
+
+- **AI Builder.** Contrôler les validations uniquement côté client, les mutations Supabase, les erreurs silencieuses, les données non persistées, les valeurs par défaut dangereuses et les schémas divergents.
+- **Classique.** Aligner le formulaire avec les contrats API, composants du Design System, schémas de validation partagés et tracking d'abandon.
+- **Hybride.** Identifier où vivent la validation, la normalisation et les règles métier afin d'éviter les doublons contradictoires.
+
+## Anti-patterns à refuser
+
+- Demander toutes les informations « au cas où ».
+- Utiliser le placeholder comme label.
+- Afficher les erreurs seulement après une soumission longue.
+- Réinitialiser le formulaire après une erreur serveur.
+- Utiliser un select pour une liste très longue sans recherche.
+- Masquer des champs obligatoires dans des sections repliées sans signalement.
+
+## Contrat de sortie exact
+
+```
+# Objectif du formulaire
+- Résultat utilisateur
+- Données réellement nécessaires
+- Contraintes et risques
+
+# Audit champ par champ
+FORM-XX | Champ | Nécessité | Problème | Sévérité | Correction | Validation | Critères | Confiance
+
+# Structure cible
+- Groupes
+- Ordre
+- Étapes
+- Champs conditionnels
+- Préremplissage
+
+# Règles de validation
+- Client
+- Serveur
+- Messages
+- Focus et résumé d'erreurs
+
+# États et persistance
+- Loading
+- Draft / autosave
+- Error
+- Success
+- Reprise
+
+# Plan de mesure
+- Début
+- Abandon par étape
+- Erreurs fréquentes
+- Soumission réussie
+```
+
+## Critères de qualité du skill
+
+- Chaque champ possède une justification ou une recommandation de suppression/différé.
+- Les règles de validation sont compatibles avec le backend réel.
+- Les données saisies sont préservées lors des erreurs récupérables.
+- Le formulaire est utilisable au clavier et sur mobile.
+- Les messages d'erreur indiquent comment corriger.
+
+## Exemple d'invocation
+
+```
+/better-forms
+Artefact: formulaire de création d'établissement, 18 champs
+Audience: gérant de restaurant sur mobile
+Objectif: réduire l'abandon sans perdre les données nécessaires à la facturation
+Mode: audit + structure cible
+```

package/skills/better-forms/evals/cases.json

@@ -0,0 +1,78 @@
+[
+  {
+    "id": "forms-conformant-signup",
+    "skill": "better-forms",
+    "kind": "conformant",
+    "delivery_mode": "classique",
+    "artifact": "Création de compte. Trois champs seulement (email, mot de passe, nom), chacun justifié. Labels explicites au-dessus des champs. Validation au blur, message précis à côté du champ. Autosave du brouillon. Clavier adapté sur mobile (email → clavier email). Le travail est préservé après une erreur réseau.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["juger la légitimité juridique de la collecte", "revoir le layout de la page"],
+      "expected_verdict": "PASS",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "forms-obvious-onboarding",
+    "skill": "better-forms",
+    "kind": "obvious-defect",
+    "delivery_mode": "ai-builder",
+    "artifact": "Formulaire d'inscription de 18 champs, dont beaucoup « au cas où ». Les labels sont des placeholders qui disparaissent à la saisie. La validation n'apparaît qu'après une soumission longue. En cas d'erreur serveur, le formulaire est réinitialisé. Un pays est choisi via un select de 200 entrées sans recherche.",
+    "golden": {
+      "expected_findings": [
+        "champs demandés au cas où, sans nécessité, à supprimer ou différer",
+        "placeholder utilisé comme label, disparaît à la saisie",
+        "validation seulement après une soumission longue",
+        "formulaire réinitialisé après une erreur serveur, travail perdu",
+        "select très long sans recherche"
+      ],
+      "forbidden_findings": ["revoir la grille", "réécrire la stratégie produit"],
+      "expected_verdict": "FAIL",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "forms-subtle-address",
+    "skill": "better-forms",
+    "kind": "subtle-defect",
+    "delivery_mode": "classique",
+    "artifact": "Formulaire de facturation, globalement soigné. Deux écarts : un champ obligatoire (TVA intracommunautaire) est masqué dans une section repliée sans signalement ; et la validation du code postal est déclenchée à chaque frappe, affichant une erreur prématurée avant que le champ soit complet.",
+    "golden": {
+      "expected_findings": [
+        "champ obligatoire masqué dans une section repliée sans signalement",
+        "validation à chaque frappe, erreur prématurée avant la fin de la saisie"
+      ],
+      "forbidden_findings": ["refonte complète du formulaire", "changer la palette"],
+      "expected_verdict": "PASS WITH FIXES",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "forms-out-of-scope-layout",
+    "skill": "better-forms",
+    "kind": "out-of-scope",
+    "delivery_mode": "classique",
+    "artifact": "Formulaire de recherche avancée. Les champs, la validation, la persistance et la progression sont tous corrects. Le seul souci est visuel : le formulaire est collé au bord de la page et manque de marges, avec un rythme vertical irrégulier.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["marges insuffisantes", "rythme vertical irrégulier", "revoir le layout"],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "Spacing et rythme = better-layout. La logique de saisie est correcte : hors périmètre forms."
+    }
+  },
+  {
+    "id": "forms-insufficient",
+    "skill": "better-forms",
+    "kind": "insufficient",
+    "delivery_mode": "classique",
+    "artifact": "« Améliore mon formulaire. » Aucun champ listé, aucun objectif, aucune audience, aucune contrainte de données.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": [],
+      "expected_verdict": "BLOCKED",
+      "should_refuse": true,
+      "note": "Sans les champs ni l'objectif, on ne peut pas juger la nécessité des données. Demander le résultat visé et l'inventaire des champs."
+    }
+  }
+]

package/skills/better-interface/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: better-interface
+description: Orchestrateur de revue d'interface — sélectionne les experts nécessaires, agrège leurs diagnostics et produit une vision priorisée sans mélanger leurs périmètres.
+version: 1.0
+category: orchestrator
+role: Orchestrator
+execution_mode: multi-skill-diagnostic
+supports: [ai-builder, traditional, hybrid]
+inputs: [image, url, code, figma, prototype]
+outputs: [orchestration-plan, consolidated-diagnostic, arbitrations, correction-plan, global-verdict]
+orchestrates: [better-layout, better-accessibility, better-writing, better-responsive, better-states, better-forms, better-components, better-consistency, better-navigation]
+---
+
+# /better-interface
+
+**Rôle** : Orchestrator · **Mode par défaut** : diagnostic multi-skill.
+
+Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `UI`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
+
+## Mission
+
+Fournir une revue holistique sans créer un « super prompt » vague. L'orchestrateur choisit les experts utiles, leur transmet le contexte, déduplique les résultats et arbitre les conflits. Il ne remplace pas leur analyse spécialisée.
+
+## Déclenchement
+
+Revue globale d'un écran, d'un flow ou d'une feature sans savoir quel skill spécialisé appeler.
+
+- **Entrées minimales** : artefact, objectif utilisateur, mode de delivery et périmètre de revue.
+
+## Responsabilités de l'orchestrateur
+
+- **Qualifier la demande.** Identifier artefact, objectif, parcours, audience, mode de delivery, source de vérité, contraintes et niveau de profondeur.
+- **Sélectionner les experts.** Appeler uniquement les experts nécessaires. Une page sans formulaire ne déclenche pas `better-forms`.
+- **Distinguer l'écran du chemin.** Huit experts jugent un écran ; `better-navigation` est le seul à juger ce qui se passe ENTRE les écrans. Il ne s'active que si le périmètre en montre plusieurs et leurs liens — sur un écran isolé, l'orchestrateur ne l'appelle pas et le dit dans les skills exclus.
+- **Préparer le contexte commun.** Fournir à chaque expert les mêmes hypothèses, viewports, contraintes et exclusions.
+- **Agréger sans écraser.** Conserver l'origine de chaque problème et les preuves spécifiques.
+- **Dédupliquer.** Fusionner les constats identiques tout en conservant les impacts complémentaires.
+- **Arbitrer.** Résoudre les recommandations incompatibles selon priorité utilisateur, source de vérité, accessibilité, cohérence et coût de régression.
+- **Planifier.** Ordonner les correctifs par racine, dépendance et risque plutôt que par skill.
+
+## Matrice de sélection
+
+| Signal observé | Skill principal | Skills complémentaires |
+|---|---|---|
+| Structure confuse, alignements, densité | `better-layout` | `better-responsive`, `better-consistency` |
+| Barrières clavier, contraste, labels | `better-accessibility` | `better-components`, `better-forms` |
+| Textes vagues, erreurs, terminologie | `better-writing` | `better-states`, `better-consistency` |
+| Débordements, tablette, mobile | `better-responsive` | `better-layout`, `better-components` |
+| Loading, empty, error, permissions | `better-states` | `better-writing`, `better-accessibility` |
+| Saisie, validation, progression | `better-forms` | `better-writing`, `better-states` |
+| Duplication, props, variants | `better-components` | `better-consistency`, `better-accessibility` |
+| Routes hétérogènes, patterns divergents | `better-consistency` | `better-components`, `better-writing` |
+| Rangement, étiquettes de menu, profondeur, écrans qu'on ne trouve pas | `better-navigation` | `better-writing`, `better-consistency` |
+
+## Séquence d'orchestration
+
+1. **Cadrer.** Résumer la tâche utilisateur et le périmètre. Signaler immédiatement les accès manquants.
+2. **Échantillonner.** Choisir les écrans, états, viewports et composants nécessaires. Ne pas prétendre auditer tout un produit à partir d'un écran. Noter si le périmètre est complet : `better-navigation` en dépend pour déclarer un orphelin.
+3. **Sélectionner.** Nommer les skills activés et ceux volontairement exclus.
+4. **Exécuter les fondations.** Commencer par composants, cohérence et structure lorsque les défauts sont systémiques. Quand le périmètre couvre un parcours, exécuter `better-navigation` AVANT les dimensions locales : un écran qu'on n'atteint pas ne mérite pas qu'on discute sa mise en page.
+5. **Exécuter les dimensions locales.** Layout, writing, forms, states, responsive et accessibilité selon le besoin.
+6. **Consolider.** Regrouper les problèmes par cause racine : token, composant, pattern, écran, contenu ou backend.
+7. **Arbitrer les conflits.** Documenter la décision et le compromis. Ne pas masquer les désaccords.
+8. **Produire le plan.** Lot 1 bloquants, lot 2 fondations, lot 3 parcours, lot 4 polish et prévention.
+
+## Règles d'arbitrage
+
+- **Tâche utilisateur avant préférence esthétique.** Une correction ne doit pas réduire la compréhension ou l'accès pour gagner en minimalisme.
+- **Fondation avant occurrence.** Corriger le composant ou token quand plusieurs problèmes partagent la même cause.
+- **Accessibilité comme contrainte.** Une recommandation de layout ou writing ne peut pas supprimer un nom, un focus ou une information nécessaire.
+- **Source canonique explicite.** En cas de divergence Figma / code / sortie du générateur, décider ce qui fait foi avant la correction.
+- **Moindre régression.** Choisir le lot le plus petit capable d'améliorer réellement la qualité.
+- **Confiance visible.** Une recommandation issue d'une capture ne doit pas être présentée comme un défaut de code confirmé.
+
+## Modes d'exécution
+
+| Mode | Comportement |
+|---|---|
+| **Quick review** | 2 à 4 skills, parcours principal, problèmes bloquants/majeurs, pas de couverture exhaustive. |
+| **Deep review** | Tous les skills pertinents, états, viewports, code et composants, registre complet. |
+| **Pre-release gate** | Focus bloquants, accessibilité, états, responsive, forms et non-régression. |
+| **Repair plan** | Aucun nouvel audit large ; transforme un diagnostic existant en lots de correction. |
+| **Patch supervision** | Autorise des modifications ciblées, puis réexécute les skills concernés pour vérifier. |
+
+## Anti-patterns à refuser
+
+- Exécuter tous les skills par défaut, même hors contexte.
+- Produire une liste unique sans indiquer l'expert ou la cause.
+- Fusionner deux problèmes proches au point de perdre les critères spécifiques.
+- Faire une refonte complète avant de corriger les bloquants.
+- Masquer les conflits entre recommandations.
+- Déclarer l'ensemble du produit validé à partir d'un échantillon limité.
+
+## Contrat de sortie exact
+
+```
+# Cadrage
+- Artefact et tâche utilisateur
+- Périmètre / échantillon
+- Source de vérité
+- Mode de delivery
+- Niveau de profondeur
+
+# Plan d'orchestration
+Skill | Motif d'activation | Artefacts transmis | Limites
+
+# Diagnostic consolidé
+UI-XX | Cause racine | Skills sources | Sévérité | Localisations | Preuves | Impact | Correction | Critères | Confiance
+
+# Arbitrages
+Conflit | Options | Décision | Compromis | Validation
+
+# Plan de correction
+Lot 1 - Blocants
+Lot 2 - Fondations
+Lot 3 - Parcours et états
+Lot 4 - Polish et prévention
+
+# Verdict
+- PASS | PASS WITH FIXES | FAIL | BLOCKED
+- Couverture réelle
+- Risques résiduels
+```
+
+## Critères de qualité du skill
+
+- Les skills activés sont justifiés par le contenu de l'artefact.
+- Chaque problème conserve ses preuves et son origine.
+- Les doublons sont fusionnés par cause racine, pas simplement supprimés.
+- Les conflits sont arbitrés explicitement.
+- Le verdict indique clairement la couverture et les limites.
+
+## Exemple d'invocation
+
+```
+/better-interface
+Artefact: nouveau parcours de création d'alerte
+Mode: deep review
+Delivery: Lovable + Supabase
+Sources: production, repo, captures mobile/desktop
+Objectif: décider si la feature est prête pour la bêta
+Exclusions: stratégie produit et pricing
+```

package/skills/better-interface/evals/cases.json

@@ -0,0 +1,80 @@
+[
+  {
+    "id": "interface-single-dimension",
+    "skill": "better-interface",
+    "kind": "conformant",
+    "delivery_mode": "classique",
+    "artifact": "Un écran statique dont le seul problème est la structure visuelle (grille, spacing, hiérarchie). Pas de formulaire, pas d'état complexe, pas de tableau. On demande une revue d'interface.",
+    "golden": {
+      "expected_findings": [
+        "structure visuelle de l'écran : grille, spacing et hiérarchie, relevé par better-layout"
+      ],
+      "forbidden_findings": ["exécuter tous les skills par défaut", "produire une liste sans indiquer l'expert ou la cause"],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "L'orchestrateur doit sélectionner uniquement les experts utiles (ici better-layout), pas tout lancer : better-forms et better-states n'ont rien à auditer sur cet écran. Les findings attendus portent sur la structure visuelle ; un problème de formulaire ou d'état signalé ici en sévérité majeure ou plus est un faux positif."
+    }
+  },
+  {
+    "id": "interface-multi-expert",
+    "skill": "better-interface",
+    "kind": "obvious-defect",
+    "delivery_mode": "ai-builder",
+    "artifact": "Un parcours de création d'alerte avec plusieurs problèmes : structure confuse, boutons icône-seule sans nom, et états d'erreur génériques. Aucun formulaire de saisie complexe.",
+    "golden": {
+      "expected_findings": [
+        "sélectionne better-layout, better-accessibility et better-states",
+        "consolide les problèmes par cause racine plutôt que par skill",
+        "arbitre en gardant l'accessibilité comme contrainte, pas sacrifiée à l'esthétique",
+        "produit un plan par lots, bloquants d'abord"
+      ],
+      "forbidden_findings": ["exécuter better-forms alors qu'il n'y a pas de formulaire", "fusionner deux problèmes distincts au point de perdre leurs critères"],
+      "expected_verdict": "FAIL",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "interface-shared-root-cause",
+    "skill": "better-interface",
+    "kind": "subtle-defect",
+    "delivery_mode": "hybride",
+    "artifact": "Deux écrans où un même token de spacing mal défini produit à la fois un défaut de layout et une incohérence entre les écrans. Deux experts (better-layout, better-consistency) signaleraient chacun un symptôme.",
+    "golden": {
+      "expected_findings": [
+        "consolide les deux symptômes en une seule cause racine, le token de spacing",
+        "corrige la fondation avant les occurrences"
+      ],
+      "forbidden_findings": ["créer deux tickets distincts pour la même cause racine", "masquer le conflit entre recommandations"],
+      "expected_verdict": "PASS WITH FIXES",
+      "should_refuse": false
+    }
+  },
+  {
+    "id": "interface-out-of-scope-strategy",
+    "skill": "better-interface",
+    "kind": "out-of-scope",
+    "delivery_mode": "classique",
+    "artifact": "On demande à l'orchestrateur de trancher si la proposition de valeur du produit est la bonne et quel pricing adopter.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["se prononcer sur la proposition de valeur", "recommander un pricing"],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "La stratégie produit et le pricing sont hors du périmètre de la revue d'interface. L'orchestrateur reste sur l'interface."
+    }
+  },
+  {
+    "id": "interface-insufficient",
+    "skill": "better-interface",
+    "kind": "insufficient",
+    "delivery_mode": "classique",
+    "artifact": "« Fais une revue complète de mon produit. » Aucun écran, aucun artefact, aucun périmètre fourni.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": ["déclarer le produit validé à partir de rien"],
+      "expected_verdict": "BLOCKED",
+      "should_refuse": true,
+      "note": "Sans artefact ni périmètre, l'orchestrateur ne peut pas cadrer. Il doit signaler les accès manquants avant toute revue."
+    }
+  }
+]