figma-generate-design

Build / Update Screens and Views from Design System

Use this skill to create or update screens, views, and multi-section UI containers in Figma by reusing the published design system — components, variables, and styles — rather than drawing primitives with hardcoded values. This includes full pages, modals, dialogs, drawers, sidebars, panels, and any composed view with multiple sections. The key insight: the Figma file likely has a published design system with components, color/spacing variables, and text/effect styles that correspond to the codebase's UI components and tokens. Find and use those instead of drawing boxes with hex colors.

MANDATORY: You MUST also load figma-use before any use_figma call. That skill contains critical rules (color ranges, font loading, etc.) that apply to every script you write.

Always include figma-generate-design in the comma-separated skillNames parameter when calling use_figma as part of this skill. If this skill was loaded via an MCP resource, you MUST prefix the name with resource: (e.g. resource:figma-generate-design). This is a logging parameter — it does not affect execution.

Skill Boundaries

• Use this skill when the deliverable is a composed Figma view (new or updated) — full-page screens, modals, dialogs, drawers, sidebars, panels, or any multi-section container — built from design system component instances.
• If the user wants to create new reusable components or variants, use figma-use directly.
• If the user wants to write Code Connect mappings, switch to figma-code-connect.

Prerequisites

• Figma MCP server must be connected
• The target Figma file must have a published design system with components (or access to a team library)
• User must provide a target Figma file (URL or fileKey). If they don't have one yet, invoke /figma-create-new-file (or call create_new_file) first and reuse the returned file_key. Both use_figma and generate_figma_design require an existing fileKey.
• Source code or description of the screen/view to build/update

Parallel Workflow with generate_figma_design (Web Apps Only)

When building a screen from a web app that can be rendered in a browser, the best results come from running both approaches in parallel:

1. In parallel:
   • Start building the screen using this skill's workflow (use_figma + design system components) against the target Figma file (fileKey).
   • Run generate_figma_design against the same fileKey to capture a pixel-perfect screenshot of the running web app into that file. generate_figma_design always requires fileKey — if the user does not yet have a Figma file, first invoke /figma-create-new-file (or call the create_new_file MCP tool) to get one, and reuse that file_key for both this skill and the capture.
2. Once both complete: Update the use_figma output to match the pixel-perfect layout from the generate_figma_design capture. The capture provides the exact spacing, sizing, and visual treatment to aim for, while your use_figma output has proper component instances linked to the design system. If the capture contains images, transfer them to your use_figma output by copying imageHash values from the capture's image fills (see Step 5 for details).
3. Once confirmed looking good: Delete the generate_figma_design output — it was only used as a visual reference.

This combines the best of both: generate_figma_design gives pixel-perfect layout accuracy, while use_figma gives proper design system component instances that stay linked and updatable.

This parallel workflow is MANDATORY when the source contains images. The use_figma Plugin API cannot fetch external image URLs — it can only set image fills by copying imageHash values from nodes already in the file. generate_figma_design rasterizes all visible images into Figma, providing the hashes you need. If you skip the capture when images are present, image frames will be left blank.

For non-web apps (iOS, Android, etc.) or when updating existing screens, use the standard workflow below.

Required Workflow

Follow these steps in order. Do not skip steps.

Hard gates — forbidden shortcuts:

• Forbidden: search_design_system for component keys until 2a-i is complete and 2a-ii is attempted or logged N/A (e.g. "empty file, no existing screens").
• Forbidden: Any use_figma call that mutates the canvas (Step 3+) until all Step 2 rows in the checklist below are filled in.

Step 1: Understand the Deliverable

Before touching Figma, understand what you're building:

