flcker/figma-ui-desktop

Spécification de développement UI desktop Figma (version Framelink MCP)

Résout le problème de faible fidélité lors du développement d'UI desktop à partir de maquettes Figma. La cause racine : considérer les « données de la maquette » Figma (coordonnées absolues, couleurs en ligne, superposition de calques pixels) comme des « données d'implémentation », ce qui conduit à des dispositions rigides, des couleurs et polices inexactes, et des ressources manquantes.

Pourquoi utiliser Framelink pour le desktop plutôt que le serveur MCP officiel de Figma ? : L'outil principal du MCP officiel, get_design_context, ne produit par défaut que du code Web (React/Tailwind, convertible en Vue/HTML/iOS), ne prend pas en charge Qt Widget / QML / WinUI / Flutter, et est payant. Framelink se positionne comme « fournisseur de données Figma indépendantes du framework, la traduction est laissée au modèle » — ce « défaut » est en fait un avantage dans le contexte multi-frameworks desktop : le modèle, après avoir reçu les données de la maquette, peut les traduire dans n'importe quel framework cible, sans être verrouillé dans le Web.

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 de la maquette (disposition, contenu, visuel, informations sur les composants) via fileKey + nodeId
download_figma_images	Canal visuel	Exporte les nœuds en SVG/PNG/GIF vers un répertoire local

Si la cible est le Web (React/Vue/HTML), utilisez figma-ui-web plutôt que ce skill.

Principes fondamentaux

1. Double canal en parallèle, interdiction de coder avec un seul canal. Le canal précis fournit les valeurs exactes, le canal visuel donne la disposition globale et le texte. N'utiliser qu'un seul entraîne une distorsion de la fidélité.
2. Utiliser des valeurs exactes, ne pas faire d'estimation visuelle. Couleurs, tailles de police, graisses, espacements, coins arrondis, bordures, ombres : toujours prendre les valeurs exactes de la maquette.
3. Demander d'abord la maquette, ne pas coder l'UI de sa propre initiative.
4. Après l'implémentation, la vérification en boucle fermée est obligatoire : capture d'écran de l'application compilée → comparaison avec la maquette → correction automatique des défauts → relecture humaine pour identifier les problèmes plus fins → itération.

Flux de travail

Phase 1 : Lecture grossière (comprendre les besoins et la structure)

Lorsque la maquette est trop 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 peu profond), afin de comprendre les pages/blocs/contrôles.
2. Utilisez download_figma_images pour exporter une vue d'ensemble de l'interface et comprendre la disposition et le texte.

