uix-skill

Que fait uix-skill ?

Construisez une UI qui semble conçue, pas générée. Décidez l'apparence une fois (DESIGN.md), construisez à partir de là, vérifiez le résultat avec des scripts.

Chemins : tous les chemins references/, data/ et scripts/ ci-dessous sont relatifs au dossier contenant ce SKILL.md. Exécutez les scripts depuis la racine du projet utilisateur avec node <ce dossier>/scripts/<nom>.mjs. Les scripts nécessitent Node 22.

Commandes

Commande	Rôle
/uix init	Lire le projet, poser 3 questions, proposer 3 directions, écrire et lint DESIGN.md.
/uix build	Construire une page, un écran ou un composant à partir de DESIGN.md, le vérifier, le corriger. Par défaut.
/uix audit	Exécuter les vérifications et faire un rapport. Ne rien éditer.
/uix polish	Corriger les principaux problèmes d'audit. Conserver la logique, les routes et le sens du texte.
/uix motion	Réviser ou ajouter une animation, après les 4 questions.

Le verbe peut arriver sous la forme /uix-skill <verbe>, uix <verbe>, ou comme une demande directe ("fais la page des paramètres", "audite cet écran"). Associer une demande directe au verbe le plus proche. Aucune correspondance claire : build.

Règles strictes

1. DESIGN.md existe : le lire en premier et construire à partir de lui. Sauter la phase d'orientation et de directions. Ne jamais inventer des couleurs, des polices ou des rayons qu'il ne définit pas.
2. Ne jamais signaler "terminé" avant que scripts/rules.mjs n'ait été exécuté et, pour les piles web, scripts/check.mjs aussi. Si une vérification ne peut pas s'exécuter (voir Vérifications), signaler non vérifié : <raison>.
3. Au maximum 2 cycles de correction après une vérification. Ensuite, signaler ce qui reste.
4. Images : ressources du projet, puis Openverse/Wikimedia avec crédits, puis art CSS/SVG. Jamais un espace réservé vide.
5. Outils gratuits uniquement. Pas d'API payantes, pas de clés.
6. Ne pas éditer de fichiers hors du périmètre UI de la requête. /uix audit ne modifie rien.
7. Charger uniquement les fichiers nommés dans les tableaux ci-dessous. Charger un fichier de pile, sauf shadcn et nuxt-ui : charger ce guide plus le guide du framework hôte.

Ordre d'exécution

1. Lire le projet : package.json, configuration, styles existants, DESIGN.md, public/ ou assets/.
2. Détecter la pile (tableau ci-dessous). Charger son guide.
3. Phase d'orientation. Poser les 3 questions ensemble, en un seul message : public cible, le job de l'écran, le ton. Piles mobiles : le ton demande aussi "animation calme ou vive ?" ; enregistrer la réponse comme le niveau d'animation dans DESIGN.md (references/design-md.md). Ignorer toute question déjà répondue par l'utilisateur ou le projet.
4. Proposer 3 directions issues de references/directions.md qui diffèrent clairement par le ton, la densité et la température des couleurs. Attendre le choix. Une direction que le propriétaire a déjà choisie au préalable ignore la proposition.
5. Écrire DESIGN.md (references/design-md.md) et le linter. Corriger toutes les erreurs de lint.
6. Choisir une structure dans references/layouts-web.md (marketing, contenu) ou references/layouts-app.md (écrans connectés).
7. Construire la première section. Texte réel, images réelles, tous les états des composants.
8. Vérifier (ci-dessous). Corriger les erreurs, puis les avertissements. Au maximum 2 cycles.
9. Faire le rapport.

Les étapes 3 à 5 appartiennent à init. build utilise un DESIGN.md existant ; s'il n'y en a pas, exécuter init d'abord.

Les systèmes de design existants l'emportent

• DESIGN.md existe : le lire, le linter, construire à partir de lui.
• Pas de DESIGN.md mais le projet a ses propres tokens ou thème (configuration Tailwind, variables CSS, fichier de thème) : /uix init écrit un DESIGN.md (à la racine du projet) à partir de ces tokens. Ne pas proposer de nouvelles directions sauf si l'utilisateur demande un nouveau look.
• Ni l'un ni l'autre : init complet.
• On entend par "tokens propres" des couleurs, polices ou espacements au-delà des valeurs par défaut du framework, dans un bloc @theme de Tailwind v4, une configuration Tailwind, des propriétés CSS personnalisées ou un fichier de thème de plateforme. Les valeurs par défaut --background/--foreground de create-next-app ne comptent pas.

Que charger

Ne rien charger d'autre jusqu'à ce que ce soit nécessaire.

