use_figma — Skill Figma Plugin API pour Slides

Ce skill contient du contexte spécifique aux Slides pour l'outil MCP use_figma. Le skill figma-use fournit le contexte fondamental pour l'exécution de l'API plugin via MCP ainsi que l'API complète du plugin Figma pour les cas d'usage avancés non décrits ici.

Incluez toujours figma-use-slides dans le paramètre skillNames séparé par des virgules lors de l'appel de use_figma pour les opérations Slides. Si ce skill a été chargé via une ressource MCP, vous DEVEZ préfixer le nom par resource: (par exemple resource:figma-use-slides). Il s'agit d'un paramètre de journalisation utilisé pour suivre l'utilisation des skills — il n'affecte pas l'exécution.

Règles critiques (spécifiques aux Slides)

Les fichiers Slides nouvellement créés ont un thème clair par défaut. Quand un fichier Slides est créé via create_new_file, un thème clair par défaut est automatiquement initialisé. Ce thème est un échafaudage structural — vous devez remplacer les variables de couleur et les styles de texte du thème par votre propre direction de conception pour le deck que vous construisez. Ne vous appuyez pas sur les tokens de thème clair par défaut et ne vous laissez pas influencer par eux.
VOUS DEVEZ appendChild AVANT de définir x/y — pour chaque nœud, à chaque niveau d'imbrication. Les nœuds nouvellement créés sont silencieusement auto-parentés à un contexte de slide avec une position absolue (240, 240) (le GRID_PADDING de la grille de slide). Écrire x/y avant appendChild enregistre la valeur par rapport à cette origine cachée ; le nœud atterrit alors à (prévu − 240, prévu − 240) une fois que vous attachez le parent réel. Le bug est intermittent — certains frames du même script l'évitent, donc un test fonctionnel ne prouve pas que vous êtes sûr. Signature à reconnaître : si un nœud se retrouve à (−240, −240) de l'endroit où vous l'aviez positionné, votre code a défini x/y avant le dernier appendChild. Ne tentez PAS de compenser en rajoutant 240 — cela produit un résultat pire à la prochaine tentative. Corrigez l'ordre à la place. Voir slide-gotchas.md pour le motif helper qui rend l'ordre impossible à mauvais utiliser.
SLIDE_GRID et SLIDE_ROW sont des nœuds opaques — n'accédez pas à .fills, .effects, ou les propriétés de layout sur eux. Seuls les nœuds SLIDE (type 'SLIDE') étendent BaseFrameMixin. Exception : SLIDE_ROW.name EST modifiable — c'est ainsi que les plugins renomment les sections de slide (par exemple slideRow.name = "Intro"). Voir slide-lifecycle.md.
get_metadata NE fonctionne PAS sur les fichiers Slides. Utilisez des scripts en lecture seule use_figma pour la validation. Retournez les positions des nœuds créés dans la sortie closePlugin() et vérifiez qu'aucune boîte englobante ne se chevauche.
N'appelez PAS figma.createPage() dans Slides. Cela lève TypeError: figma.createPage no such property 'createPage' on the figma global object — createPage() est une API Design-file uniquement (figma.com/design/...) ; l'URL Slides est figma.com/slides/.... Utilisez la grille de slide (SLIDE_GRID / SLIDE_ROW / SLIDE) pour organiser la structure du deck à la place — voir slide-lifecycle.md et slide-grid.md.
Ne supprimez jamais les slides existantes pour les reconstruire. Quand on vous demande d'améliorer, de repenser ou de redonner du style à un deck, modifiez les slides existantes en place. Supprimez uniquement les slides quand l'utilisateur demande explicitement de « recommencer » ou de « recommencer de zéro ».

Réflexion de conception

Chaque tâche ne demande pas le même niveau de réflexion de conception. Avant de faire quoi que ce soit, identifiez dans quel registre vous êtes :

Modifications de contenu/propriétés — changer du texte, permuter une couleur, mettre à jour un nombre, corriger un alignement, redimensionner un élément. Passez la réflexion de conception. Faites juste la modification et adaptez-vous à ce qui est déjà là.
Ajouts structurels — ajouter des slides, refondre la disposition d'une section, changer la palette de couleurs du deck, introduire un nouvel élément visuel. Cela inclut les demandes d'« améliorer », « repenser » ou « redonner du style » à un deck — ce sont des modifications sur place de ce qui existe déjà, pas un nouveau deck. La réflexion de conception s'applique, mais en mode héritage : le deck existant est votre langage de conception. Inspectez-le, adaptez sa palette, sa typographie, ses habitudes spatiales et ses motifs. Étendez le caractère existant du deck plutôt que de le réinventer.
Création d'un nouveau deck — construire un deck de zéro ou à partir d'un fichier vierge. La réflexion de conception complète s'applique tel que décrit ci-dessous.

