Prototype UI/UX
Concevoir des interfaces produit autour de tâches réelles. Livrer un HTML révisable avant l'implémentation applicative. Travailler dans la langue de l'utilisateur ; par défaut, explications en français avec les termes techniques anglais nécessaires. Cette compétence est autonome : les compétences amont et les services de référence payants sont facultatifs, pas des dépendances.
1. Établir le produit et préserver sa base
Lire d'abord les fichiers AGENTS.md, HANDOFF.md, DESIGN.md existants et les fichiers prototype courants. Identifier les utilisateurs, le scénario, le point d'entrée, la tâche principale, le résultat, la valeur métier, les surfaces demandées et ce qui est hors de cette version. Préserver les décisions de marque existantes et les modifications des autres. Résoudre vous-même les détails courants ; ne demander que les informations manquantes qui modifient matériellement la conception.
Convenir d'un inventaire borné d'écrans/flux à partir du brief, pas d'un nombre arbitraire de pages. Couvrir chaque surface demandée (web, mini-programme, mobile, bureau) ; ne pas inventer d'application non pertinente. Si le périmètre de surface est inconnu et que le projet ne peut pas l'établir, demander une fois avant de continuer. Une interface héritée reçoit un audit et une version non écrasante, pas un redesign non sollicité.
Lire les sections de règles de décision pertinentes (§1–7) dans source-synthesis.md ; utiliser sa carte source (§8–10) lorsqu'un compromis nécessite une explication. Elle intègre les sept dépôts source. La clarté de la tâche produit, les contrats de conception existants et les choix de l'utilisateur priment sur les conventions de page d'accueil, les interdictions de style et les thèmes aléatoires.
2. Rechercher des références, puis STOP pour une décision de style
Lire reference-research.md. Commencer par Dribbble ; utiliser 即时设计 et Behance comme solutions de repli ou compléments. Rechercher la catégorie du produit, la tâche de l'utilisateur et la plateforme pertinente, pas seulement « beau UI ». Utiliser les outils de navigation/recherche disponibles ; enregistrer quelles pages et images ont réellement été inspectées. Ne pas considérer un extrait de recherche comme une revue visuelle. Observer les restrictions d'accès ; si les cas réels ne peuvent pas être consultés, le signaler et demander des références fournies ou une renonciation explicite à la recherche.
Créer une nouvelle version sous docs/prototype/versions/vX.Y.Z/ (ou la racine prototype établie du projet). Utiliser le CLI ci-dessous pour démarrer en toute sécurité. Écrire d'abord style-reference.html : normalement 2–3 directions différenciées et adaptées à la tâche, liens/créateurs de cas réels, preuves observées par rapport à votre interprétation, échantillons de tokens et une petite étude UI originale de la MÊME tâche pour comparaison. Inclure l'adéquation plateforme, les limitations et votre recommandation. Préserver les choix de marque connus ; lorsque l'utilisateur a déjà fourni une direction, la valider au lieu de forcer des alternatives.
Livrer le HTML style-reference réel et demander à l'utilisateur de le choisir ou de le réviser. S'arrêter ici. Ne pas créer les écrans complets de l'application, design-system.html ou DESIGN.md final tant que l'utilisateur n'a pas explicitement approuvé une direction nommée (ou délégué ce choix exact dans la tâche en cours). Un bouton radio/carte local sélectionné, une recommandation préférée, un temps écoulé ou un enregistrement CLI n'est pas une autorisation utilisateur. Conserver la preuve d'approbation avec le SHA-256 du HTML approuvé ; un changement matériel de ce tableau nécessite une nouvelle décision. Ne pas traiter cette porte comme une permission de demander à nouveau des travaux non liés déjà autorisés.
3. Construire le prototype HTML complet après approbation
Lire prototype-contract.md et seulement les sections pertinentes de platforms-and-quality.md. Enregistrer la décision réelle de l'utilisateur ; le helper enregistre la preuve, il ne peut pas vérifier qui l'a donnée. Ensuite, préparer et remplacer les échafaudages générés par des artefacts conçus et fonctionnels :
index.html: page d'accueil/navigation du prototype avec version, entrées de surface, flux principaux, référence de style et liens de spécification visuelle. Chaque application possède également son propre accueil orienté tâche. Conserver les détails d'implémentation/statut dans ce hub de révision, pas dans le chrome produit.design-system.html: spécification visuelle complète pour les composants utilisés dans cette version : couleurs sémantiques, typographie, espacement, disposition/densité, icônes, surfaces, états de composants applicables, interaction/mouvement et différences de plateforme/réponse. Montrer des exemples rendus réels, pas seulement des tableaux de noms.DESIGN.md: décisions canoniques, valeurs de tokens, inventaire des écrans/flux, interactions, surcharges de plateforme, accessibilité, provenance et limitations connues du prototype. Le DESIGN.md par surface explique uniquement les variations pertinentes.- Écrans HTML de chaque surface demandée : chemins critiques complets convenus, données synthétiques plausibles étiquetées, navigation et changements d'état significatifs. Tokens sémantiques partagés ; interaction adaptée à la plateforme, pas une capture d'écran de bureau réduite.
Utiliser du HTML sémantique, des variables CSS et de petits scripts locaux par défaut. Réutiliser le framework/composants existant lorsque cela réduit la complexité ; pas de React, Tailwind, shadcn ou dépendance réseau obligatoires. Un prototype HTML statique doit s'ouvrir via un serveur HTTP local et rester navigable avec des URL de fichier lorsque c'est possible. Les actifs nécessaires à la révision du prototype doivent être locaux et sous licence. Garder le prototype séparé du code source de l'application.
4. Vérifier, versionner et remettre
Utiliser platforms-and-quality.md pour réviser le résultat rendu dans des fenêtres étroites et larges, le focus clavier, le zoom et le mouvement réduit ; inspecter le comportement applicable à la plateforme/appareil. Tester les chemins principaux réels ainsi que les états vides/chargement/erreur/succès et les contenus extrêmes qui comptent. Ne pas affirmer l'acceptation d'un appareil ou SDK natif à partir d'une simulation navigateur. Corriger les problèmes observés et revérifier les chemins affectés.
Exécuter une validation structurelle, puis enregistrer les preuves navigateur, les tailles de fenêtre, les flux testés et les problèmes non résolus dans QA.md. La validation structurelle ne peut pas prouver la qualité visuelle, l'exhaustivité métier, l'application des permissions, l'intégration externe ou la préparation à la production. Signaler explicitement les éléments non testés. Pour le travail de déploiement, mesurer les coûts de chargement/exécution/ressources pertinents au lieu de rapporter uniquement des vérifications fonctionnelles ; les prototypes locaux ordinaires ne nécessitent pas de suite de benchmarks de production.
Conserver les versions précédentes intactes. Lire versioning.md pour l'invalidation d'approbation, les révisions, les instantanés scellés, le journal des modifications et la navigation vers la dernière version. Ne pas modifier silencieusement un tableau approuvé ni écraser un prototype plus ancien. Fournir des liens vers les fichiers réels, comment les ouvrir, ce qui a été vérifié et ce qui reste simulé.
Helper (Python 3, bibliothèque standard)
Résoudre <skill-dir> vers le répertoire de cette compétence installée. Les commandes opèrent uniquement sur le projet spécifié ; elles ne publient ni ne modifient le code source de l'application.
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# Modifier style-reference.html avec une vraie recherche ; obtenir la décision de l'utilisateur.
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "Décision exacte de l'utilisateur de cette conversation"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# Remplacer chaque échafaudage en attente, implémenter les flux convenus, et rendre/réviser.
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "Périmètre et changements matériels révisés"
record-approval stocke un enregistrement de flux de travail, pas une identité ou une frontière de sécurité. Ne jamais fabriquer sa preuve. prepare produit des échafaudages, pas un prototype fini. seal enregistre les hachages de fichiers ; ce n'est pas une validation visuelle ni un stockage immuable. Utiliser le manifeste et les preuves de QA ensemble.