Quand	Charger
Tout build, polish ou audit	references/anti-slop.md, references/components-a11y.md
init, ou toute écriture de DESIGN.md	references/design-md.md
init (proposition de directions)	references/directions.md, puis les lignes choisies de data/fonts.csv, data/palettes.csv, data/styles.csv
Page marketing, contenu, catalogue	references/layouts-web.md
Tableau de bord, tableau, formulaire, paramètres, authentification	references/layouts-app.md
Toute animation, ou /uix motion	references/motion.md
Build, polish ou audit mobile	references/mobile-foundations.md, references/mobile-patterns.md
Animation mobile	references/mobile-motion.md au lieu de references/motion.md
Mobile : visualiser l'application en toute sécurité, Expo Go vs une build de développement, vérifications tactiles et de balayage	references/mobile-testing.md
init pour une application mobile	data/mobile-styles.csv au lieu de data/styles.csv (les lignes choisies)
Tout emplacement d'image	references/images.md
Exemple de forme DESIGN.md	data/examples/ledger.md, field-notes.md ou harbor.md. Un seul.
Chaque tâche	Un references/stacks/<id>.md. Pour shadcn ou nuxt-ui, aussi le guide hôte (voir Détection de la pile).

Détection de la pile

La première correspondance gagne, de haut en bas. Aucune correspondance : html-tailwind. Correspondre aux noms de dépendances exacts (next, pas next-themes).

Signal	Id de pile
@nuxt/ui dans package.json	nuxt-ui
components.json avec shadcn, ou @/components/ui	shadcn
Fichier artisan ou laravel/framework dans composer.json	laravel
nuxt dans package.json	nuxtjs
next dans package.json	nextjs
@angular/core ou angular.json	angular
astro dans package.json ou astro.config.*	astro
svelte ou @sveltejs/kit	svelte
vue dans package.json	vue
three dans package.json	threejs
react-native ou expo dans package.json	react-native
react dans package.json	react
pubspec.yaml	flutter
build.gradle(.kts) avec Compose (androidx.compose)	jetpack-compose
*.xcodeproj ou Package.swift avec SwiftUI	swiftui
*.csproj avec Avalonia	avalonia
*.csproj avec Uno. ou Uno.WinUI	uno
*.csproj avec Microsoft.WindowsAppSDK	winui
*.csproj avec <UseWPF>true</UseWPF>	wpf
*.csproj avec TargetPlatformIdentifier UAP ou Microsoft.NETCore.UniversalWindowsPlatform	uwp
pom.xml ou build.gradle avec javafx	javafx
aucun des ci-dessus	html-tailwind

Ids web : angular, astro, html-tailwind, laravel, nextjs, nuxt-ui, nuxtjs, react, shadcn, svelte, threejs, vue. Les autres sont natifs. "Pile mobile" signifie react-native, flutter, swiftui ou jetpack-compose. Leurs requêtes chargent également les lignes mobiles de "Que charger". La pile la plus spécifique gagne : nextjs sur react, react-native sur react, laravel sur son frontend JS. Les piles de couche composant chargent deux guides : shadcn plus le guide hôte (nextjs, react, astro, laravel, ... détecté par ce tableau avec la ligne shadcn ignorée), et nuxt-ui plus nuxtjs. Tous les autres projets en chargent un.

Vérifications

Depuis la racine du projet utilisateur. Remplacez <skill> par le dossier contenant ce SKILL.md.

node <skill>/scripts/rules.mjs [--design DESIGN.md] <chemin...>
node <skill>/scripts/check.mjs <url|fichier> [--widths 375,768,1280] [--out .uix/shots] [--themes attr=v1,v2]
node <skill>/scripts/images.mjs "<requête>" [--count 6]

