Name: figma-generate-design
Author: figma

Use this skill alongside figma-use when the task involves translating an application page, view, or multi-section layout into Figma. Triggers: 'write to Figma', 'create in Figma from code', 'push page to Figma', 'take this app/page and build it in Figma', 'create a screen', 'build a landing page in

Build / Update Screens and Views from Design System Hard deliverable gate: Code to design output must recreate the UI as editable text, components, icons, and hierarchy. Treat any screenshot or flattened rendering of the complete UI only as a visual reference: never upload or import it into the deliverable, including as the wrapper fill or a child node, even if it exists in the repository or appears more pixel accurate. Before completion, inspect the result; if the UI is not primarily represented by editable layers, rebuild it semantically or report failure. 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](../figma use/SKILL.md) before any use figma call. That skill contains critical rules (color ranges, font loading, etc.) that apply to every script you write. When available, call create session with fileKey and description before file reads or edits (create the file first if needed), then pass the returned sessionId unchanged to every call that accepts it, including follow ups and work across files. 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. HTML to Figma Exceptions Use html to figma for initial creation in these cases: The input is an existing raw or static HTML document. Pass it directly to html to figma . The prompt asks to create a new design and there is no rendered UI implementation to reproduce. Create a self contained HTML document and pass it to html to figma . If html to figma is unavailable, follow the existing workflow below. Skill Boundaries Use this skill when the deliverable is a composed Figma view (new or updated) — including a form, dashboard, list, table, card, header, panel, dialog, message preview, or other multi section container — built from design system component instances. This applies even when the user calls the composed view a component. If the primary deliverable is a reusable library primitive or foundation intended for variants, tokens, or publication, use [figma generate library](../figma generate library/SKILL.md) with [figma use](../figma use/SKILL.md) instead. If the user wants to write Code Connect mappings , switch to [figma code connect](../figma code connect/SKILL.md). 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 discrete content images used by the app, such as photos, avatars, logos, or icons. A screenshot or flattened rendering of the complete UI is a visual reference, not a content image. 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 these content images are present, their 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. Required invariants: Complete Code Connect discovery and select the target library before mutating the deliverable. Discovery only imports and temporary instances are allowed; remove temporary instances immediately. Apply each selected asset where it is imported. If an import fails, try the next applicable exact result before building a manual fallback. 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](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: Batch multiple lookups in a single call. Use the returned keys with either importComponentByKeyAsync() or importComponentSetByKeyAsync() depending on each item's assetType in Step 4. Mark resolved components and continue with unresolved ones. 2a ii — REQUIRED: Select the library scope, then search and inspect the whole view. Call get libraries . If the user names one or more libraries, use their exact keys whether they appear in libraries added to file or libraries available to add . Otherwise search across all libraries in libraries added to file together. Pass the selected keys in includeLibraryKeys on every search. Only when unresolved gaps have no suitable match, add specifically relevant libraries from libraries available to add and retry those unresolved queries; do not broaden to unrelated available libraries. In the first batched search design system call, include one component query for the requested view or flow alongside queries for unresolved items already known from source or Code Connect inspection. Name the whole view query by purpose and container (for example, billing settings drawer ). Inspect the strongest candidate. If it covers two or more requested sections, select it as a foundation; otherwise continue without a whole view composite. 2a iii — Inspect existing screens. Check if the target file already contains screens using the same design system. One read only use figma call inventories an existing frame — its component keys, bound variables, and text/effect styles — in a single authoritative pass. Run it once here and reuse the result in 2b and 2c rather than re walking the frame: Match components against your unresolved components; Code Connect keys from 2a i stay authoritative. Mark any newly resolved. 2a iv — Search only the gaps needed for construction. After Code Connect, whole view discovery, and existing screen inspection, search for unresolved components and tokens the design still needs. Batch independent one intent entries, keep includeLibraryKeys restricted to the selected library scope, and carry selected keys into the build. Do not delay construction to exhaustively search every unresolved role. 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). Use one intent per query. search design system does not apply OR semantics, so never pack alternatives or synonyms into one string ("Button IconButton icon" matches nothing useful). Use an exact design syst