1. If building from code, read the relevant source files to understand the structure, sections, and which components are used.
2. Identify the major sections of the view (e.g., for a page: Header, Hero, Content Panels, Footer; for a modal: Title Bar, Form Sections, Action Bar; for a sidebar: Navigation, Content Area, Footer Actions).
3. For each section, list the UI components involved (buttons, inputs, cards, navigation pills, accordions, etc.).
4. Identify the product's font family from the source. Do not default to Inter. Find which typeface the product uses before writing any script. See references/discover-product-font.md for where to look (CSS variables, component files) and how to resolve messy Figma font names.
5. Check whether the view contains any images (e.g., <img>, <Image>, background images, product photos, avatars, icons loaded from URLs). If it does and this is a web app, you must run the parallel generate_figma_design capture workflow — start it immediately alongside Step 2 so the capture runs while you discover components. See "Parallel Workflow with generate_figma_design" above.

Step 2: Collect Component Keys, Variables, and Styles

You need three things from the design system: components (buttons, cards, etc.), variables (colors, spacing, radii), and styles (text styles, effect styles like shadows). Don't hardcode hex colors or pixel values when design system tokens exist.

2a: Discover components

2a-i — REQUIRED: Check Code Connect for needed components. Starting from the component list you built in Step 1, check whether each component has a Code Connect file in the codebase. Code Connect files live next to the component source and are named by platform:

• TypeScript/JS: *.figma.ts, *.figma.js
• React (parser-based): *.figma.tsx
• Kotlin/Compose: .kt files containing @FigmaConnect
• Swift: .swift files containing FigmaConnect

For each component you need (e.g., Button, Card, Input), search for its Code Connect file — glob or grep by component name (e.g., **/Button.figma.tsx, **/Card.figma.ts). Only read files that match components you actually need.

From each matching Code Connect file, extract the Figma component URL. Parse fileKey and nodeId from the URL (convert hyphens to colons: 123-456 → 123:456). Then resolve component keys via use_figma:

Example: Code Connect file contains // url=https://figma.com/design/ABC123/File?node-id=609-35535. Parse fileKey = ABC123, nodeId = 609:35535. Run use_figma against the library file (fileKey ABC123, not the target file) to resolve the key:

const node = await figma.getNodeByIdAsync("609:35535");
const set = node?.parent?.type === "COMPONENT_SET" ? node.parent : node;
return { componentKey: set.key };

Batch multiple lookups in a single call. Use the returned keys with importComponentSetByKeyAsync() in Step 4.

Mark resolved components. If all components are resolved, skip 2a-ii and 2a-iii. If none of the needed components have Code Connect files, proceed to 2a-ii.

2a-ii — REQUIRED if unresolved components remain: Inspect existing screens. Check if the target file already contains screens using the same design system. A single use_figma call that walks an existing frame's instances gives you an exact, authoritative component map:

Match results against your unresolved components. Mark any newly resolved. If all components are resolved, skip 2a-iii.

2a-iii — LAST RESORT: search_design_system. Only if components remain unresolved after completing both 2a-i and 2a-ii.

Before searching, call get_libraries to discover which libraries are available for the file. This returns two lists: libraries already added to the file and libraries available to add (community UI kits and org libraries). Each entry includes a libraryKey you can pass to search_design_system via the includeLibraryKeys param to scope your search to specific libraries instead of searching across everything.

Org libraries in libraries_available_to_add are paginated (20 per page). When libraries_available_to_add_next_offset is non-null, more org libraries are available — call get_libraries again with offset set to that value to fetch the next page. Community UI kits only appear on the first page. If the user names a specific library you don't see in the current page, page further before giving up.

This is especially useful when the file has many libraries and you want targeted results (e.g. searching only within "iOS 26" or "Material 3" instead of getting matches from every library).

Search broadly — try multiple terms and synonyms (e.g., "button", "input", "nav", "card", "accordion", "header", "footer", "tag", "avatar", "toggle", "icon", etc.). Use includeComponents: true to focus on components.

Include component properties in your map — you need to know which TEXT properties each component exposes for text overrides. Create a temporary instance, read its componentProperties (and those of nested instances), then remove the temp instance.

Example component map with property info:

2b: Discover variables (colors, spacing, radii)

Inspect existing screens first (same as components). Or use search_design_system with includeVariables: true.

