flntfnd/figma-design-system

Systèmes de Design Figma

Comment je construis des systèmes de design dans Figma pour iOS/iPadOS/macOS, Android et Web, au-dessus du serveur MCP officiel de Figma. Chaque valeur est une variable. Les styles sont réservés aux composites construits à partir de variables : styles de texte, styles d'effet, styles de dégradé de peinture. Les styles de couleur unie sont hérités.

Les appels d'outils MCP appartiennent aux compétences plugin fournies avec le plugin Figma (figma:figma-use, figma:figma-generate-library, figma:figma-generate-design, et leurs semblables). Figma les maintient. Chargez-les en parallèle de celle-ci. Sur les aspects mécaniques, la compétence plugin l'emporte. Sur les processus et l'exhaustivité, c'est celle-ci qui prime.

Référence Rapide

Sujet	Référence
Nommage des tokens pour chaque compétence : niveaux, familles, règle de conversion par plateforme, syntaxe de code ; collections de variables, modes, typographie, espacement, rayon	reference/token-architecture.md
Listes de composants et d'états, Auto Layout, propriétés, Slots, câblage obligatoire des états interactifs	reference/component-architecture.md
Construction de Liquid Glass dans Figma : kit d'Apple, paramètres, tokens de verre, limites de l'API	reference/liquid-glass.md
Application d'un style visuel à un design existant (restructuration, pas un échange de tokens)	reference/applying-styles.md
Ordre des opérations pour construire à partir de zéro et répliquer une application, structure de fichier, transfert en mode Développeur, accessibilité, anti-patrons	reference/workflows-and-handoff.md
Les quatre vérifications en détail, comment elles s'adaptent à la tâche, l'ensemble d'écrans minimum par plateforme	reference/gates.md
Faits Figma qui changent : seuils de plan, limites, statut bêta, noms d'outils et de compétences MCP, liens vers les kits, datés	reference/platform-status.md

Vérifications

Quatre règles, les miennes, vérifiées au début de chaque session et tout au long. Elles échouent silencieusement et coûtent le plus cher au moment du transfert.

1. Toile sombre en premier. La toile de chaque page est #1E1E1E avant même l'existence de tout contenu. Si elle est blanche, arrêtez et corrigez-la.
2. Pas de pages ou de cadres vides. Créez-la, remplissez-la complètement, passez à la suivante. Une plateforme n'est pas complète sans l'ensemble d'écrans minimum.
3. Les noms de tokens correspondent exactement à la base de code. Utilisez les noms déjà en production. N'en inventez pas de nouveaux.
4. Clair et sombre, les deux. Chaque couleur sémantique a les deux valeurs et chaque écran est construit et révisé dans les deux avant d'être considéré comme complet.

Une construction complète respecte les quatre intégralement. Une petite modification d'un fichier existant ne doit simplement pas dégrader le fichier, et tout ce qui est déjà cassé doit être signalé, pas réparé silencieusement. reference/gates.md contient les raisons, les règles d'adaptation et l'ensemble d'écrans minimum.

Dans Figma :

Toile sombre :

figma.currentPage.backgrounds = [{
  type: 'SOLID',
  color: { r: 0.118, g: 0.118, b: 0.118 },  // #1E1E1E
  opacity: 1
}];

figma.currentPage correspond à une page. Répétez pour chaque page en utilisant la règle de changement de page dans figma:figma-use, et définissez-la sur chaque nouvelle page au moment de sa création. Manuellement : clic droit sur la toile vide → Couleur d'arrière-plan. Faites une capture d'écran et vérifiez.

Pas de pages vides. Créez une page dans la même étape qui la remplit. Si une page 🎨 Tokens existe, les collections de variables s'y trouvent avant que la page 🎛 Components ne soit touchée.

Noms de tokens. Le chemin de la variable et la syntaxe de code de chaque variable suivent reference/token-architecture.md. Là où la base de code nomme déjà un token, ce nom prévaut.

Clair et sombre. Modes Light et Dark sur la collection Semantic Color. Révisez chaque écran avec son cadre principal défini sur chacun.

Couloirs

Cette compétence contient le processus Figma et les noms de tokens. Les valeurs et les règles de plateforme proviennent de la compétence qui les possède.

Besoin	Propriétaire
Les quatre vérifications et l'ensemble d'écrans minimum	Cette compétence (reference/gates.md)
Valeurs de palette et primitive que chaque rôle sémantique aliase	color-system
Tailles de police Apple, couleurs système, règle et aspect Liquid Glass, versions d'OS	apple-platform
Rôles de couleur Material, échelle de forme, classes de taille de fenêtre, versions de bibliothèque	android-platform
Tokens Web en CSS, points de rupture en code	web-platform
Noms et valeurs des tokens de mouvement	motion-design
Le catalogue de styles	visual-styles

Démarrage de Session

1. Chargez figma:figma-use et la compétence plugin adaptée à la tâche : figma-generate-library pour les tokens et composants, figma-generate-design pour les écrans, figma-design-to-code avant de lire un design pour l'implémentation.
2. Ouvrez une session. create_session avec la clé du fichier et une tâche d'une ligne, avant tout autre outil de fichier, y compris le travail en lecture seule. Nouveau fichier : create_new_file d'abord, puis create_session.
3. Lisez avant d'écrire. Un fichier existant a des pages, des collections et des conventions. Trouvez-les avant d'y ajouter quoi que ce soit.
4. Vérifiez les portes, adaptées à la tâche.

Style de Design

Confirmez le style visuel avec la compétence visual-styles avant de construire des tokens ou des composants. Sans style spécifié, le langage de design natif de la plateforme est la valeur par défaut. Les niveaux de tokens, la structure des composants, l'Auto Layout et le câblage des états restent les mêmes d'un style à l'autre. Seules les valeurs et les spécificités structurelles changent. reference/applying-styles.md explique comment un style est appliqué dans Figma.

Philosophie

Le système de design est un contrat entre le design et le code. Les tokens définis dans Figma sont les mêmes tokens utilisés dans SwiftUI, Compose et CSS. Les noms, les valeurs et la hiérarchie correspondent sur les trois plateformes. Un système de design construit sans l'ingénierie comme public n'est qu'une planche de stickers.

Concevez tout. Chaque écran, chaque état, chaque cas limite. Vide, chargement, erreur, contenu partiel, débordement, texte long, texte court, désactivé. Un design qui ne couvre que le chemin heureux est un tableau d'ambiance. L'ingénierie inventera les états manquants dans le code, et ils seront faux.

Pixel perfect signifie exactement cela. Liez tout à des variables, mesurez tout. Un composant qui fait 17px de large parce qu'il « a l'air à peu près juste » n'est pas pixel perfect.

Deux Modes de Travail

Construire à partir de zéro. Système de design d'abord, composants ensuite, écrans en dernier. Les tokens sont définis avant qu'un seul composant ne soit touché.

Répliquer une application existante. Auditez d'abord, extrayez le système implicite, formalisez-le, puis reconstruisez les composants sur les tokens formalisés. Ne sautez jamais l'audit.

Les deux sont décrits étape par étape dans reference/workflows-and-handoff.md.