Criar frontend do zero

Créer un frontend à partir de zéro

Transformez un besoin produit en une interface fonctionnelle, accessible et vérifiable. Cette skill prend la tête lorsque l'objectif principal est de construire un nouveau frontend, dans un projet vide ou dans une nouvelle zone explicitement demandée. Elle implémente, exécute le projet lorsque c'est possible et rapporte ce qu'elle a réellement vérifié.

Frontières et collaboration

• Nouveau frontend : cette skill prend la tête, même lorsqu'une référence aide à orienter une création originale. Extrayez les principes, sans copier la marque, le contenu ou les actifs de tiers.
• Auditer une interface existante : utilisez audit-frontend-designer-konvert, qui est en lecture seule. Pour « auditez et corrigez », commencez par celle-ci et suivez le contrat d'approbation.
• Appliquer une référence, affiner directement une interface existante ou implémenter un rapport approuvé : utilisez design-por-referencia-konvert et respectez ses règles de périmètre, d'approbation et de dépendance externe.
• Dans les projets mixtes, implémentez uniquement la nouvelle zone autorisée ; identifiez et préservez les intégrations et les interfaces existantes. Consultez le guide de collaboration pour tirer parti des connaissances et des outils des autres skills sans les dupliquer.

Flux

1. Comprendre la demande et le contexte. Lisez les instructions du projet, les fichiers pertinents, la stack et les conventions existantes. Identifiez le produit, le public, la tâche principale, les pages, les données, l'identité, les contraintes et l'endroit où le travail sera livré. Distinguez les faits fournis des hypothèses ; n'inventez pas de personas ou de résultats de recherche. Si un choix indispensable ne peut être déduit et a un impact irréversible, demandez des éclaircissements ; pour les autres décisions, déclarez l'hypothèse et avancez. Enregistrez le résultat dans le brief de découverte et brief.
2. Définir une proposition concrète. Choisissez le parcours et les états pertinents : initial, chargement, vide, succès, erreur et récupération lorsqu'ils sont applicables. Listez les composants et les états par écran avec états et composants, en utilisant les unités de l'auditeur comme critère de prêt. Pour les projets avec plusieurs pages ou catégories, définissez les chemins avec structure de contenu et navigation. Définissez le contenu, la hiérarchie, la navigation et la direction visuelle cohérents avec le public et l'objectif, avec des tokens décidés conformément à la fondation visuelle. Utilisez l'exploration de la direction visuelle lorsque deux options modifient matériellement le résultat. Utilisez les matériaux locaux existants et, s'ils sont disponibles et pertinents, les catalogues et les unités de connaissance de l'auditeur. Citez uniquement les références réellement consultées. Une référence visuelle est une inspiration, pas une preuve d'utilisabilité.
3. Planifier la construction. Réutilisez le framework, le routage, les composants et les tokens existants. Dans un projet vide, choisissez la solution la plus simple adaptée à la demande et à l'environnement avec le choix de stack ; justifiez les nouvelles dépendances, vérifiez les versions et les scripts avant de les exécuter. Ne supposez pas l'autorisation pour les services payants, la publication, les comptes externes ou les données réelles. Maintenez le périmètre du backend, de l'authentification et des intégrations conformément à la demande ; lorsqu'ils sont absents, utilisez des données synthétiques et indiquez clairement la limitation.
4. Implémenter. Construisez le contenu, la structure sémantique, les styles, les composants et les interactions réelles dans le périmètre autorisé. Évitez les boutons sans comportement ou les liens fictifs présentés comme fonctionnels : implémentez l'action demandée ou indiquez clairement son indisponibilité. Utilisez des tokens cohérents, des états visibles et des mises en page responsives. Appliquez les règles de contenu, SEO, performance et mesure : contenu fictif identifié, SEO de base sur les pages publiques et aucun analytics sans demande. Consultez sécurité et localisation pour protéger le frontend et, lorsque le produit a plusieurs langues ou régions, adaptez l'interface aux locales définies. Ne supprimez ni ne remplacez le code, les données, les intégrations ou les fichiers de l'utilisateur sans nécessité et autorisation applicable.
5. Vérifier. Exécutez les vérifications pertinentes pour le projet, lancez l'interface localement lorsque c'est possible et ouvrez le résultat rendu. Vérifiez les tâches principales, le contenu, la navigation, le clavier, le focus, les formulaires, les états pertinents, l'écran étroit et le bureau ; évaluez le contraste et le mouvement réduit lorsqu'ils sont applicables. Utilisez les scripts de la skill de référence lorsqu'ils sont disponibles, avec une sortie autorisée et des données synthétiques. Pour une création sans version précédente, n'inventez pas d'avant/après : enregistrez la première capture comme référence initiale et comparez uniquement les états ou les versions réellement existants. Consultez vérification.
6. Livrer et rapporter. Vérifiez la définition de prêt et utilisez son modèle de rapport. Informez des fichiers modifiés, des décisions et des hypothèses pertinentes, de la manière d'exécuter, des vérifications effectuées et de leurs résultats, des fonctionnalités simulées et de ce qui n'a pas pu être validé. Enregistrez les tâches, les zones inspectées, les décisions et les critères vérifiés dans execution-record.json dans le répertoire de sortie autorisé, en suivant enregistrement d'exécution et son validateur. Ne stockez pas de prompt ou d'URL privées. N'alléguez pas de tests utilisateurs, de conformité intégrale, de performances ou de résultats commerciaux sans preuve. Si le navigateur n'est pas disponible, rapportez explicitement que l'interface n'a pas été inspectée visuellement.

