flcker/figma-ui-web

Normes de développement UI Web Figma (version Framelink MCP)

Résout le problème de faible fidélité lors du développement d'UI Web à partir de maquettes Figma. La cause racine est que les données du canevas Figma (coordonnées absolues, couleurs en ligne, superposition de calques) sont considérées comme des données d'implémentation, ce qui conduit à un rendu réactif défectueux, des couleurs et polices inexactes, et des ressources manquantes.

Ce skill est destiné aux deux outils de Framelink figma-developer-mcp :

Outil	Canal	Rôle
get_figma_data	Canal précis	Récupère les données du canevas selon fileKey + nodeId : informations de mise en page, contenu, visuelles, composants
download_figma_images	Canal visuel	Exporte les SVG/PNG/GIF des nœuds dans un répertoire local

Remarque : Ceci est la version Framelink, pas le serveur Figma MCP officiel (dont les outils sont get_design_context/get_variable_defs/download_assets). La méthodologie de ce skill est commune aux deux, mais les noms d'outils suivent Framelink.

Pour les applications de bureau (Qt Widget / QML / WinUI / Flutter), utilisez figma-ui-desktop plutôt que ce skill.

Principes fondamentaux

1. Double canal obligatoire, interdiction d'écrire du code avec un seul canal. Le canal précis fournit les valeurs exactes, le canal visuel donne la mise en page globale et le texte. Utiliser un seul entraîne une distorsion du rendu — surtout si on utilise uniquement le canal visuel (c'est deviner d'après une capture) ou uniquement le canal de données (c'est coder à l'aveugle).
2. Utiliser les valeurs exactes, pas d'estimations visuelles. Couleurs, taille de police, hauteur de ligne, graisse, espacement, coins arrondis, bordures, ombres : toujours prendre les valeurs exactes de la maquette.
3. Demander d'abord la maquette, ne pas écrire l'UI de soi-même.
4. Après l'implémentation, boucle de validation obligatoire : comparer la capture d'écran avec la maquette → corriger automatiquement les défauts → relecture humaine → itération. Il n'existe pas de magie pour atteindre 100% du premier coup ; 70-80% de fidélité viennent du processus, le reste est comblé par la boucle de validation.

Flux de travail

Phase 1 : Lecture grossière (comprendre le besoin et la structure)

Lorsque la maquette est grande, commencez par une lecture grossière pour éviter de surcharger le contexte :

1. Utilisez get_figma_data pour récupérer la structure de haut niveau (depth contrôle le niveau de parcours, commencez par le superficiel), comprenez les pages/blocs/composants.
2. Utilisez download_figma_images pour exporter l'image globale de la page, comprenez la mise en page et le texte.

Phase 2 : Lecture fine (obtenir les données précises avant l'implémentation)

Pour le composant/bloc à implémenter, appelez simultanément :

• get_figma_data (avec nodeId, lisez les coordonnées, couleurs, polices, espacements, coins, bordures nœud par nœud)
• download_figma_images (exportez l'image de ce bloc, confirmez les positions relatives des composants)

Faites d'abord une analyse structurelle avant d'écrire le code :

• Quels nœuds sont des motifs répétés (cartes, éléments de liste, boutons) → extrayez-les en composants
• Quels positionnements absolus sont en fait des mises en page (disposition horizontale, centrage, alignement justifié) → convertissez-les en flex/grid
• Quelles sont les rôles sémantiques (navigation, formulaire, liste) → mappez-les avec la bibliothèque de composants existante du projet
• Nœuds d'images/icônes → téléchargez les fichiers originaux via download_figma_images dans le dossier assets, ne les dessinez pas à la main

Phase 3 : Implémentation

• Couleurs, polices, espacements : utilisez les valeurs exactes de la maquette, pas « ça semble proche »
• Privilégiez la bibliothèque de composants existante du projet, vérifiez d'abord les props (theme/size/variant), évitez de redéfinir les styles
• Icônes : utilisez la bibliothèque d'icônes du projet, pas des icônes tierces
• Nommage des fichiers de style, conventions des classes CSS, profondeur d'imbrication : suivez les conventions du projet

Phase 4 : Boucle de validation

Utilisez Playwright MCP pour ouvrir la page locale et prendre une capture d'écran, comparez-la côte à côte avec la capture de la maquette, corrigez automatiquement les défauts évidents ; relecture humaine : identifiez les problèmes plus fins (espacements, graisse, nuances de couleurs), soumettez-les activement à l'IA pour une correction précise, puis entrez dans la prochaine itération.

Règles strictes anti-paresse

L'IA a tendance à n'utiliser qu'un seul canal pour écrire du code. Exigez explicitement :

• « Appelez à la fois get_figma_data et download_figma_images pour lire la maquette »
• « Il est interdit de lire la maquette uniquement avec des images/captures pour écrire du code »
• « Lisez ligne par ligne les valeurs exactes de get_figma_data, comparez les couleurs, polices et espacements, sans estimation visuelle »

Normes de composants (à adapter selon le projet)

Ce qui suit est un modèle. Adaptez-le aux conventions du projet :

• Privilégiez la bibliothèque de composants du projet (ex. @notta/components), en cas de doute demandez activement à l'utilisateur
• Vérifiez d'abord les props de la bibliothèque de composants, évitez de redéfinir les styles
• Icônes : utilisez la bibliothèque d'icônes du projet
• Nommage des fichiers de style, conventions des classes CSS, profondeur d'imbrication : suivez les conventions du projet

Liste de vérification de fidélité

Après génération, cochez chaque élément (plus fiable que « est-ce que ça ressemble dans l'ensemble ? ») :

• Couleurs (hex exact utilisé, pas une approximation)
• Taille de police / hauteur de ligne / graisse
• Espacement / marges / padding
• Coins arrondis / bordures / ombres
• Mise en page (flex/grid équivalent à la disposition de la maquette)
• z-index / hiérarchie
• Les icônes/images sont-elles des fichiers originaux, pas dessinés à la main ?

Sources de référence

Méthodologie inspirée du flux de développement UI officiel Figma MCP + Playwright (voir « Améliorer l'efficacité du développement UI avec Figma MCP et Playwright MCP »). Le principe central est « double canal + boucle de validation + exigences explicites anti-paresse », les noms d'outils ont été adaptés pour Framelink figma-developer-mcp.