Phase 2 : Lecture précise (obtenir des données exactes avant l'implémentation)

Pour le bloc ou le contrôle spécifique à implémenter, appelez simultanément :

• get_figma_data (avec nodeId, lisez les coordonnées, les valeurs de couleur, la taille de police, l'espacement, les coins arrondis, les bordures nœud par nœud)
• download_figma_images (exportez l'image de ce bloc pour confirmer les relations de position relatives des contrôles)

Après avoir obtenu les données, effectuez d'abord une analyse structurelle avant d'écrire le code :

• Quels nœuds sont des motifs répétés (éléments de liste, cartes, boutons) → extrayez-les en contrôles/composants personnalisés du framework cible
• Quels positionnements absolus sont en fait des dispositions (disposition horizontale, centrage, alignement justifié, grille) → convertissez-les en dispositions du framework correspondant en utilisant la table de correspondance ci-dessous
• Quels sont les rôles sémantiques (navigation, formulaire, liste) → mappez-les à la bibliothèque de contrôles existante du framework cible
• Nœuds image/icône → utilisez download_figma_images pour télécharger le fichier original dans le répertoire des ressources, ne les dessinez pas à la main

Phase 3 : Implémentation (traduction indépendante du framework)

Utilisez les valeurs exactes de la maquette pour les couleurs, les tailles de police et les espacements. Lors de la traduction, consultez la table de correspondance « Concepts de la maquette → Framework cible » ci-dessous. N'inventez pas de contrôles — si le framework cible a des dispositions/contrôles standard, utilisez-les. N'utilisez le positionnement absolu que lorsqu'un « positionnement précis en pixels est vraiment nécessaire ».

Phase 4 : Vérification en boucle fermée

Le desktop ne dispose pas d'outils d'automatisation de navigateur comme Playwright. La méthode de vérification : compilez et exécutez l'application, prenez une capture d'écran, comparez-la côte à côte avec la capture d'écran de la maquette, corrigez automatiquement les défauts évidents ; la relecture humaine identifie les problèmes plus fins (espacements, graisses, nuances de couleur), les soumet activement à l'IA pour une correction précise, puis passe à l'itération suivante.

Table de correspondance : Concepts de la maquette → Framework cible

La maquette Figma est composée de coordonnées absolues et de calques pixels. L'implémentation doit traduire cela en sémantique de disposition de chaque framework. Consultez cette table lors de la traduction :

Concept maquette/conception	Qt Widget	QML (Qt Quick)	WinUI 3 (XAML)	Flutter
Disposition horizontale	QHBoxLayout	Row	StackPanel (Orientation=Horizontal)	Row
Disposition verticale	QVBoxLayout	Column	StackPanel (Orientation=Vertical)	Column
Grille	QGridLayout	Grid / GridLayout	Grid	GridView / Table
Positionnement absolu	setGeometry / move	Item + x/y	Canvas + Canvas.Left/Top	Stack + Positioned
Superposition/chevauchement	Superposition de widgets enfants / raise()	Propriété z / Stack	Canvas.ZIndex	Stack
Centrage	addStretch / setAlignment	anchors.centerIn	HorizontalAlignment/VerticalAlignment=Center	Center / Align
Alignement justifié	addStretch des deux côtés	anchors.left/right + marges	Répartition des marges	MainAxisAlignment.spaceBetween
Espacement	QSpacerItem / spacing de la disposition	Propriété spacing	Margin / Padding	SizedBox / Padding / Spacer
Couleur	QPalette / feuille de style	Thème / liaison de propriétés	Dictionnaire de ressources ResourceDictionary	ThemeData / ColorScheme
Taille de police/police	QFont	font.pixelSize	FontSize	TextStyle.fontSize
Coins arrondis	border-radius de la feuille de style	Rectangle radius	CornerRadius	BorderRadius
Ombre	QGraphicsDropShadowEffect	DropShadow	ThemeShadow / DropShadow	BoxShadow
Icône	QIcon / ressources	Image / police d'icônes	FontIcon / SymbolIcon	Icon
Réutilisation de composants	Sous-classe QWidget personnalisée	Component QML personnalisée	UserControl / contrôle personnalisé	Widget
État/variante	Énumération + update()	State / piloté par propriétés	VisualStateManager	setState / AnimatedWidget

Règles anti-paresse

L'IA a tendance à coder en n'utilisant qu'un seul canal. Exigez explicitement :

• « Appelez simultanément get_figma_data et download_figma_images pour lire la maquette »
• « Il est interdit d'écrire du code en se basant uniquement sur des images/captures d'écran de la maquette »
• « Lisez ligne par ligne les valeurs exactes de get_figma_data, comparez les couleurs, les tailles de police, les espacements, ne faites pas d'estimation visuelle »
• « Traduisez en dispositions/contrôles standard du framework cible en utilisant la table de correspondance, n'inventez pas »

Liste de contrôle d'auto-vérification de la fidélité

Après la génération, vérifiez chaque point (plus fiable qu'un simple « ça ressemble » global) :

• Couleurs (valeurs exactes, pas approximatives ?)
• Taille de police / graisse
• Espacements / marges / padding
• Coins arrondis / bordures / ombres
• Disposition (traduite en disposition standard du framework cible, pas copie des coordonnées absolues ?)
• Hiérarchie / ordre de superposition
• Icônes/images : fichiers originaux, pas dessinés à la main ?
• Les motifs répétés ont-ils été extraits en composants/contrôles personnalisés ?

Sources de référence

La méthodologie s'inspire du flux de développement UI utilisant le MCP officiel de Figma et Playwright (voir « Améliorer l'efficacité du développement et du débogage UI avec Figma MCP et Playwright MCP »). L'idée centrale « double canal + vérification en boucle fermée + exigences anti-paresse explicites » est conservée, les noms d'outils sont adaptés à Framelink figma-developer-mcp, et la table de correspondance est étendue pour couvrir plusieurs frameworks desktop.