Figma Build

figma-build

Turn code or a description into a Figma design that looks like it belongs in the file: reuse the components, variables, and styles that already exist, and only build what's genuinely missing. This is the mirror image of figma-codegen — same "reuse beats regenerate / reference tokens not literals" philosophy, pointed at the canvas instead of the codebase. This file is the router; deep detail lives in references/ — load a reference when its step is in play.

You operate on the connected Figma file (the plugin's current session). There is no fetch-by-URL; the user must have the target file open. Confirm a plugin is connected (ping) before building.

When to use

• The user wants to create or update something in Figma from code or a description — a screen, view, modal/dialog/drawer/sidebar/panel, a single component, or a design-system asset.
• Not for reading a Figma design into code — that's figma-codegen.

More than one Figma file open

Every tool result says so when it applies, so you do not have to check up front: with two or more files connected and none claimed, results carry a MORE THAN ONE FIGMA FILE IS OPEN block naming them. It matters because calls otherwise follow whichever file the user last touched, which changes when they switch tabs — so a task can read one file and write to another and report success.

When you see it, claim the file before doing anything else: list_files names every connected file, use_file({ fileName }) claims one for this session (use_file({ sessionId }) when two open files share a name — Figma allows that, and x (Copy) is how it happens). Every later call then reaches that file whatever is in front, including while its tab sits in the background. If the user has not said which file, ask — do not guess from the names.

First, understand the environment, then build (provider-first)

The write-side mirror of codegen's grounding, and the most important habit: an off-looking build almost always comes from invented values or assumed conventions. So understand this user's actual environment first, then build into it — never apply a generic template. There's no single "right" stack; there's their stack. Look at both ends before creating anything:

• The Figma file — its existing design system, which you'll reuse and bind to:
  1. get_variable_defs → the file's variables (colour / spacing / radius / typography) with names + values + hex. These are the tokens you bind to.
  2. scan_components / get_local_components → existing components to instance rather than rebuild. Match the source UI pattern (a card, a list row, a nav, a button) to a component.
  3. get_styles → shared paint / text / effect styles to apply.
• The source you were handed — when it's code, which stack and styling system (Tailwind / Chakra / MUI / CSS modules / vanilla …) and whether it has a config / theme / tokens file. That's where its real values live — read them from there, don't assume a default.

Then build, tracing every value to a source in priority order: reuse an existing component / variable / style; else take the exact value from the source's own code — provider-first, resolving whatever styling system it uses to real px / hex (CSS literally; Tailwind / Chakra / UnoCSS / … via their config or scale), never eyeballed; only invent from a consistent scale when neither exists. Full detail + the value-resolution method in references/write-rules.md.