Help us improve
Share bugs, ideas, or general feedback.
How this skill is triggered — by the user, by Claude, or both
Slash command
/figma:figma-use-slidesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill contains Slides-specific context for the `use_figma` MCP tool. The [figma-use](../figma-use/SKILL.md) skill provides foundational context for plugin API execution via MCP as well as the full Figma plugin API for more advanced use-cases that are not described here.
Orchestrates presentation creation from content planning to format-specific generation (HTML slides or PPTX). Invokes html-slides or pptx-slides skills for final output.
Generates self-contained HTML slide decks from briefs, notes, or topics. Supports 13 layouts, 8 style presets, inline editing, and PDF export.
Generates HTML slide decks for presentations with fixed 1920×1080 canvas, chapter-driven titles, slide-native type scale, and JS scaling. Activates when users request slide presentations.
Share bugs, ideas, or general feedback.
This skill contains Slides-specific context for the use_figma MCP tool. The figma-use skill provides foundational context for plugin API execution via MCP as well as the full Figma plugin API for more advanced use-cases that are not described here.
Always pass skillNames: "figma-use-slides" when calling use_figma for Slides operations. This is a logging parameter used to track skill usage — it does not affect execution.
create_new_file, a default light theme is automatically initialized. This theme is structural scaffolding — you should overwrite the theme's color variables and text styles with your own design direction for the deck you're building. Do not rely on or be influenced by the default light theme tokens.appendChild to the slide BEFORE setting x/y position. Slides have an internal coordinate origin; positioning before parenting causes silent offsets that produce broken/overlapping layouts. Do all property configuration after appending for safety. See slide-gotchas.md..fills, .effects, or layout properties on them. Only SLIDE nodes (type 'SLIDE') extend BaseFrameMixin. Exception: SLIDE_ROW.name IS settable — that's how plugins rename slide sections (e.g. slideRow.name = "Intro"). See slide-lifecycle.md.get_metadata does NOT work on Slides files. Use use_figma read-only scripts for validation. Return created node positions in closePlugin() output and verify no overlapping bounding boxes.figma.createPage() in Slides. It throws TypeError: figma.createPage no such property 'createPage' on the figma global object — createPage() is a Design-file API only (figma.com/design/...); the Slides URL is figma.com/slides/.... Use the slide grid (SLIDE_GRID / SLIDE_ROW / SLIDE) to organize deck structure instead — see slide-lifecycle.md and slide-grid.md.Not every task needs the same depth of design thinking. Before doing anything, identify which gear you're in:
For structural additions to existing decks: run the inspection scripts (below) and take screenshots before making changes. The answers to "what color story?" and "what type treatment?" are already in the file — your job is to read them and stay consistent. The design principles in slide-design.md describe what you're matching, not what you're choosing.
Before writing any Plugin API code for a new deck, decide what it should feel like. Figma users have high visual expectations — a deck that looks like it came out of a generic template generator will stand out for the wrong reasons.
When the user provides a link to a Figma file as a reference, study it before designing anything. What you extract depends on what the file is:
get_metadata does not work on Slides files. Use get_screenshot to capture individual slides for visual reference, and use_figma with the reference file's fileKey to run read-only scripts that extract theme variables, color palettes, font choices, and layout patterns.get_design_context gives you comprehensive design data — colors, typography, layout structure. get_screenshot gives you visual reference. Use both.What to look for in a reference file: the color palette (which hue leads, what the accent is, how dark/light backgrounds are used), the type choices (families, weights, how hierarchy is handled), the spatial habits (where content anchors, how much whitespace, whether things bleed off edges), and any recurring motifs (shapes, line treatments, decorative elements). These are the decisions you inherit — everything else is yours.
How closely to follow the reference depends on what the user asked for. "Make it look like this" means replicate the design language with new content. "Use this for inspiration" means echo the character but make it your own. "Here's our brand deck" means extract the brand system and apply it consistently. When in doubt, stay closer to the reference — it's easier for a user to ask you to diverge than to ask you to undo invented choices that conflict with their brand.
Load slide-design.md for specific guidance on color, type, layout patterns, composition, and what to avoid. When you have a reference file or brand guidelines, treat slide-design.md's principles as defaults for the decisions the user didn't make — not as overrides for the ones they did.
A section is a horizontal row in the slide grid — every row is a section. Names show up in the editor (next to the row) and in Presenter View (so speakers can jump between groups). They're an organizational aid for whoever is editing the deck — the user owns where the breaks fall, not you.
"Organize this deck" is ambiguous — grouping, reordering, deduping, or restructuring. Read the deck before reaching for AskUserQuestion.
Default: propose, don't ask. Most decks have cues — title bookend, numbered use cases, repeated Before / After pairs, transition slides ("Then X enters the chat"), a Thank you. When cues exist, pick a sectioning and surface it in one confirmation message. Bounded calls inside the proposal (one Use Cases row vs. three, where a transition slide lives) are reversible — pick one and move on.
Fallback: ask when cues are absent. If slides are in arbitrary order or there's no spine, ask which ranges go together and what to call them. Don't slice by thirds as a substitute for reading.
Names should be short (1–3 words), concrete (Demo beats Show & tell), and consistent within a deck. Two to five sections is typical; more only for long or repeating decks. Names aren't slide titles — they help find a group, not describe its content.
getSlideGrid() returns SlideNode[][] — the inner arrays are plain JS arrays of slides, NOT SLIDE_ROW nodes. Setting .name on those arrays silently no-ops. To rename a section, traverse the node tree and set .name on the actual SLIDE_ROW:
const slideGrid = figma.currentPage.children.find(c => c.type === "SLIDE_GRID");
slideGrid.children[0].name = "Intro";
Speaker notes are the presenter's private companion to each slide. They appear in Presenter View (visible only to the speaker, not the audience) and serve as a script, cue sheet, or talking-points reference during a live presentation.
node.screenshot() for image-heavy, chart-heavy, or visually sparse slides when visual context matters, but don't screenshot every slide by default — images spend context budget.Speaker notes are for the presenter, not the audience. They should feel like a trusted colleague leaning over and whispering "here's what to say." Good notes:
slide.speakerNotes accepts a markdown string. Prefer bullet lists as the primary structure; bold is useful for emphasis on key phrases the presenter shouldn't skip. See slide-properties.md for the full list of supported (lists, bold, italic, strikethrough) and unsupported (headings, code blocks, inline code, links) markdown.
There is no dedicated read tool for Slides files yet. Use use_figma with read-only scripts for inspection, and get_screenshot / await node.screenshot() for visual context.
use_figma to discover what already exists — slides, text, components, naming conventions. The figma-use Section 6 "Inspect first" pattern applies here.get_metadata does NOT work on Slides files — it only supports figma (Design) editor type.console.log() output is NOT returned — only the return value comes back. Always return the data you need.get_screenshot for visual context — pass a valid nodeId to get a screenshot. You can also use await node.screenshot() inline within use_figma scripts.List all slides in the 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,
}))
);
Get text content from a specific slide:
// Read-only text inventory — skip invisible instance interiors for speed.
figma.skipInvisibleInstanceChildren = true;
const slide = figma.getNodeById("TARGET_SLIDE_ID");
// findAllWithCriteria uses an indexed type lookup — much faster than
// findAll(n => n.type === 'TEXT') on slides with many shapes/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,
}));
Load only the references your task needs:
getSlideGrid, setSlideGrid)speakerNotes, isSkippedSlide, focusedSlide, focusedNode, slideThemeId, InteractiveSlideElementNode)