TemPad Dev: a Figma bridge for coding agents, in both directions

The bridge runs in both directions, and the Figma file is the anchor

TemPad Dev is described as an open-source connection between Figma, developers, and their coding agents, and the tagline is design and dev, connected.

The connection works in two directions. On one side the agent can read a design and implement it in the project. On the other the agent can create and edit content in Figma itself, producing native editable layers rather than an exported image. The README describes the result as native, editable layers, and says to reuse accessible components, variables and styles when the task calls for them.

The examples given are short prompts that read like instructions to a colleague. Create a settings screen in Figma using the available components. Or, working on an existing design, adjust the spacing and typography in this screen, keeping its components and content.

The mechanism underneath is MCP, the Model Context Protocol, exposed by a local server that the extension hosts. The agent connection requires Node.js 22.x, 24.x or 26+, and the canvas editing additionally requires edit access to the Figma Design file.

That last constraint is a hard boundary worth stating early. Writes require an editable Figma Design file, and view-only files and Dev Mode remain read-only. So the same agent that can inspect a design perfectly well in a shared file cannot change anything in it.

The primary language is TypeScript, the licence is MIT, and the homepage is tempad.dev. The last push was on 2026-10-21 and the repository has no GitHub releases.

Inspecting a design in the browser needs no agent at all

The part of the tool that does not depend on any agent setup is the one that gets used most often, and the quick start says so directly. Manual inspection needs no agent setup.

The panel opens when you select an element in a Figma Design file, and it shows that element's code, its variables and its layout. The README describes a set of inspection features: inspecting CSS code and variables, a deep select mode, a measure to selection mode, and scrolling the selection into view.

Those four capabilities are the difference between reading a Figma file and understanding it. CSS and variables give you the actual property values rather than approximations. Deep select is for drilling into a nested element. Measure to selection gives you distances between elements, which is the number a developer needs when spacing is wrong. Scroll into view is the one that sounds trivial and is not, because it resolves the difference between what Figma shows and what the browser has scrolled to.

None of this needs a client, an MCP server or Node. You install the extension from the Chrome Web Store, open a Figma Design file, select an element, and read the panel.

That is worth separating from the agent integration, because it is the part that works for everyone on the team regardless of which coding agent they use, and because it is the part you would use even if you never enable the MCP connection. The agent integration adds the ability for an agent to read the same evidence and act on it.

Two skills, and the generated code is a starting point

The agent integration ships two skills, and the split between them mirrors the two directions of the bridge.

The design-in-figma skill guides the agent through resource inspection, editing and checking the rendered result. It is the authoring path, and it is the one that needs edit access.

The figma-design-to-code skill is the implementation path. You select the design in Figma, then ask the agent in the target code project to implement the current Figma selection using this project's components and styling conventions. The skill guides the agent through adapting the evidence to the repository and validating the implementation.

The evidence TemPad Dev provides for that path is enumerated: layout, styles, variable references, component information and assets. That is a well-chosen list, because those five are what a developer has to reconstruct from a design and what an agent most often gets wrong.

The README is explicit about the output: generated design code is a starting point, and the agent produces the project implementation. That is the honest framing. An agent given Figma evidence and your repository can produce a plausible implementation, but the components and conventions of your project still have to be respected, and that is what the skill is for.

Both workflows use the same MCP connection to Figma, so there is one connection to set up rather than two.

Setup routes differ per client, and the choice only changes the instructions

The setup flow is the part of the documentation with the most detail, and the reason is that different agent clients consume the configuration in different ways.

The setup starts with installing Node.js 22.x, 24.x or 26+ with npx, keeping TemPad Dev open in the Figma tab you want the agent to inspect, then enabling Preferences, Agent integration, MCP access and allowing the loopback connection to 127.0.0.1. Canvas authoring is available while MCP access is enabled and the current Figma Design file is editable.

Then you select Set up agents, choose your client and follow the displayed path. The listed dedicated entries are Qwen Code, Qoder, ZCode, Kimi Code, Pi and Hermes Agent alongside the existing IDE and CLI integrations, and Other agents covers another compatible client. The README makes one clarifying point: the choice only changes the instructions shown, it does not bind or activate an agent.