Pour les ajouts structurels aux decks existants : exécutez les scripts d'inspection (ci-dessous) et prenez des captures d'écran avant de faire des modifications. Les réponses à « quelle histoire de couleur ? » et « quel traitement typographique ? » sont déjà dans le fichier — votre travail est de les lire et rester cohérent. Les principes de conception dans slide-design.md décrivent ce que vous adaptez, pas ce que vous choisissez.

Processus de conception d'un nouveau deck

Avant d'écrire n'importe quel code Plugin API pour un nouveau deck, décidez ce qu'il devrait donner comme impression. Les utilisateurs Figma ont de grandes attentes visuelles — un deck qui ressemble à la sortie d'un générateur de template générique sera remarqué pour les mauvaises raisons.

Lisez le brief. Qu'est-ce que le deck communique, et à qui ? Un pitch d'investisseur, une rétrospective d'équipe, un lancement de produit et un deep-dive technique demandent tous des traitements visuels différents. La conception devrait être inséparable du contenu.
Vérifiez un langage de conception. Avant d'inventer quoi que ce soit, regardez ce que l'utilisateur vous a déjà donné. Les directives de marque dans le prompt — palettes de couleurs, spécifications typographiques, règles de logo, descripteurs de ton — sont des décisions de conception qui ont déjà été prises. Un lien vers un fichier Figma de référence est un langage de conception que vous devriez étudier, pas juste parcourir. Plus les entrées de l'utilisateur sont spécifiques, moins vous devriez inventer de votre côté. Quand l'utilisateur fournit une référence, votre rôle passe de concepteur à interprète : extrayez le langage de conception et appliquez-le fidèlement au nouveau contenu.
Prenez position — sur ce qui reste. Si l'utilisateur a fourni un système de marque complet, votre latitude créative se situe dans la disposition, la cadence et la composition — pas dans la couleur ou la typographie. S'il vous a donné une seule slide de référence pour l'inspiration, vous avez plus de marge de manœuvre mais devriez quand même faire écho à son caractère. S'il ne vous a rien donné, alors vous êtes responsable de chaque décision — choisissez une histoire de couleur, un traitement typographique, une façon d'organiser l'espace, et suivez-la à travers chaque slide. Un deck avec une perspective claire (même discrète) se lit toujours mieux qu'un qui joue la sécurité sur chaque décision. L'étendue de « prendre position » est inversement proportionnelle à ce que l'utilisateur a fourni.
Donnez-lui une signature. Chaque bon deck a au moins un élément que vous reconnaîtriez si vous le voyiez hors contexte : une palette distinctive, une cadence de disposition inattendue, un langage de forme récurrent. Quand vous travaillez à partir de directives de marque, la signature devrait provenir de ce langage de marque — amplifiez quelque chose qui existe déjà plutôt que d'ajouter quelque chose d'étranger. Quand vous concevez de zéro, décidez quelle est la signature avant de commencer à construire.

Lire un fichier de référence

Quand l'utilisateur fournit un lien vers un fichier Figma comme référence, étudiez-le avant de concevoir quoi que ce soit. Ce que vous en extrayez dépend de ce qu'est le fichier :

Un fichier Slides : get_metadata ne fonctionne pas sur les fichiers Slides. Utilisez get_screenshot pour capturer des slides individuelles pour la référence visuelle, et use_figma avec le fileKey du fichier de référence pour exécuter des scripts en lecture seule qui extraient les variables de thème, les palettes de couleurs, les choix de police et les motifs de disposition.
Un fichier Design : get_design_context vous donne des données de conception complètes — couleurs, typographie, structure de disposition. get_screenshot vous donne une référence visuelle. Utilisez les deux.

Ce qu'il faut chercher dans un fichier de référence : la palette de couleurs (quelle teinte domine, quelle est l'accent, comment les fonds clairs/foncés sont utilisés), les choix typographiques (familles, poids, comment la hiérarchie est gérée), les habitudes spatiales (où le contenu s'ancre, combien d'espace blanc, si les choses débordent des bords), et tout motif récurrent (formes, traitements de lignes, éléments décoratifs). Ce sont les décisions que vous héritez — tout le reste est le vôtre.

