Figma

A design describes a screen more precisely than a task does: sizes, spacing, colours, fonts, which components it is built from and how its auto layout behaves. The integration lets Buff read Figma files in the connection’s scope the way the inspector panel shows them — as parameters and token names — and takes questions right in design comments. Only a model that can read images gets a picture of the design; everything else works with any model.

• Build the screen as in the design, not as it seemed

  A developer takes the task “build the sign-in screen”. The task has one line and a link to Figma. Spacing, corner radii, font sizes and the button colour are usually judged by eye and rounded.

  Result. The bot reads the screen’s frame with a tool and answers with parameters: vertical auto layout with 24 padding and 16 spacing, a button 48 high with a 12 corner radius, fill — the “Button/Malachite” style, #0FA37F. There is something to build from, and the numbers match the design.

• Design system: which tokens exist and what they mean

  A third shade of green appears in the project because nobody remembers which one is the “primary”. The tokens are written in Figma — as styles and variables — but people rarely look there from the code.

  Result. The get_styles tool returns the published styles with their values and the variables by mode: “Colour/Accent” is #0FA37F in the light theme and #33CC99 in the dark one. The answer refers to the token names, and they are what goes into the code, not yet another hex.

• A question right on the design

  A designer leaves a comment on a screen in Figma: “what happens if the email is already taken?”. Such a question used to go to the chat and get lost between two tools.

  Result. They mention the bot in the comment. The bot answers in the same thread, relying on the project code and the design itself: what error text the code has, and whether the field component has a state for it. The discussion stays where the design is.

• Review: the design and the code differ

  At review people argue about whether the field border is the right thickness and the heading the right line height. A screenshot against a screenshot is a weak argument, and opening Figma to measure by hand takes a while.

  Result. The bot compares: in the design the border is 1, colour #D1D5DB, the heading Inter Semi Bold 24/32 with −0.5 tracking. In the code — 2 and 28. The difference is named in numbers, and the argument is closed in one comment.

1. @buff what are the padding and colour of the “Sign in” button on the sign-in screen?

   a design comment or a question in the Buff app

   tool: search_nodes + get_node

   The “Sign in” button is an instance of the “Button/Primary” component, 342×48. Horizontal auto layout, padding 12 top and bottom, 24 at the sides, spacing 8. Fill — the “Button/Malachite” style (#0FA37F), corner radius 12, shadow 0/4 with a blur of 12. The label is Inter Semi Bold 16, white, centred.

2. @buff show the colour tokens in this file

   a design comment

   tool: get_styles

   Published fill styles: “Background/Surface” #FFFFFF, “Text/Primary” #111827, “Button/Malachite” #0FA37F; the text style “Heading/H1” is Inter Semi Bold 24/32. Variables cannot be read on your Figma plan — their names are visible in node bindings, and the values come from the styles.

3. /research how the sign-in screen in the design differs from the one in the code

   a comment on the screen’s frame

   tool: get_node + project code

   The word after the mention picks the work: without it — a short answer, “research” — research with a document, “task” — a draft development task. Research reads the design as parameters and checks it against the layout in the repository.

4. @buff what is called “Email field” in the design and what is it made of?

   a question in the Buff app

   tool: search_nodes + get_node

   The “Email field” frame, 342×56, on the sign-in screen: horizontal auto layout with 16 padding, corner radius 8, a white fill and a 1 border of colour #D1D5DB. Inside is the placeholder text “Email”, Inter 16, colour #6B7280.

1. Step 1

   Installation takes one click

   Open the “Marketplace” section on the connector’s local page. Before installing you can see what the integration will get: the addresses it will be able to reach (the Figma API and the image store), which credentials it will ask for and which tools the model will see — with a mark on the one that answers with a picture.

   Connector

   

   ← scroll the frame →

2. Step 2

   Setup: a token and a list of files or projects

   The API address is already filled in (`https://api.figma.com`); there is no need to change it. A file’s key is visible in its address: `figma.com/design/KEY/…`; a project’s number in the project address: `figma.com/files/project/NUMBER/…`. You can use one of the lists or both. If both are empty — any file open to the bot’s account, but questions from comments then arrive only through a webhook. A personal access token is issued in the Figma account settings and stored on your machine: the integration does not see it.

   Connector

   

   ← scroll the frame →

3. Step 3

   Create a separate account for the bot

   Give it view access to the files needed and permission to comment. The integration needs nothing more: it does not edit designs, publish libraries or change permissions.

4. Step 4

   The same from the command line

   Installing without a GUI is an equal option: `connector install figma`, then `connector instance add figma --config projects=4815162342` — the API address fills itself in.

5. Step 5

   How the bot learns about questions

   If the connection lists files or projects, polling reads their comments itself — every 20 seconds by default; the interval can be changed in the connection settings, and no ports are needed; a FILE_COMMENT webhook to the link issued by the connector only speeds up the answer. If both lists are empty, polling does not know which files to watch: the bot learns about a question in a comment only from the webhook and only in the files it is set up for. In that case the connector’s event receiver must be reachable from the internet — Figma calls it from its cloud. Without a webhook such questions do not reach the bot.

   Connector

   

   ← scroll the frame →

The integration runs as a separate process under its own operating system user: it does not see the connector’s key, does not read the files of other connections and cannot reach the network past the connector. More in the security section.

• Figma on any plan; variables can be read only on Enterprise — other plans get styles and node bindings.
• A personal access token of the bot’s account with view access to the files needed and permission to comment.
• Network access from the connector’s machine to api.figma.com and to Figma’s image store. If the lists of files and projects are empty, you also need the connector’s event receiver with an address reachable from the internet: otherwise questions from comments will not reach the bot.
• Connector 0.6 or later: the integration declares a picture tool and default values in its settings, which older versions do not understand.
• A connector run with the right to create a separate OS user for the integration (root or CAP_SETUID).
• A model that reads images — only if you need the render_node tool; everything else works with any model.

Our model cannot look at pictures. Is the integration useless?

No — it is built for exactly this case. The model gets the design as parameters: sizes, auto layout, colours in hex, typography, names of styles and variables, components and their properties. The one picture tool is simply not offered to it, and answers are worked out from parameters and tokens.

How does Buff know whether the model sees pictures?

From the model’s description — at the provider or on the dedicated machine: it states which input types the model accepts. If images are among them, the render_node tool is offered; if not, it is not. There is nothing to set up by hand.

Will you copy our designs to your side?

No. The integration reads nodes at the model’s request when an answer requires it, and transfers or indexes nothing in advance. What is read enters the context of a specific answer, not a store.

Why can variables not be read?

Because that is how the Figma API works: access to variables is available only on Enterprise plans. On other plans the integration takes tokens from the published styles and shows variable names from node bindings; the connection check says so plainly.

Will the bot be able to change anything in the design?

No. It reads nodes and writes comments; it cannot edit layers, publish libraries or change permissions — the integration has no such tools at all.

Does a big file mean a big bill?

Only what the model asked for is read: the structure to a given depth, a specific node, the styles. The answer is not cut — a frame with forty layers has forty layers in the answer — but the model goes for the whole file only when searching by name, and that is visible in the list of tool calls.