WARNING: Two different variable discovery methods — do not confuse them.

• use_figma with figma.variables.getLocalVariableCollectionsAsync() — returns only local variables defined in the current file. If this returns empty, it does not mean no variables exist. Remote/published library variables are invisible to this API.
• search_design_system with includeVariables: true — searches across all linked libraries, including remote and published ones. This is the correct tool for discovering design system variables.

Never conclude "no variables exist" based solely on getLocalVariableCollectionsAsync() returning empty. Always also run search_design_system with includeVariables: true to check for library variables before deciding to create your own.

Query strategy: search_design_system matches against variable names (e.g., "Gray/gray-9", "core/gray/100", "space/400"), not categories. Run multiple short, simple queries in parallel rather than one compound query:

• Primitive colors: "gray", "red", "blue", "green", "white", "brand"
• Semantic colors: "background", "foreground", "border", "surface", "text"
• Spacing/sizing: "space", "radius", "gap", "padding"

If initial searches return empty, try shorter fragments or different naming conventions — libraries vary widely ("grey" vs "gray", "spacing" vs "space", "color/bg" vs "background").

Inspect an existing screen's bound variables for the most authoritative results:

For library variables (remote = true), import them by key with figma.variables.importVariableByKeyAsync(key). For local variables, use figma.variables.getVariableByIdAsync(id) directly.

See variable-patterns.md for binding patterns.

2c: Discover styles (text styles, effect styles)

Search for styles using search_design_system with includeStyles: true and terms like "heading", "body", "shadow", "elevation". Or inspect what an existing screen uses:

Import library styles with figma.importStyleByKeyAsync(key), then apply with node.textStyleId = style.id or node.effectStyleId = style.id.

See text-style-patterns.md and effect-style-patterns.md for details.

Step 3: Create the Wrapper Frame First

Do NOT build sections as top-level page children and reparent them later — moving nodes across use_figma calls with appendChild() silently fails and produces orphaned frames. Instead, create the wrapper first, then build each section directly inside it.

Create the wrapper in its own use_figma call. Position it away from existing content and return its ID:

Step 4: Build Each Section Inside the Wrapper

This is the most important step. Build one section at a time, each in its own use_figma call. At the start of each script, fetch the wrapper by ID and append new content directly to it.

After each section, validate with get_screenshot before moving on. Look closely for cropped/clipped text (line heights cutting off content) and overlapping elements — these are the most common issues and easy to miss at a glance.

Override instance text with setProperties()

Component instances ship with placeholder text ("Title", "Heading", "Button"). Use the component property keys you discovered in Step 2 to override them with setProperties() — this is more reliable than direct node.characters manipulation. See component-patterns.md for the full pattern.

For nested instances that expose their own TEXT properties, call setProperties() on the nested instance:

Only fall back to direct node.characters for text that is NOT managed by any component property.

Read source code defaults carefully

When translating code components to Figma instances, check the component's default prop values in the source code, not just what's explicitly passed. For example, <Button size="small">Register</Button> with no variant prop — check the component definition to find variant = "primary" as the default. Selecting the wrong variant (e.g., Neutral instead of Primary) produces a visually incorrect result that's easy to miss.

What to build manually vs. import from design system

Never hardcode hex colors or pixel spacing when a design system variable exists. Use setBoundVariable for spacing/radii and setBoundVariableForPaint for colors. Apply text styles with node.textStyleId and effect styles with node.effectStyleId.

Componentize repeated and reusable elements (required)

Componentization is part of the default workflow, not an optional follow-up. Produce a componentized structure on the first pass; do not emit a flat tree of one-off frames and wait for a second "now make it componentized" prompt.

• Design-system instances are already componentized (Step 2). Prefer them.
• For anything the design system does not cover that repeats or maps to a reusable source component, create a local component once with figma.createComponent() and place instances, instead of hand-building N near-identical frames. One source component maps to one Figma main component.

See references/componentization.md for the build-once-place-instances pattern and code.

