use_figma — Skill Figma Plugin API pour Slides

Ce skill contient du contexte spécifique à 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 Figma plugin complète pour les cas d'usage plus avancés non décrits ici.

Toujours passer skillNames: "figma-use-slides" quand appeler use_figma pour des opérations Slides. C'est un paramètre de logging utilisé pour suivre l'usage du skill — cela n'affecte pas l'exécution.

Règles critiques (spécifiques à 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 structurel — tu devrais remplacer les variables de couleur et les styles de texte du thème par ta propre direction de design pour le deck que tu construis. Ne te fie pas au thème clair par défaut ni ne sois influencé par ses tokens.
MUST appendChild à la slide AVANT de définir la position x/y. Les Slides ont une origine de coordonnées interne ; le positionnement avant le parentage cause des décalages silencieux qui produisent des layouts cassés/chevauchants. Fais toute configuration de propriété après l'ajout pour plus de sécurité. Voir slide-gotchas.md.
SLIDE_GRID et SLIDE_ROW sont des nœuds opaques — n'accède pas à .fills, .effects, ou aux 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 slides (p. ex. slideRow.name = "Intro"). Voir slide-lifecycle.md.
get_metadata ne fonctionne PAS sur les fichiers Slides. Utilise des scripts read-only use_figma pour la validation. Retourne les positions des nœuds créés dans la sortie closePlugin() et vérifie qu'il n'y a aucun chevauchement des boîtes englobantes.

Réflexion de design

Pas chaque tâche n'a besoin de la même profondeur de réflexion de design. Avant de faire quoi que ce soit, identifie dans quel régime tu es :

Éditions de contenu/propriétés — changer du texte, échanger une couleur, mettre à jour un nombre, corriger l'alignement, redimensionner un élément. Saute la réflexion de design. Fais juste la modification et assortis ce qui est déjà là.
Ajouts structurels — ajouter des slides, retravailler le layout d'une section, changer la palette de couleurs du deck, introduire un nouvel élément visuel. La réflexion de design s'applique, mais en mode héritage : le deck existant est ton langage de design. Inspecte-le, assortis sa palette, sa typographie, ses habitudes spatiales et ses motifs. Étends le caractère existant du deck plutôt que de le réinventer.
Création de nouveau deck — construire un deck à partir de zéro ou à partir d'un fichier vierge. La réflexion de design complète s'applique comme décrit ci-dessous.

Pour les ajouts structurels aux decks existants : exécute les scripts d'inspection (ci-dessous) et prends 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 — ton travail est de les lire et de rester cohérent. Les principes de design dans slide-design.md décrivent ce que tu assortis, pas ce que tu choisis.

Processus de design de nouveau deck

Avant d'écrire du code Plugin API pour un nouveau deck, décide à quoi il devrait sembler. Les utilisateurs Figma ont des attentes visuelles élevées — un deck qui a l'air de sortir d'un générateur de template générique se remarquera pour les mauvaises raisons.

Lis 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 une plongée technique approfondie exigent tous des traitements visuels différents. Le design devrait être inséparable du contenu.
Cherche un langage de design. Avant d'inventer quoi que ce soit, regarde ce que l'utilisateur t'a déjà donné. Les directives de marque dans le prompt — palettes de couleurs, spécifications typographiques, règles de logo, descripteurs de tonalité — sont des décisions de design qui ont déjà été prises. Un lien vers un fichier Figma de référence est un langage de design que tu devrais étudier, pas juste parcourir. Plus les entrées de l'utilisateur sont spécifiques, moins tu devrais inventer de ton côté. Quand l'utilisateur fournit une référence, ton rôle passe de designer à interprète : extrais le langage de design et applique-le fidèlement au nouveau contenu.
Prends position — sur ce qui reste. Si l'utilisateur a fourni un système de marque complet, ta latitude créative est dans le layout, la cadence et la composition — pas dans la couleur ou la typographie. S'il t'a donné une seule slide de référence pour l'inspiration, tu as plus de marge mais devrais toujours écho son caractère. S'il ne t'a rien donné, alors tu possèdes chaque décision — choisis une histoire de couleur, un traitement typographique, une manière d'organiser l'espace, et suis-la sur chaque slide. Un deck avec une perspective claire (même une tranquille) se lit toujours mieux qu'un qui joue la sécurité sur chaque décision. La portée de « prendre position » est inversement proportionnelle à ce que l'utilisateur a fourni.
Donne-lui une signature. Chaque bon deck a au moins un élément que tu reconnaîtrais si tu le voyais hors de son contexte : une palette distinctive, une cadence de layout inattendue, un langage de formes récurrent. En travaillant à partir de directives de marque, la signature devrait provenir de ce langage de marque — amplifie quelque chose qui est déjà là plutôt que d'ajouter quelque chose d'étranger. En concevant à partir de zéro, décide 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, étudie-le avant de concevoir quoi que ce soit. Ce que tu extrais dépend de ce que le fichier est :

Un fichier Slides : get_metadata ne fonctionne pas sur les fichiers Slides. Utilise get_screenshot pour capturer des slides individuelles pour une référence visuelle, et use_figma avec la fileKey du fichier de référence pour exécuter des scripts read-only qui extraient les variables de thème, les palettes de couleurs, les choix de police et les modèles de layout.
Un fichier Design : get_design_context te donne des données de design complètes — couleurs, typographie, structure de layout. get_screenshot te donne une référence visuelle. Utilise les deux.

Ce qu'il faut chercher dans un fichier de référence : la palette de couleurs (quelle teinte mène, quel est l'accent, comment les fonds clair/foncé 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 tous les motifs récurrents (formes, traitements de lignes, éléments décoratifs). Ce sont les décisions que tu hérités — tout le reste est à toi.

À quel point suivre la référence dépend de ce que l'utilisateur a demandé. « Fais-le ressembler à ça » signifie répliquer le langage de design avec du nouveau contenu. « Utilise ça pour l'inspiration » signifie écho le caractère mais rends-le tien. « Voici notre brand deck » signifie extraire le système de marque et l'appliquer de manière cohérente. En cas de doute, reste plus proche de la référence — c'est plus facile pour un utilisateur de te demander de diverger que de te demander d'annuler des choix inventés qui entrent en conflit avec leur marque.

Charge slide-design.md pour des conseils spécifiques sur la couleur, la typographie, les modèles de layout, la composition, et ce à éviter. Quand tu as un fichier de référence ou des directives de marque, traite les principes de slide-design.md comme des défauts pour les décisions que l'utilisateur n'a pas prise — pas comme des remplacements pour celles qu'il a faites.

Sections

Une section est une rangée horizontale dans la grille de slides — chaque rangée est une section. Les noms apparaissent dans l'éditeur (à côté de la rangée) et dans Presenter View (pour que les présentateurs puissent sauter entre les groupes). C'est une aide organisationnelle pour quiconque édite le deck — l'utilisateur possède où les coupures se font, pas toi.

Quand on te demande d'organiser un deck

« Organise ce deck » est ambigu — regroupement, réordering, déduplication, ou restructuration. Lis le deck avant de recourir à AskUserQuestion.

Par défaut : propose, ne demande pas. La plupart des decks ont des indices — slide de titre bookend, cas d'usage numérotés, paires Avant / Après répétées, slides de transition (« Puis X arrive »), un Merci. Quand des indices existent, choisis une sectionnement et remonte-le dans un message de confirmation. Les appels bornés dans la proposition (une seule rangée Cas d'usage vs. trois, où vit une slide de transition) sont réversibles — choisis-en un et continue.

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

