A cloud coding agent can have your source code and still be missing the design. I built figlens around a file-based handoff: save a local .fig copy in Figma, then let the agent read it wherever it runs.
The machine reading the design needs no Figma installation, login or API key. Designers can keep working in Figma.
A real build, with a live preview
This is a real Pi session in Orca, shown at 8x speed. Pi reads the local design bundle, writes HTML/CSS, and checks the result in a browser. The finished page uses 19 SVG icons from the bundle and includes a local Share dialog and composer.
The design is the “List views” frame from MCP Apps for Claude (Community). System sans and Georgia replace the unavailable Anthropic fonts. Replies in the demo stay in the page and reset on reload.
Watch the 45-second video. The capture uses actual window snapshots, so motion is less smooth than a native recording.
Try it with your own design
Save your design with File > Save local copy in Figma. With Node.js 18+ installed, list its frames:
npx @runkids/figlens tree design.fig --depth 2
Choose a frame ID from that output, then create a bundle. Replace 12:345 below with your frame ID:
npx @runkids/figlens bundle design.fig 12:345 frame.zip
The npm launcher downloads and caches a native binary on its first run. You can also install a native release directly; users need neither Rust nor Docker.
Give your coding agent frame.zip and a prompt like this:
Extract frame.zip into its own directory and read context.md. Build this screen using this project’s stack and conventions. Use the supplied layout values and assets, then compare your result with references/screen.png.
The bundle contains layout and text data, bound variables, image and SVG assets, a reference render, and a list of any missing assets. That gives the agent concrete values to build from. Font files are not included.
For agents that support skills:
npx skills add runkids/figlens --skill figlens
There is also a local stdio MCP server. The README has native and npx configuration examples.
What “offline” covers
figlens reads the saved design locally without calling the Figma API. Your AI provider, initial binary download, and project dependencies may still need a network connection. A Figma URL alone does not supply the design: you need the saved .fig file, and a new copy when it changes.
One measured example
For this 57.5 MiB file, extracting the selected frame’s bundle took 0.47 seconds median over five warm runs. The frame had 153 nodes and produced 25 SVG assets with no missing assets.
That timing measures figlens bundle only. It excludes the AI’s implementation time. It was recorded with figlens 0.1.2 in an ARM64 Docker container using a prebuilt release binary. Individual runs, environment and reproduction commands are in the repository.
The .fig format is undocumented, and rendering has known gaps. I would like feedback from people using coding agents in headless or cloud environments: does a local design bundle fit your handoff, and what information would your agent still need?
Source and installation: https://github.com/runkids/figlens
Top comments (7)
"The machine reading the design needs no Figma installation, login or API key" is the right architecture, and it's the one most design-to-code tools get wrong.
Most tools require the agent to call the Figma API, which means it needs a token, an internet connection, and permission to access the file. Your approach — save a local .fig, extract the bundle, hand it to the agent — is much simpler and works in headless environments where API access is blocked.
The
context.mdfile with layout, text, variables, and reference render is the key. It gives the agent concrete values to build from, not just a screenshot to guess at.Thanks. The headless case is exactly what pushed me to do it this way: the agent was running in CI with no browser, and the Figma MCP quota belongs to the team that owns the file, not to the seat running the agent.
One thing I'd like to hear from people actually using it: does
context.mdhave everything you need, or is there a value you still end up asking the designer for? That's the part I'm tuning next.The headless CI constraint is a massive pain point, so solving that with a static file is a really smart architectural choice.
To answer your question: for static layout, context.md probably covers it. But what I still almost always have to ask designers for is behavior and edge cases.
Specifically, I find myself missing:
Interaction states: Does this component have a hover state? What does the disabled or focus state look like? Does clicking this trigger a modal, or navigate to a new route?
Content limits: What happens if the user's name is 3x longer than the mockup? What does this list look like with 0 items (empty state) or 100 items (pagination)? Designers usually design for the happy path, but agents need to code for the extremes.
Responsive behavior: Does this sidebar disappear on mobile, or stack below the main content?
If context.md could eventually capture basic "empty state" or "error state" variations, the generated code would be 10x closer to production-ready. Awesome work on this!
Thanks, this is really useful. I’d want to distinguish states defined in the design from behavior the agent would have to guess. In your workflow, are those states usually captured as variants or separate frames in Figma, or documented elsewhere? A small example would help me understand what the bundle should preserve.
Great question. Distinguishing defined states from guessed behavior is exactly where agents usually fail.
In practice, it's a mix. In Figma, simple states (like hover or disabled) are usually captured as Component Variants. But complex states (like empty states, loading spinners, or complex error messages) are often just separate frames on a canvas, hidden layers, or they aren't designed at all and live in a spec doc.
The context.md bundle should explicitly map this state matrix out. It needs to preserve the trigger (what causes the state change) and the visual delta (what actually changes on screen).
A small example for a "Submit" button:
Default: Standard view.
Disabled: Opacity 50%, cursor not-allowed. (Trigger: form is invalid).
Loading: Text replaced by a spinner. (Trigger: onClick).
Error: Red border and text below. (Trigger: API failure).
If the bundle doesn't explicitly list those, the agent will just code the "Default" variant and guess the rest (and usually guess wrong).
For the SVGs, I'd keep the source library and license in the bundle; those details are easy to lose during handoff.
Good point. Preserving source and license information would be useful where it’s available. I’d want to avoid guessing when that metadata isn’t in the .fig file. How do you usually keep track of it in your Figma workflow?