DEV Community: Roya

AI can read your Figma. Figwright lets it build there, too.

Roya — Sat, 27 Jun 2026 10:53:44 +0000

TL;DR — Figwright is a free, open-source MCP server + Figma plugin that gives any AI agent a two-way door into Figma. It reads designs into code that reuses your components and tokens, and it writes back onto the canvas — frames, text, auto-layout, styles, variables, whole screens. 92 tools. Any MCP client. No Dev Mode seat.
npx -y @figwright/mcp@latest

Here's a Tuesday I've lived more times than I'd like.

It's 3pm. A designer drops a Figma link in Slack — "can you build this screen? should be quick 🙏" — and I make the mistake of believing "should be quick." I point my AI agent at the frame and ask for the code. Thirty seconds later I'm staring at a 180-line component that's really just a wall of <div style={{ ... }}>, with #2563EB hardcoded in six places. That blue is literally bg-primary in our config — the AI just has no way to know that. The Button I shipped last month? Reinvented from scratch. My Tailwind tokens? Never heard of them. So I spend the next hour find-and-replacing hex codes like it's 2015, swapping the AI's generic markup for the components we already have. The tool "saved me time" by handing me homework.

Then the designer follows up, breezy as ever: "oh, can you also drop a pricing section into the Figma file so I can tweak the spacing?" And my AI just… shrugs. It'll describe the canvas to me all day. It can't put one frame back on it.

And the official Figma Dev Mode MCP — the thing that does the reading half? It wants a paid Dev Mode seat. For a side project, that's where the conversation quietly ends.

I got tired of every part of that Tuesday, so I built Figwright: a free, open-source MCP server (plus a Figma plugin) that gives any AI agent — Claude Code, Cursor, whatever speaks MCP — a two-way door into Figma. Let me walk you through how it fixes that exact day.

Where Playwright drives the browser, Figwright drives Figma.

Problem 1: "The AI ignores everything I've already built"

Generic tools fail for one reason: they hand the model a flattened picture of the design and zero knowledge of your repo. Of course it reinvents a button — it doesn't know you have one.

Figwright does the opposite. Before it writes a line, it does what I call grounding: it reads your real stack (React / Vue / Svelte / Next… + Tailwind / CSS / CSS-in-JS) and then joins the Figma design to your codebase with three tools that are the heart of the project:

component_map — sees a card in the design, knows you already ship <Card>.
token_map — sees your brand blue, emits bg-primary, not #2563EB.
icon_map — sees an icon and reuses the actual SVG from your repo (with the right currentColor / fixed-fill contract), instead of re-drawing a blob.

All of it rides on get_design_context, which gives the model faithful, de-duplicated context — layout, typography, variables, components — instead of a screenshot it has to guess from.

So the same request that used to spit out <div> soup:

// ❌ generic tool: hardcoded values, your design system nowhere in sight
<div style={{ display: 'flex', padding: 16, borderRadius: 8, background: '#2563EB' }}>
  <span style={{ color: '#fff', fontSize: 14, fontWeight: 600 }}>Get started</span>
</div>

…now comes back as code I can actually merge:

// ✅ Figwright: reuses the component and tokens I already have
<Button variant="primary" size="md">
  Get started
</Button>

No afternoon of cleanup. That's the whole point: don't be a compiler that flattens the design — surface honest context and let the model write code that fits the repo it's living in.

Problem 2: "It can only look, never touch"

This is the half nobody else does. When the designer asks me to push a section into Figma, I now just… do it:

Build a 3-tier pricing section in Figma from this spec.

Figwright authors the canvas directly — and it reuses the file's design system instead of dropping flat rectangles. Real auto-layout, your text and color styles, your variables bound to the right nodes, your components instantiated. Under the hood that one prompt fans out into real tool calls:

create_frame → set_auto_layout → create_text → apply_style_to_node
→ bind_variable_to_node → create_instance → resize_nodes → ...

Scaffold a whole screen, fix one component, or generate design-system assets — from a prompt or a chunk of code. Turn a React component into a Figma component. Recreate a landing page on the canvas. The symmetry is the magic: the same agent that implements your designs can also build them.

Problem 3: "Why am I paying for a seat just to read my own file?"

Figwright talks to Figma through a plugin, so the free tier is enough — no Dev Mode seat, no paid tier. And it isn't married to one editor: any MCP-capable client works the same way.

Here's the honest comparison with the official option:

	Official Dev Mode MCP	Figwright
Reads a design → code	✅	✅
Writes back to the canvas	❌	✅
Reuses your components & tokens	partial	✅ provider-first
Works in any MCP client	Dev Mode clients	✅
Cost	paid Dev Mode seat	free

The official Dev Mode MCP is genuinely good — but it's read-only and behind a paid seat. Figwright is the one that also writes back, reuses your codebase, and runs for free.

The stuff you only learn from real, messy files

