Justin Figma Design (/jfd)

Que fait jfd) ?

Cet espace de travail est un espace de collaboration axé sur Figma, et non une base de code applicative. Cette compétence est la couche d'orchestration : mémoire de l'espace de travail, flux de travail Figma Console, discipline de système de design et QA visuelle fondée sur des preuves. Ne générez pas de React, HTML ou CSS, sauf si l'utilisateur demande explicitement du design-to-code.

Compagnon MCP requis

Tout travail Figma repose sur Figma Console MCP (user-figma-console) : figma_execute pour inspecter et muter, figma_take_screenshot pour les preuves, figma_get_status et figma_reconnect pour la connexion Desktop Bridge. Les travaux d'écriture nécessitent le serveur local/NPX avec le Desktop Bridge connecté ; le mode distant hébergé est en lecture seule. Lisez references/figma-execute.md avant d'écrire un script, ainsi que le fichier de l'espace de travail docs/tools/figma-console.md (à la racine de l'espace de travail) pour les détails de connexion. Ne traitez pas /jfd comme un éditeur Figma autonome sans cette connexion MCP.

Résolvez les faits à partir du design, pas de cette compétence

Cette compétence fournit des procédures, pas des faits. Les tailles d'appareils, les polices, l'espacement et les préférences de style évoluent avec le temps ; le fichier cible est toujours à jour. Résolvez toute valeur nécessaire — une dimension, une police, un pas d'espacement, une couleur, un nom ou une convention — dans cet ordre :

1. Le fichier cible. Mesurez le cadre, le texte, le jeton ou le composant réel.
2. La famille. Les cadres frères, les états et les écrans dans la même section.
3. La mémoire de l'espace de travail. Les fichiers docs/files/<alias>/design.md et docs/preferences.md, en respectant leurs dates de « Dernière vérification ».
4. L'utilisateur ou une recherche actuelle. Demandez, ou consultez les directives actuelles de la plateforme. Ne faites jamais confiance à des tailles d'appareils mémorisées ou à des valeurs par défaut obsolètes.
5. Écrivez en retour. Enregistrez la valeur résolue avec la date du jour dans le design.md cible afin que la prochaine session puisse lui faire confiance.

Ne résolvez jamais une valeur de projet à partir du texte de cette compétence.

Deux flux de travail

• Modification d'un fichier existant (par défaut) : il y a quelque chose à mesurer. Suivez la boucle complète ci-dessous et ne présumez jamais d'une taille de cadre racine — mesurez le cadre racine réel de la famille en cours d'édition.
• Départ de zéro : rien n'existe à mesurer, donc l'ordre de résolution s'exécute sur les étapes 3 à 5. Lisez references/starting-from-scratch.md. Confirmez la taille du cadre racine, la typographie et la prise en charge du thème avec l'utilisateur avant de construire, puis créez immédiatement le fichier design.md afin que chaque session ultérieure puisse mesurer au lieu de deviner.

Initialiser un espace de travail vide

Utilisez le mode init lorsque l'espace de travail manque de docs/preferences.md et docs/FILES.md. Init est un échafaudage local et idempotent ; il n'ouvre jamais Figma, n'appelle pas le MCP et ne mute pas un canvas.

1. Traitez jfd init de la même manière que /jfd init lorsque l'hôte n'a pas d'alias de barre oblique.
2. Listez les chemins d'échafaudage manquants avant d'écrire. Dans un espace de travail non vide, demandez une confirmation d'abord. Ne remplacez jamais un fichier, un répertoire, un lien symbolique ou une installation de compétence existant.
3. Copiez uniquement les fichiers manquants à partir de assets/templates/ de cette compétence.
4. Installez une copie de compétence manquante dans .agents/skills/justin-figma-design/ (canonique) et .cursor/skills/justin-figma-design/ le cas échéant.
5. Exécutez éventuellement scripts/init_project.py (Python 3, stdlib uniquement) pour un passage en masse ; les outils de fichiers de l'agent restent la voie principale.
6. Vérifiez l'échafaudage, puis demandez un lien Figma ou une clé de fichier. N'inventez jamais d'identifiants ni de données de fichier.

Détails : references/getting-started.md.

Choisissez le mode de fonctionnement

Le mode Non-YOLO est le mode par défaut.

• Non-YOLO pour le travail de production : motifs partagés, écrans, composants, variables, thèmes, modifications réactives et toute portée non explicitement jetable.
• YOLO uniquement lorsque l'utilisateur dit explicitement « YOLO », « démo rapide », « prototype rapide » ou équivalent, et que la portée est un seul tableau ou état nommé.
• « Créer un composant », « mettre à jour une bibliothèque », « prendre en charge le mode clair et sombre » ou une modification de chrome partagée n'est jamais YOLO simplement parce que c'est petit.
• Restez en mode plan jusqu'à ce que l'utilisateur demande clairement d'implémenter ou d'exécuter.

YOLO réduit les frais généraux de la bibliothèque ; il ne supprime pas la sécurité ni la QA visuelle. Passez en Non-YOLO si vous découvrez un chrome partagé, un motif réutilisable, plusieurs états liés, une propagation clair/sombre ou réactive, une modification de composant maître, un refactoring de disposition automatique, une modification de règle métier ou un second tableau. Routeur complet et listes de contrôle : references/modes-and-workflow.md.

Avant toute mutation Figma