Behind that are three installation mechanisms. The setup flow uses native marketplace installation for Codex and Claude Code, the portable Agent Plugin for Cursor and VS Code, and native IPC without lifecycle hooks for Codex App. Other entries get the client's MCP flow plus the two standalone skills, with configuration destinations and documentation links where needed. Pi requires version 0.99 or later with built-in MCP enabled.

Two details are reassuring. Every command or config is shown in full for review and copying, so you can see exactly what will be written. And the README notes that these setup paths do not imply native comment delivery or host interruption support for every client, which is the sort of qualification that is usually missing.

For clients that install MCP and skills separately, the setup shows each command, and Gemini is the example given.

Task controls exist, and stopping a task cancels its writes for good

On compatible Codex App hosts there is a richer interaction model, and the README describes it in enough detail to be worth reading because the semantics are not obvious.

There is a task status bar that follows the design anchor and shows the agent's activity along with Stop and Done controls. The important line is that Stop permanently cancels the current task, and reconnecting cannot resume its writes. That is a stronger statement than a pause, and it is the right one, because a half written Figma layer is worse than no write at all.

On those hosts you can save element comments or add a general comment and then send the batch with Queue or Steer. Queue clears submitted drafts after the host confirms receipt, so another batch can be written while the queued request waits. The README is careful to add that confirmation does not mean the agent has completed the changes.

The keyboard semantics are also specified. In an element editor, Enter saves, and Command or Ctrl with Enter saves and queues the whole batch. In the general composer, Enter queues the batch and Command or Ctrl with Enter uses Steer. Shift with Enter adds a newline.

And there is a scope limit stated plainly: Claude, Codex CLI and other clients currently have task controls without comment sending. The comment guide and host validation scope live in the agent plugin README.

The pattern across all of this is worth naming, because it applies to any agent integration: the tool works with every MCP capable client for the core functionality, and the richer host specific features are opt-in and documented as such.

Where TemPad Dev is the wrong tool

The first wrong-tool case is a design that does not live in Figma. The entire bridge is a Figma extension speaking to a Figma canvas. A team working in Sketch, in a design system hosted as code, or in a hand built component library gets no design context from this tool, and the inspection features are the part people use most.

The second case is a team that wants an agent to produce finished visual design on its own. The design-in-figma skill creates native editable layers, and the README's own examples are prompts that specify constraints: use the available components, keep the existing components and content, adjust spacing and typography. The agent is a mechanism for applying instructions, not a substitute for a designer with taste, and the output is meant to be reviewed and edited in Figma.

The third case is a locked-down environment. The extension needs a local MCP server, Node.js on the machine, and a loopback connection that the user has to allow. A corporate policy that blocks local servers or restricts the Chrome Web Store rules it out, and there is no hosted variant described in the visible documentation.

There is also the edit access boundary to keep in mind for shared files. A colleague viewing a design file you own can have the agent read it, but writes need edit access. In a review workflow where a designer is the only one with edit rights, the authoring direction needs their involvement anyway.

What the tool does give you is a way to hand an agent the same design evidence a developer would gather by hand, at the moment the design changes, in both the direction of building the interface and the direction of changing the design.

Editorial conclusion

TemPad Dev suits a team whose designs live in Figma and whose implementation happens in a codebase, because it gives the agent the same design context a developer would read off the canvas, in both the authoring and the implementation direction. It does not suit a designer who wants an agent to produce finished visual design without a developer in the loop, and it does not suit a workflow outside Figma, since the whole bridge is Figma specific. Before adopting, enable Preferences, Agent integration, MCP access on a machine running Node.js 22.x, 24.x or 26+, and confirm the Figma file is editable, because view-only files and Dev Mode stay read-only regardless of the agent connection.

Frequently asked questions

Official sources

1. ecomfe/tempad-dev on GitHub
2. Issues
3. License: MIT
4. Project website
5. README