La proximité avec laquelle suivre la référence dépend de ce que l'utilisateur a demandé. « Faites en sorte que cela ressemble à ceci » signifie répliquer le langage de conception avec un nouveau contenu. « Utilisez ceci pour l'inspiration » signifie faire écho au caractère mais le rendre vôtre. « Voici notre deck de marque » signifie extraire le système de marque et l'appliquer de manière cohérente. En cas de doute, restez plus proche de la référence — il est plus facile pour un utilisateur de vous demander de diverger que de vous demander d'annuler les choix inventés qui entrent en conflit avec sa marque.

Chargez slide-design.md pour des conseils spécifiques sur la couleur, la typographie, les motifs de disposition, la composition et ce qu'il faut éviter. Quand vous avez un fichier de référence ou des directives de marque, traitez les principes de slide-design.md comme des défauts pour les décisions que l'utilisateur n'a pas prises — pas comme des remplacements pour celles qu'il a prises.

Workflow de construction de deck

Quand vous construisez un nouveau deck de 5 slides ou plus, utilisez ce workflow en deux phases. Il remplace le workflow incremental général de figma-use Section 6 pour la construction de deck spécifiquement — les principes s'appliquent toujours, mais la cadence change.

Phase 1 — Conception et planification

Complétez le processus de réflexion de conception ci-dessus (lisez le brief, vérifiez un langage de conception, prenez position, donnez-lui une signature), puis avant d'écrire n'importe quel code use_figma, produisez un plan de slide couvrant l'ensemble du deck :

Plan slide par slide. Pour chaque slide : son objectif/contenu, approche de disposition décrite en termes spatiaux (par exemple « titre ancré en haut à gauche, carte spec remplissant le tiers droit, cercle décoratif débordant du bord haut droit »), et traitement du fond (sombre/clair/dégradé). Ne calculez PAS les coordonnées en pixels pendant la planification — décrivez les dispositions en termes spatiaux. Les mathématiques de coordonnées se font pendant la génération de code.
Constantes partagées. Déclarez les familles et styles de police que vous utiliserez, la palette de couleurs comme rôles nommés (primaire, accent, bgDark, surface, textPrimary, textMuted, etc.), et le motif récurrent ou élément signature.
Contrôle de la variété de disposition. Lisez les plans de slide en séquence. Si les descriptions de disposition semblent répétitives — « deux colonnes, deux colonnes, grille, deux colonnes » — réarrangez avant de construire. C'est le moment le moins cher pour diversifier. Voir slide-design.md pour les anti-motifs.
Code préambule. Écrivez le préambule réutilisable que vous collerez en haut de chaque script de construction : un objet palette de couleurs const C = { ... }, un bloc de chargement de police Promise.all([...]), et les helpers addFrame/addText/addRect de slide-gotchas.md.

Phase 2 — Construction

Exécutez le plan en grands lots. L'objectif est de minimiser le nombre de cycles penser-puis-construire — pas de minimiser les éléments par script.

3–5 slides par appel use_figma. Les slides structurellement similaires (par exemple une série de slides de features de produit) peuvent aller dans le même lot. Chaque slide est un sous-arbre isolé — les dépendances inter-slides n'existent pas, donc les grands lots sont sûrs.
Ne re-planifiez PAS entre les lots. La conception a été décidée en Phase 1. Si un lot réussit et passe la validation, passez au lot suivant immédiatement. Seule une re-planification si un lot échoue ou produit un problème visuel qui demande de changer l'approche.
Collez le préambule de code (couleurs, polices, helpers) en haut de chaque script de construction. Copiez-le de la Phase 1 textuellement — ne le re-dérivez pas.
Validez chaque lot avec le script de validation de lot déterministe de slide-gotchas.md. Cela vérife les éléments qui se chevauchent, l'écrêtage de texte et les nœuds hors limites en ~3 secondes. Si la vérification réussit, procédez sans capture d'écran. Si elle échoue, prenez une capture d'écran des slides affectées et corrigez avant de continuer.
Screenshot aux points de contrôle uniquement — après le premier lot (valide le système visuel : couleurs, typographie, direction de conception), et après le lot final (qualité générale). Prenez une capture d'écran de 1–2 slides représentatives par point de contrôle en utilisant await slide.screenshot() en ligne, pas des appels get_screenshot séparés.
Retournez tous les IDs de nœud créés de chaque script de construction, comme toujours.

Sections

Une section est une ligne horizontale dans la grille de slide — chaque ligne est une section. Les noms apparaissent dans l'éditeur (à côté de la ligne) et en Presenter View (afin que les présentateurs puissent sauter entre les groupes). C'est une aide organisationnelle pour quiconque édite le deck — l'utilisateur détient où sont les coupures, pas vous.

Quand on vous demande d'organiser un deck