Icons: import the SVG, never reconstruct from rotated primitives

Icons are the main exception to the build-manually-vs-import split above. If the design system exposes an icon as a component, instance it (a single INSTANCE_SWAP property, not a variant per icon). Otherwise — most commonly when grabbing an icon from the codebase to place or replace it in Figma — import the icon's SVG source directly as a vector node. This is the primary, default path for icons; do not redraw them.

1. Get the SVG from the codebase. Read the icon's source — inline <svg>, the imported .svg asset, or the icon-library entry — and pass that exact SVG string. Prefer the codebase's own SVG over hand-authoring one.
2. Import with figma.createNodeFromSvg(svgString), which returns a FrameNode of editable vector paths. The SVG string must include a viewBox plus explicit width/height (e.g. <svg width="24" height="24" viewBox="0 0 24 24" ...>). Without width/height it falls back to the viewBox size, which is often smaller than the slot — the usual cause of "the icon didn't size properly."
3. Size it to the slot. createNodeFromSvg frames scale their contents on resize, so icon.resize(size, size) fits the whole icon (stroke weight included) to the target box. Equivalently author width/height equal to the target. Match the source's icon size — commonly 16/20/24px.
4. Never reconstruct an icon from rotated line/rect/ellipse primitives. Figma's line rotation is unreliable in the use_figma context and produces broken, mis-rotated icons (a chevron collapses into a blob, an arrowhead detaches from its shaft). Importing the SVG is both more reliable and more editable.

Codebase SVGs usually use currentColor (e.g. stroke="currentColor" / fill="currentColor"), which createNodeFromSvg imports as black — it does not inherit the parent's color. Set the intended color after import: substitute the literal color into the SVG string before importing, or bind the imported vector fills/strokes to a design-system color variable with setBoundVariableForPaint (same as any paint). To turn an imported SVG into a reusable icon component (for INSTANCE_SWAP), see figma-generate-library → Creating Icon Components and the INSTANCE_SWAP pattern.

Step 5: Validate the Full View and Transfer Images

After composing all sections, call get_screenshot on the wrapper frame and compare against the source. Fix any issues with targeted use_figma calls — don't rebuild the entire view.

Screenshot individual sections, not just the full view. A full-view screenshot at reduced resolution hides text truncation, wrong colors, and placeholder text that hasn't been overridden. Take a screenshot of each section by node ID to catch:

• Cropped/clipped text — line heights or frame sizing cutting off descenders, ascenders, or entire lines
• Overlapping content — elements stacking on top of each other due to incorrect sizing or missing auto-layout
• Placeholder text still showing ("Title", "Heading", "Button")
• Truncated content from layout sizing bugs
• Wrong component variants (e.g., Neutral vs Primary button)
• Wrong font family — text rendered in a different typeface than the product uses (e.g. Inter where the product is SF Pro). The script ran without error, so this is invisible at a glance; assert it explicitly (see "Assert the font family is correct" below)
• Blank image placeholders — if images are missing, you need to transfer them from the generate_figma_design capture (see below)

Assert the font family is correct

You MUST explicitly assert that rendered text uses the product font(s) identified in Step 1, and treat any mismatch as a failed validation. Do not assume a successfully loaded font is the correct font: loading Inter when the product uses SF Pro is a failure even if no errors occur. If you have a source reference (the running web app, a design mock, or the generate_figma_design capture), you MUST also compare rendered screenshots — a near-miss style within the right family can pass a family check but still look wrong.

See references/discover-product-font.md for the read-back script (which separates free-standing text you fix from design-system-governed text you flag) and the screenshot-comparison steps.

Transfer images from the generate_figma_design capture

If you ran generate_figma_design in parallel (mandatory when the source contains images), transfer the captured images into your design system output:

1. Find all image nodes in the capture output by searching for fills with type === "IMAGE":

   const capture = await figma.getNodeByIdAsync("CAPTURE_NODE_ID");
   const imageNodes = capture.findAll(() => true).flatMap(n => {
     if (!Array.isArray(n.fills)) return [];
     const imageFill = n.fills.find(f => f.type === "IMAGE");
     return imageFill ? [{ name: n.name, id: n.id, imageHash: imageFill.imageHash }] : [];
   });
   return imageNodes;