A demo is easy. Trusting a tool on a 2,000-layer client file is where it gets real — and a few scars shaped how Figwright works:

Run two agents at once. I keep Claude Code and Cursor open. They used to fight over the plugin socket, so Figwright runs a leader/follower election: one owns the connection, the others forward over HTTP, and if the leader quits a follower takes over — sub-second, no manual reconnect.
"Busy ≠ dead." A big export would look like a dropped connection — a heavy, synchronous step starved the heartbeat and the relay cut the line. Cranking the timeout up doesn't help; the heartbeat has to survive the work. Now it does.
Screenshots never come back empty. I once exported a logo and got a 1×1 transparent pixel because it lived inside a clipped carousel. Figwright bypasses ancestor clipping, so a screenshot returns the real thing — not a blank.
Binary on the wire. The plugin↔server protocol is msgpack, not JSON — faster and smaller for the chunky payloads design data throws around.

None of it is flashy. All of it is the difference between a demo and a tool you reach for on a deadline.

92 tools, three groups

The count isn't the point — coverage is:

Read — selection, document/node inspection, styles, variables, components, fonts, reactions, screenshots, even PDF export.
Write — create and edit frames, text, shapes, auto-layout, effects, styles, variables, components, pages, reactions… plus a batch tool to apply many edits at once.
Grounding — get_design_context, component_map, token_map, icon_map — the join layer that ties Figma to your code.

Your MCP client lists every tool at connect time, so that's always the source of truth.

Skills do the orchestrating

Raw tools are low-level. Figwright ships two model-invoked skills that encode the grounded workflows, so your agent reaches for the right tools at the right moment:

Skill	What it does
`figma-codegen`	Turn a Figma selection into framework-aware code, grounded on your stack and components.
`figma-build`	Build a Figma design from code or a description, reusing the file's existing system.

npx skills add awdr74100/figwright/skills

Quick start

1. Add the server to your MCP client (.mcp.json for Claude Code; other clients use the same shape):

{
  "mcpServers": {
    "figwright": {
      "command": "npx",
      "args": ["-y", "@figwright/mcp@latest"]
    }
  }
}

2. Install the plugin from the latest GitHub release: unzip it, then in the Figma desktop app → Plugins → Development → Import plugin from manifest… and pick the manifest.json.

3. Connect. Open the plugin in Figma — it auto-connects and shows Connected. Ask your agent to run ping to confirm.

4. Try it. With a frame selected: "Code this Figma selection as a React component." …or the other way: "Build a pricing section in Figma from this spec."

FAQ

Do I need Figma Dev Mode or a paid plan?
No. It's a plugin, so the free tier is enough — no Dev Mode seat, no paid tier.

Which agents work?
Anything that speaks MCP — Claude Code, Cursor, and other MCP clients all work the same way.

Can multiple agents use the same plugin?
Yes — leader/follower election shares one plugin across several servers, with a graceful handoff.

Is it actually local?
Yes. The relay is 127.0.0.1-only; nothing leaves your machine.

Why "Figwright"?

figwright follows the old -wright tradition — a maker or craftsman. A playwright writes plays, a shipwright builds ships, a wheelwright builds wheels. It's a nod to Playwright, which automates the browser. Where Playwright drives the browser, Figwright drives Figma — a maker of designs that both reads the canvas and crafts work back onto it.

Try it — and tell me what breaks

It's MIT-licensed, open to contributions, and already carries an A quality score on Glama.

⭐ Repo: https://github.com/awdr74100/figwright
📦 npm: @figwright/mcp

I built Figwright because I was tired of AI tools that could only look at my designs — and that handed me homework every time they did. If you've felt the same wall, give it a spin on a real file and tell me how the two-way loop holds up. Star the repo if it's useful, open an issue if it isn't, and I'd genuinely love to see what you build (or break).

I built a Vite plugin to bring Nuxt-style middleware to Vue

Roya — Sat, 09 May 2026 10:57:24 +0000

Vue is great. Vite is great. Vue Router is great. But there's one area where the "bring your own solution" philosophy starts to show its cracks: navigation guards.

The moment your app needs more than a simple auth check — analytics, permission levels, feature flags, prefetching — you start piling logic into beforeEach and hoping for the best.

What about the existing solutions?

To be fair, there are some community approaches out there:

Roll your own middleware runner — works, but you're reinventing the wheel every project, with no type safety
vue-router-middleware-plugin — closest thing I found, but no TypeScript support for middleware names, no async context handling
Just use Nuxt — valid option, but sometimes you really don't need the full SSR framework for a simple SPA

None of these fully scratched the itch, so I built vite-plugin-vue-middleware.

The goal was simple: make Vue SPA middleware feel as natural as Nuxt, without leaving the Vite ecosystem.

What started as a straightforward file-scanning plugin turned into something more interesting, especially when I ran headfirst into the async context problem — more on that below.