Confidentialité et sécurité

Utilisez uniquement des cibles et des environnements autorisés. Ne lisez ni n'exposez jamais .env, les identifiants, les sessions ou les données personnelles inutiles ; utilisez du contenu synthétique et réexaminez les captures avant de les partager. Respectez les protections et les limitations de l'outil de capture : l'inspection exécute JavaScript et n'est pas un bac à sable pour les sites non fiables. Enregistrez les artefacts uniquement dans un répertoire autorisé et ignoré par Git, ou en dehors du checkout ; ne modifiez pas la configuration de confidentialité du projet sans nécessité. N'envoyez pas de données à des tiers, ne créez pas de comptes et ne publiez pas sans autorisation.

Critères de qualité

L'interface doit soutenir la tâche principale avec clarté, hiérarchie visuelle, contenu cohérent et retour utile. Veillez à la sémantique, au focus, aux noms accessibles, aux étiquettes et au reflow conformément au contexte ; n'affirmez pas la certification d'accessibilité uniquement avec des vérifications automatiques. N'inventez pas de métriques de conversion, de témoignages, de badges, de prix, d'intégrations ou de fonctionnalités. Privilégiez une implémentation complète et testable dans le périmètre à une apparence convaincante avec des actions cassées.

Définition de prêt

La livraison n'est prête que lorsque la tâche principale fonctionne de bout en bout dans le périmètre convenu et que chaque élément de la définition de prêt est rempli, non applicable avec motif ou non vérifié avec motif. Points qui échouent le plus souvent dans les créations à partir de zéro :

• états autres que normal (chargement, erreur, vide, succès et récupération) sans moyen d'être observés ;
• focus supprimé ou masqué, étiquette uniquement dans le placeholder et erreur indiquée uniquement par la couleur ;
• contraste et cibles tactiles non mesurés dans le rendu ;
• boutons et liens qui semblent fonctionner, mais ne font rien ;
• données commerciales, témoignages ou intégrations inventés ;
• analytics ou polices externes ajoutés sans décision enregistrée.

Références et exemples

Matériel	Quand utiliser
Découverte et brief	Avant de construire : questions avec modèles et enregistrement des hypothèses.
Choix de stack	Projet vide, sans plateforme définie.
Fondation visuelle	Tokens et contraintes vérifiables de contraste, cible et focus.
Exploration de direction visuelle	Direction originale, options matérielles et vérification dans le rendu.
Structure de contenu et navigation	Chemins, étiquettes et organisation des pages dans les nouveaux projets.
États et composants	Inventaire par écran et unités de l'auditeur comme critère de prêt.
Contenu, SEO, performance et mesure	Pages publiques, formats brésiliens, Core Web Vitals et confidentialité.
Sécurité et localisation	Contenu variable, ressources externes et, le cas échéant, plusieurs langues ou régions.
Vérification	Comment exécuter et enregistrer les vérifications.
Collaboration	Quand utiliser l'auditeur et l'exécuteur.
Définition de prêt et livraison	Avant de rapporter la livraison.
Brief de page d'accueil, brief d'e-commerce et rapport de livraison	Exemples synthétiques du niveau de détail attendu.