Nommage + portée

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

Renommer une section

getSlideGrid() retourne SlideNode[][] — les arrays intérieurs sont des arrays JS simples de slides, PAS des nœuds SLIDE_ROW. Définir .name sur ces arrays silencieusement ne fait rien. Pour renommer une section, traverse l'arbre de nœuds et définis .name sur la véritable SLIDE_ROW :

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

Inspecter les fichiers Slides

Il n'y a pas encore d'outil de lecture dédié pour les fichiers Slides. Utilise use_figma avec des scripts read-only pour l'inspection, et get_screenshot / await node.screenshot() pour le contexte visuel.

Inspecte avant de créer. Avant de créer quoi que ce soit, exécute un use_figma read-only pour découvrir ce qui existe déjà — slides, texte, composants, conventions de nommage. Le pattern figma-use Section 6 « Inspecte d'abord » s'applique ici.
get_metadata ne fonctionne PAS sur les fichiers Slides — il ne supporte que le type d'éditeur figma (Design).
La sortie de console.log() n'est PAS retournée — seule la valeur de return revient. Toujours return les données dont tu as besoin.
Utilise get_screenshot pour le contexte visuel — passe une nodeId valide pour obtenir une capture d'écran. Tu peux aussi utiliser await node.screenshot() en ligne dans les 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,
  }))
);

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

const slide = figma.getNodeById("TARGET_SLIDE_ID");
const textNodes = slide.findAll(n => n.type === "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

Charge seulement les références dont ta tâche a besoin :

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