« Organiser ce deck » est ambigu — regroupement, réorganisation, déduplication ou restructuration. Lisez le deck avant de recourir à AskUserQuestion.

Par défaut : proposez, ne demandez pas. La plupart des decks ont des indices — séparation de titre, cas d'usage numérotés, paires Avant/Après répétées, slides de transition (« Puis X entre en jeu »), un Merci. Quand les indices existent, choisissez une sectionnement et surfacez-le dans un message de confirmation. Les appels limités à l'intérieur de la proposition (une ligne Use Cases vs trois, où vit une slide de transition) sont réversibles — choisissez-en un et passez au suivant.

Secours : demandez quand les indices sont absents. Si les slides sont dans un ordre arbitraire ou il n'y a pas de colonne vertébrale, demandez quelles plages vont ensemble et comment les appeler. Ne divisez pas par tiers comme substitut à la lecture.

Dénomination et portée

Les noms doivent être courts (1–3 mots), concrets (Demo bat Show & tell), et cohérents dans un deck. Deux à cinq sections est typique ; plus uniquement pour les decks longs ou répétitifs. Les noms ne sont pas les titres de slide — ils aident à trouver un groupe, pas à décrire son contenu.

Renommer une section

getSlideGrid() retourne SlideNode[][] — les tableaux internes sont des tableaux JS ordinaires de slides, PAS des nœuds SLIDE_ROW. Définir .name sur ces tableaux fonctionne silencieusement en no-op. Pour renommer une section, parcourez l'arbre de nœud et définissez .name sur le SLIDE_ROW réel :

const slideGrid = figma.currentPage.children.find(c => c.type === "SLIDE_GRID");
slideGrid.children[0].name = "Intro";

Notes du présentateur

Les notes du présentateur sont le compagnon privé du présentateur pour chaque slide. Elles apparaissent en Presenter View (visibles uniquement par le présentateur, pas l'audience) et servent de script, feuille de repères ou référence de points clés lors d'une présentation en direct.

Quand écrire les notes du présentateur

Quand demandé : Si l'utilisateur demande les notes du présentateur, notes du présentateur, points clés ou un script pour un deck, écrivez les notes pour chaque slide qui a du contenu substantiel (sautez les séparateurs de section ou les slides purement décoratives sauf s'il y a quelque chose à dire).
Decks prêts pour la présentation : Si l'utilisateur demande explicitement un deck prêt pour une présentation en direct, les notes du présentateur sont utiles. Ajoutez-les quand elles aident le présentateur à comprendre la cadence, les transitions ou le contexte qui n'est pas visible sur la slide.
Slides creuses ou visuelles : Si une slide est construite autour d'un graphique, une image, une métaphore ou une question provocante, les notes peuvent aider à expliquer ce que le présentateur devrait dire. Utilisez des captures d'écran ou node.screenshot() pour les slides riches en images, riches en graphiques ou visuellement creuses quand le contexte visuel compte, mais ne prenez pas de capture d'écran de chaque slide par défaut — les images dépensent du budget de contexte.
N'ajoutez pas les notes sans y être invité : Pour les éditions normales de slide, le travail de disposition ou les mises à jour des decks existants, ne remplissez pas les notes du présentateur sauf si l'utilisateur les demande. L'ajout de notes change le flux de présentation et peut surprendre le propriétaire du deck.

À quoi ressemblent les bonnes notes du présentateur

Les notes du présentateur s'adressent au présentateur, pas l'audience. Elles devraient donner l'impression d'un collègue de confiance se penchant et chuchotant « voici ce qu'il faut dire ». Les bonnes notes :