1. Lisez docs/preferences.md et docs/FILES.md à la racine de l'espace de travail.
2. Résolvez l'alias du fichier cible et lisez son docs/files/<alias>/design.md ; lisez screens.md pour le travail sur les écrans, les flux ou les surfaces composites.
3. Lisez la dernière note de session pertinente. Le design.md vivant et l'autorité actuelle prévalent sur les notes historiques obsolètes.
4. Confirmez le fichier Figma actif, la page, la section/cadre et l'autorité. Recherchez à nouveau les ID de nœuds, les composants, les variables et les styles dans le fichier connecté ; les ID des sessions précédentes sont des preuves obsolètes, pas une autorisation.
5. Inventoriez toute la famille du même cadre/état avant un changement partagé : clair/sombre, développé/réduit, routes actives imbriquées, superpositions, variantes réactives et états intentionnellement supprimés.
6. Mesurez le(s) cadre(s) racine(s) de la famille en cours d'édition. Ne présumez jamais d'une taille d'appareil.
7. Avant la mutation de texte, inspectez les segments de police stylisés et chargez les polices actuelles. Choisissez toute police de remplacement via l'ordre de résolution — texte mesuré, puis design.md, puis l'utilisateur — jamais à partir de cette compétence.

Si le fichier cible n'a pas de design.md, effectuez d'abord une ligne de base d'investigation en lecture seule. Si le fichier actif ou l'autorité ne peut pas être vérifié, arrêtez-vous et demandez.

Graphiques courants

Avant de placer des icônes ou des images importées, lisez docs/assets/README.md et docs/assets/icons.md à la racine de l'espace de travail. Préférez les composants de fichier existants et les sources d'icônes approuvées du projet ; inspectez les limites vectorielles, le dimensionnement et le contraste du thème avant d'accepter un nouveau graphique. Les avatars sont fournis uniquement par l'utilisateur ; ne les générez jamais.

Contrat Non-YOLO

• Recherchez d'abord les instances/composants locaux autoritaires, puis les bibliothèques activées, puis une recherche plus large dans les bibliothèques. Créez uniquement après avoir documenté l'écart.
• Construisez le système de design minimum cohérent pour la portée approuvée : variables et modes d'abord, puis styles et composants, puis instances d'écran.
• Utilisez des variantes pour les états structurels/visuels et les propriétés de composants pour la flexibilité du contenu. Préférez les instances, les échanges d'instances et les wrappers contrôlés plutôt que les redessins détachés.
• Rendez l'intention de mise en page lisible : noms sémantiques, hiérarchie significative, disposition automatique là où les enfants sont liés, liaisons de jetons, descriptions de composants et comportement d'accessibilité/état documenté.
• Traitez le clair/sombre comme une matrice de modes de variables, et non comme deux écrans codés en dur. Voir references/variables-and-theming.md.
• Appliquez les modifications partagées à l'ensemble de la famille d'écrans associés en un seul passage, puis effectuez une QA sur chaque membre. Un correctif sur un seul cadre n'est pas complet tant que les frères sont obsolètes.

Lisez references/components-and-design-system.md et references/layout-and-autolayout.md avant un travail complexe.

Règles de mise en page

Choisissez Hug, Fill, Fixed, et min/max indépendamment par axe : Hug pour les piles et les contrôles pilotés par le contenu ; Fill uniquement pour un enfant avec un espace disponible significatif dans un parent en disposition automatique ; Fixed pour les limites structurelles intentionnelles (racines d'écran mesurées, boîtes d'icônes, CTA, coques calibrées) ; min/max pour les limites réactives approuvées. Encodez les relations avec la disposition automatique imbriquée, le padding et l'espacement — jamais de cadres d'espacement invisibles préservant les anciennes coordonnées. Conservez les couches absolues / Ignorer la disposition automatique uniquement pour les superpositions justifiées, le chrome, la décoration ou les exceptions documentées dans le design.md cible. Après avoir redimensionné un conteneur, auditez les descendants qui possèdent la largeur ; un parent plus large n'est pas un réécoulement complet. Détails : references/layout-and-autolayout.md.

Exécutez et vérifiez

Inspectez, exécutez un petit figma_execute ciblé, retournez chaque ID muté et la géométrie utile, puis capturez une capture d'écran immédiatement avec figma_take_screenshot. Gardez les écritures et les captures d'écran séquentielles lorsque le routage dépend du fichier actif. La QA combine la structure mesurée avec les preuves visuelles — capturez, selon le cas : (1) un recadrage de composant ciblé, (2) le tableau complet, (3) la famille associée ou l'aperçu de la section. Vérifiez les bords partagés, l'espacement, le clipping, le débordement, le comportement du texte long, les limites des icônes/vecteurs, le contraste, la typographie, les contrôles cachés, l'état sémantique, la parité des états associés, les valeurs codées en dur, les liaisons non résolues et la résolution clair/sombre. Utilisez les designs Figma Check lorsqu'ils sont disponibles ; sinon, effectuez des contrôles structurels et manuels équivalents.

Traitez un figma_execute échoué comme potentiellement partiel jusqu'à ce que la cible soit inspectée ; ne réexécutez jamais aveuglément un script de création ou de reparentage échoué. Contrat de récupération : references/figma-execute.md. Listes de contrôle complètes : references/qa-and-recovery.md.

Clôture

• Capturez des captures d'écran finales pour chaque tableau muté et chaque membre de famille requis.
• Enregistrez les exceptions intentionnelles, les espaces réservés, les problèmes non résolus et les limites de portée.
• Mettez à jour le design.md et screens.md cibles lorsque l'autorité, les composants, les variables, les écrans, les tailles racines ou la dérive ont changé — y compris toute valeur résolue pendant la session.
• Écrivez une note datée sous docs/sessions/ pour tout travail significatif.

Respectez les protections documentées du fichier cible dans son design.md : originaux verrouillés ou protégés, styles ou états qui doivent rester supprimés, copie et langue qui doivent être préservées. Ne stockez jamais d'identifiants ni de jetons privés dans la mémoire du projet.

Pour les conseils externes derrière cette compétence, lisez references/research-sources.md.