2. Match each captured image to the corresponding frame in your use_figma output (by position, name, or order).
3. Apply the image hash to the target frame:

   targetFrame.fills = [{ type: "IMAGE", imageHash: "hash_from_capture", scaleMode: "FILL" }];
4. Delete the generate_figma_design capture output after all images are transferred.

Step 6: Updating an Existing View

When updating rather than creating from scratch:

1. Use get_metadata to inspect the existing screen structure.
2. Identify which sections need updating and which can stay.
3. For each section that needs changes:
   • Locate the existing nodes by ID or name
   • Swap component instances if the design system component changed
   • Update text content, variant properties, or layout as needed
   • Remove deprecated sections
   • Add new sections
4. Validate with get_screenshot after each modification.

// Example: Swap a button variant in an existing screen.
// Batch the node lookup and component-set import in parallel — they are
// independent and awaiting them sequentially serializes two IPC round-trips.
const [existingButton, buttonSet] = await Promise.all([
  figma.getNodeByIdAsync("EXISTING_BUTTON_INSTANCE_ID"),
  figma.importComponentSetByKeyAsync("BUTTON_SET_KEY"),
]);
if (existingButton && existingButton.type === "INSTANCE") {
  const newVariant = buttonSet.children.find(c =>
    c.name.includes("variant=primary") && c.name.includes("size=lg")
  ) || buttonSet.defaultVariant;
  existingButton.swapComponent(newVariant);
}
return { success: true, mutatedNodeIds: [existingButton.id] };

Reference Docs

For detailed API patterns and gotchas, load these from the figma-use references as needed:

• component-patterns.md — importing by key, finding variants, setProperties, text overrides, working with instances
• variable-patterns.md — creating/binding variables, importing library variables, scopes, aliasing, discovering existing variables
• text-style-patterns.md — creating/applying text styles, importing library text styles, type ramps
• effect-style-patterns.md — creating/applying effect styles (shadows), importing library effect styles
• gotchas.md — layout pitfalls (HUG/FILL interactions, counterAxisAlignItems, sizing order), paint/color issues, page context resets

Error Recovery

Follow the error recovery process from figma-use:

1. STOP on error — do not retry immediately.
2. Read the error message carefully to understand what went wrong.
3. If the error is unclear, call get_metadata or get_screenshot to inspect the current file state.
4. Fix the script based on the error message.
5. Retry the corrected script — this is safe because failed scripts are atomic (nothing is created if a script errors).

Because this skill works incrementally (one section per call), errors are naturally scoped to a single section. Previous sections from successful calls remain intact.

Best Practices

• Always search before building. The design system likely has the component, variable, or style you need. Manual construction and hardcoded values should be the exception, not the rule.
• Search broadly. Try synonyms and partial terms. A "NavigationPill" might be found under "pill", "nav", "tab", or "chip". For variables, search "color", "spacing", "radius", etc.
• Prefer design system tokens over hardcoded values. Use variable bindings for colors, spacing, and radii. Use text styles for typography. Use effect styles for shadows. This keeps the screen linked to the design system.
• Prefer component instances over manual builds. Instances stay linked to the source component and update automatically when the design system evolves.
• Componentize by default. Build repeated or reusable elements as a component once, then place instances. Do not ship a flat tree of one-off frames that needs a second "make it componentized" pass.
• Work section by section. Never build more than one major section per use_figma call.
• Return node IDs from every call. You'll need them to compose sections and for error recovery.
• Validate visually after each section. Use get_screenshot to catch issues early.
• Assert the font family, not just a successful load. A script can load the wrong font without error. After building, verify rendered text uses the product font identified in Step 1 (see Step 5).
• Match existing conventions. If the file already has screens, match their naming, sizing, and layout patterns.*