What problems it solves

Problem 1: Everything piles up in `beforeEach`

Fix: Each middleware is its own file inside src/middleware/. The plugin scans the directory automatically and wires everything up.

src/middleware/
├── 01.auth.global.ts     ← runs on every route, first
├── 02.log.global.ts      ← runs on every route, second
├── admin.ts              ← only runs when the route opts in
└── guest.ts

Your router setup becomes a single line:

import { setupMiddleware } from 'virtual:vue-middleware'
setupMiddleware(router)

That's it. New middleware file = automatically picked up. Delete a file = gone. No manual registration, no imports to remember.

Problem 2: No type safety for named middleware

When you write middleware names as strings in meta.middleware, there's no autocomplete, no error on typos — you only find out at runtime that 'auht' is not a valid middleware name. Classic.

Fix: The plugin auto-generates a .d.ts that augments vue-router's RouteMeta, so your middleware names are fully typed with IntelliSense.

definePage({
  meta: {
    middleware: ['admin', 'guest'], // autocomplete works, typos caught at compile time
  },
})

Problem 3: `inject()` silently breaks after `await` — and TanStack Query will find this out for you

This one caught me off guard. Vue's inject() only works inside an active app context. In an async function, code after await runs in a new microtask — Vue's context is already gone by then.

Why does TanStack Vue Query come into this? Because useQueryClient() calls inject() under the hood. So if you ever try to do something like this in middleware:

// ❌ looks fine, blows up at runtime
export default defineMiddleware(async (to) => {
  await validateSession()
  const queryClient = useQueryClient() // inject() called outside of component setup 💥
  await queryClient.prefetchQuery(userQueryOptions)
})

You get a cryptic error, scratch your head for 20 minutes, and eventually realize it's not TanStack's fault — it's the async context evaporating after await.

Fix: The plugin applies a build-time AST transform that converts your async middleware into a generator-based executor. Each segment after an await is re-entered via app.runWithContext(), which restores the Vue injection context automatically.

The transform is completely transparent — you keep writing normal async/await, the plugin handles the rest:

// ✅ works — inject() (and useQueryClient) are available after every await
export default defineMiddleware(async (to) => {
  await validateSession()
  const queryClient = useQueryClient() // works perfectly now
  await queryClient.prefetchQuery(userQueryOptions)
})

No manual changes needed on your end. Just write middleware like you normally would.

Quick start

npm install -D vite-plugin-vue-middleware

// vite.config.ts
import vueMiddleware from 'vite-plugin-vue-middleware'

export default defineConfig({
  plugins: [vue(), vueMiddleware()],
})

// src/router/index.ts
import { setupMiddleware } from 'virtual:vue-middleware'
setupMiddleware(router)

// src/middleware/01.auth.global.ts
import { defineMiddleware } from 'virtual:vue-middleware'

export default defineMiddleware(async (to) => {
  const isLoggedIn = await checkAuth()
  if (!isLoggedIn && to.path !== '/login') return '/login'
})

Return values follow the same contract as vue-router navigation guards:

nothing returned → continue
return false → abort navigation
return '/path' or return { name: 'login' } → redirect

File naming conventions

Filename	Behavior
`auth.global.ts`	Runs on every route navigation
`01.auth.global.ts`	Global, numeric prefix controls execution order
`admin.ts`	Only runs when `meta.middleware` includes `'admin'`

Works with unplugin-vue-router

If you're using file-based routing with unplugin-vue-router, you can declare middleware directly in your .vue files:

<script setup lang="ts">
definePage({
  meta: {
    middleware: ['auth', 'admin'],
  },
})
</script>

Full type safety included.

Try it out

GitHub: awdr74100/vite-plugin-vue-middleware
npm: vite-plugin-vue-middleware

If you run into any issues or have feature ideas, issues and PRs are very welcome. Would love to hear if you've hit the async context problem too — curious how common it actually is.

If this saves you some headache, a ⭐ on GitHub would mean a lot — it helps others find the project too!

DEV Community: Roya

AI can read your Figma. Figwright lets it build there, too.

Problem 1: "The AI ignores everything I've already built"

Problem 2: "It can only look, never touch"

Problem 3: "Why am I paying for a seat just to read my own file?"

The stuff you only learn from real, messy files

92 tools, three groups

Skills do the orchestrating

Quick start

FAQ

Why "Figwright"?

Try it — and tell me what breaks

I built a Vite plugin to bring Nuxt-style middleware to Vue

What about the existing solutions?

What problems it solves

Problem 1: Everything piles up in beforeEach

Problem 2: No type safety for named middleware

Problem 3: inject() silently breaks after await — and TanStack Query will find this out for you

Quick start

File naming conventions

Works with unplugin-vue-router

Try it out

Problem 1: Everything piles up in `beforeEach`

Problem 3: `inject()` silently breaks after `await` — and TanStack Query will find this out for you