• Les trois affichent du JSON. rules.mjs affiche {findings, skipped} : les fichiers minifiés, de plus de 1 Mo ou illisibles atterrissent dans skipped avec une raison et ne sont pas une erreur. check.mjs affiche {shots, findings, notes} ; lire notes (par exemple un délai d'attente de chargement détecté tôt, ou une capture d'écran qui a échoué). Sortie 0 : propre. Sortie 1 : erreurs de constatations (rules.mjs, check.mjs). Sortie 2 : problème d'utilisation ou d'environnement (les trois). images.mjs ne sort que 0 ou 2.
• La sortie 2 n'est jamais un résultat propre et ne compte pas comme un cycle de correction. Si check.mjs ne peut pas atteindre la page et que le projet a un script de développement évident (npm run dev etc.), le lancer une fois en arrière-plan et réessayer. Sinon, demander à l'utilisateur. Nommer ce qui manque (Chrome, Node 22, un serveur qui ne tourne pas).
• Si la vérification ne peut toujours pas s'exécuter, le rapport indique non vérifié : <raison>.
• Piles web : exécuter rules.mjs sur la source, puis check.mjs sur l'URL du serveur de développement ou le fichier généré. Les largeurs sont 375, 768 et 1280. Les captures d'écran atterrissent dans .uix/shots : <w>.png est la page entière, et <w>-<n>.png sont des tuiles d'au plus 1600 px. Regarder les tuiles, pas la capture complète ; elle rétrécit à l'illisible. check.mjs fait d'abord défiler la page pour que le contenu au défilement apparaisse.
• Lorsque le projet définit plusieurs thèmes ([data-theme], [data-skin], .dark), les passer avec --themes, par exemple --themes data-skin=oatmeal,rose ou --themes class=dark. Chaque thème est sondé à la dernière largeur ; ses constatations portent theme.
• Les constatations de contraste sont groupées par paire de couleurs (count, sample, selectors). Corriger le token, pas chaque élément.
• React Native (Expo) : exécuter rules.mjs, puis node <skill>/scripts/check-mobile.mjs --app exp://127.0.0.1:<port> contre un serveur Metro en cours d'exécution ; ajouter --platform android pour les émulateurs Android (les indicateurs et le fichier de routes sont dans le guide de la pile). Il affiche {shots, findings, notes} et sort 0, 1 ou 2 comme check.mjs. Une note commençant par maestro missing: signifie que la hiérarchie et le flux n'ont pas été exécutés ; le signaler comme non vérifié : <raison>, pas comme une exécution réussie. Les captures atterrissent dans .uix/mobile-shots. Une constatation route-not-navigated est une erreur et jamais un résultat propre : la capture montre un autre écran. Boucle de correction : re-vérifier avec --only <routes> et une seule entrée --devices, pas la matrice complète.
• Autres piles mobiles : exécuter rules.mjs. Les applications iOS natives (SwiftUI) utilisent ensuite check-mobile.mjs --native (indicateurs dans le guide de la pile) ; en audit passer --out "$(mktemp -d)". Les autres utilisent la recette de capture d'écran manuelle dans le fichier de pile "Comment vérifier" (clair, sombre, texte xxxl). Aucun simulateur disponible : non vérifié : <raison>. La limite de 2 cycles s'applique.
• Autres piles natives : exécuter rules.mjs, puis la liste de contrôle manuelle dans le fichier de pile "Comment vérifier". Il n'y a pas de vérification navigateur.
• Corriger les constatations error avant warn. Un avertissement que vous conservez nécessite une raison d'une ligne.
• Boucle de correction : vérifier, corriger, revérifier. Au maximum 2 cycles. Ensuite, arrêter et faire le rapport.
• Les identifiants de règle et leurs corrections sont dans references/anti-slop.md. Il liste également les règles de jugement qu'aucun script ne détecte ; les examiner vous-même.

Contrats de commande

init

1. Lire le projet, détecter la pile, charger son guide.
2. Tokens existants ou DESIGN.md : voir "Les systèmes de design existants l'emportent".
3. Sinon, poser les 3 questions, proposer 3 directions clairement différentes, attendre. Toute pile : détecter la langue du contenu (lang, fichiers i18n, texte) et ne sélectionner que les lignes de data/fonts.csv dont la colonne scripts la couvre.
4. Écrire DESIGN.md. Linter : npx --yes @google/[email protected] lint DESIGN.md. Corriger les erreurs.
5. Signaler la direction choisie, les fichiers écrits et le résultat du lint.

build

1. Lire DESIGN.md, le guide de pile et le fichier de mise en page.
2. Choisir une structure. Dire laquelle et pourquoi en une ligne.
3. Construire complètement la première section. Puis le reste.
4. Exécuter les vérifications. Corriger en au maximum 2 cycles.
5. Signaler.

audit

1. Détecter la pile et charger son guide.
2. Exécuter les vérifications. Examiner les règles de jugement. Passer --out "$(mktemp -d)" à check.mjs et aussi à check-mobile.mjs, pour que l'audit n'écrive rien dans le projet.
3. Produire un tableau. Ne rien éditer.

Avant	Après	Pourquoi
ce qui est maintenant	ce qui devrait être	l'id de règle ou la raison

polish

1. Détecter la pile et charger son guide.
2. Exécuter d'abord un audit.
3. Corriger les principaux problèmes, d'abord les erreurs. Ne pas changer la logique, les routes ou le sens du texte.
4. Réexécuter les vérifications. Au maximum 2 cycles. Signaler.

motion

1. Charger references/motion.md (piles mobiles : references/mobile-motion.md). Répondre par écrit à ses 4 questions pour chaque animation : nécessaire, ce qu'elle communique, quel easing, combien de temps.
2. Abandonner toute animation sans réponse claire. Ajouter la gestion de prefers-reduced-motion (le guide de pile nomme l'équivalent natif).
3. Produire un tableau Avant / Après / Pourquoi. Appliquer le changement uniquement lorsque l'utilisateur a demandé d'ajouter ou de corriger une animation, pas pour la réviser.

Rapport

Terminer chaque exécution avec :

• Ce qui a changé (fichiers).
• Les constatations qui demeurent, chacune avec l'id de règle et la raison.
• Les chemins des captures d'écran et des tuiles dans .uix/shots (web), les chemins des captures dans .uix/mobile-shots (mobile) ou les vérifications manuelles effectuées (autres natifs).
• Les crédits d'image ajoutés.