Complètent la slide, ne la répètent pas. Si la slide dit « Le chiffre d'affaires a augmenté de 40 % », les notes ne devraient pas dire « Le chiffre d'affaires a augmenté de 40 % ». Elles devraient dire pourquoi il a augmenté, ce que l'audience devrait retenir ou quelle question cela soulève généralement.
Sont concises et faciles à scanner. Un présentateur jetant un coup d'œil au milieu d'une phrase doit retrouver sa place instantanément. Utilisez des listes à puces courtes, pas des paragraphes denses. Chaque point devrait être une idée.
Incluent des transitions. Les meilleures notes disent au présentateur comment passer entre les slides : « Une fois les applaudissements calmés... » ou « Cela s'appuie sur le point précédent — renvoyez à la figure de 40 % ».
Portent le contexte que la slide ne peut pas. Sources de données (« Source : métriques internes Q4 FY25, pas encore publiques »), avertissements (« Sautez cette slide si le CFO est dans la salle »), indices de synchronisation (« Ceci est le milieu — vous devriez être à ~10 minutes »), et questions anticipées (« Ils poseront des questions sur les marges — voir la slide d'appendice 14 »).
Correspondent au registre de la présentation. Les notes pour un pitch d'investisseur sont précises et répétées. Les notes pour une rétrospective d'équipe sont décontractées et flexibles. Les notes pour une keynote pourraient inclure des directions de scène. Adaptez le ton au contexte.

Ce qu'il faut éviter dans les notes du présentateur

Scripts complets : Les notes en murs de texte encouragent la lecture verbatim, ce qui donne une mauvaise présentation. Si l'utilisateur demande explicitement un script, écrivez-en un, mais par défaut préférez les listes à puces.
Formatage pour l'audience : Les notes ne sont pas visibles par l'audience. Ne les optimisez pas pour la lisibilité par les non-présentateurs.
Redondance avec la slide : Si la slide s'explique d'elle-même (« Merci » avec les informations de contact), les notes ne sont pas nécessaires. C'est acceptable de laisser les notes d'une slide vides.

Formatage

slide.speakerNotes accepte une chaîne markdown. Préférez les listes à puces comme structure primaire ; le gras est utile pour l'accent sur les phrases clés que le présentateur ne devrait pas sauter. Voir slide-properties.md pour la liste complète du markdown supporté (listes, gras, italique, barré) et non supporté (titres, blocs de code, code inline, liens).

Inspection des fichiers Slides

Il n'y a pas encore d'outil de lecture dédié aux fichiers Slides. Utilisez use_figma avec des scripts en lecture seule pour l'inspection, et get_screenshot / await node.screenshot() pour le contexte visuel.

Inspectez avant de créer. Avant de créer quoi que ce soit, exécutez une use_figma en lecture seule pour découvrir ce qui existe déjà — slides, texte, composants, conventions de dénomination. Le motif « Inspect first » (Inspectez d'abord) de figma-use Section 6 s'applique ici.
get_metadata NE fonctionne PAS sur les fichiers Slides — il supporte uniquement le type d'éditeur figma (Design).
La sortie console.log() N'EST PAS retournée — seule la valeur return revient. Retournez toujours les données dont vous avez besoin.
Utilisez get_screenshot pour le contexte visuel — passez un nodeId valide pour obtenir une capture d'écran. Vous pouvez aussi utiliser await node.screenshot() en ligne dans des scripts use_figma.

Scripts d'inspection rapides

Lister toutes les slides du deck :

const grid = figma.getSlideGrid();
return grid.map((row, rowIdx) =>
  row.map((slide, colIdx) => ({
    id: slide.id,
    name: slide.name,
    row: rowIdx,
    col: colIdx,
    isSkipped: slide.isSkippedSlide,
    speakerNotes: slide.speakerNotes,
  }))
);

Obtenir le contenu texte d'une slide spécifique :

const slide = figma.getNodeById("TARGET_SLIDE_ID");
// findAllWithCriteria utilise une recherche de type indexée — beaucoup plus rapide que
// findAll(n => n.type === 'TEXT') sur les slides avec beaucoup de formes/images.
const textNodes = slide.findAllWithCriteria({ types: ["TEXT"] });
const fontsToLoad = new Set();
for (const t of textNodes) {
  if (t.fontName !== figma.mixed) {
    fontsToLoad.add(JSON.stringify(t.fontName));
  } else {
    const segments = t.getStyledTextSegments(["fontName"]);
    for (const seg of segments) fontsToLoad.add(JSON.stringify(seg.fontName));
  }
}
for (const f of fontsToLoad) {
  await figma.loadFontAsync(JSON.parse(f));
}
return textNodes.map(t => ({
  id: t.id,
  name: t.name,
  characters: t.characters,
  x: t.x,
  y: t.y,
  width: t.width,
  height: t.height,
}));

Docs de référence

Chargez uniquement les références dont votre tâche a besoin :

slide-gotchas — Pièges spécifiques à Slides (offsets de coordonnées, types de nœuds opaques, contournements de validation)
slide-lifecycle — Créer, cloner, supprimer et réorganiser les slides et lignes de slides
slide-grid — Travailler avec la disposition de la grille de slide (getSlideGrid, setSlideGrid)
slide-content — Construire du contenu dans les slides (texte, formes, auto-layout — SlideNode étend BaseFrameMixin)
slide-properties — Propriétés spécifiques aux Slides (speakerNotes, isSkippedSlide, focusedSlide, focusedNode, slideThemeId, InteractiveSlideElementNode)
slide-design — Principes de conception pour les decks visuellement intéressants et variés (stratégie de couleur, typographie, variété de disposition, composition spatiale, anti-motifs)