What it does: 100 commands to create shapes, text, frames, components, modify styles, export assets. JSX importing that's ~100x faster than any plugin API import. Works with any LLM coding assistant.
Why I built it: The official Figma MCP server can only read files. I wanted AI to actually design — create buttons, build layouts, generate entire component systems. Existing solutions were either read-only or required verbose JSON schemas that burn through tokens.
Demo (45 sec): https://youtu.be/9eSYVZRle7o
Tech stack: Bun + Citty for CLI, Elysia WebSocket proxy, Figma plugin. The render command connects to Figma's internal multiplayer protocol via Chrome DevTools for extra performance when dealing with large groups of objects.
Try it: bun install -g @dannote/figma-use
Looking for feedback on CLI ergonomics, missing commands, and whether the JSX syntax feels natural.
A month later, he comes back to the engineering team with a 10k line "index.html" file asking "How do I hand this off?" (he was definitely smart enough to know that just passing that file to us was not gonna fly). We decided to copy the designs into Figma for the handoff, both because that was the existing way we did design/engineering handoffs and also because creating high fidelity designs (e.g., "this color from our design system" and "this standard spacing value") isn't in Cursor's wheelhouse.
We're probably going to spend more time working on a better setup for him. At the very least he should be working against our codebase and components and colors and design tokens. But I'm very curious to see where it goes from here.
Atomic component system, good page level template coverage, great prop support.
The LLM consumer nor the designer is allowed to write directly back to the library. Those changes need to go through a governance process to prevent drift as their are multiple product teams consuming it and we still don't have a reliable way to make sure Figma and the component library are always 1:1. Maybe in a company of a single designer.
So while this setup is arguably more fleshed out than what you have it still requires multiple humans in the loop.
Sure, there are a billion Medium articles about how it can be done with tokens but its much messier at any kind of scale.
I am somewhat fearful of having created a monster, but at the same time I think it’s good to knock down barriers to knowledge and learning. All else equal, I think a designer or PM with some exposure to code is better than one without.
What I’m fearful of are 10k line PRs and pressure from product to “just ship it.” Past a certain threshold a PR will be really tough to review, to the point that it would be preferable for an engineer to have handled it from the start.
I think we will need deeper integration between figma and the codebase/storybook. Shared color palette definitions, integration of storybook components with figma components, stuff like that.
The Figma MCP that you can use to handover to your agent and simply say “implement this” is already pretty impressive.
Basically, to really leverage this I think just knowing Figma perfectly previously or being a noobie and knowing Claude Code perfectly isn't gonna cut it.
Building things is fast, but building something that is gonna stick is gonna be more difficult now you have so many options.
The game has changed.
Personally, I’d really like to automate part of the workflow around exporting from Figma and assembling a design system into components — right now there’s just too much manual work involved.
You can provide the agent details to use either through skills or commands that provide reference and context to use. The agent can load when needed.
Having cli tool access provides me option to run the tools when I want to look at or do something as well.
# Read path data
figma-use path get <id>
# Set new path
figma-use path set <id> "M10,10 L90,50 L10,90 Z"
# Transform existing paths
figma-use path move <id> --dx 100 --dy 50
figma-use path scale <id> --factor 2
figma-use path flip <id> --axis x
SKILL.md updated tooIf I know my backend works I can use claude to add sufficient tests and iterate from there, improving code maturity. If my UX looks good how can I formalize it and do the same?
I can't wait to try this out. My current workflow has been use MCP to screenshot the whole app --> Use a tool like Codia to go from screenshot to components, as a non-designer its miserable though.
If I’m understanding correctly, you’d likely combine this with Figma MCP for reading? Ie. have Claude Code read the file to understand a request, then use this tooling to make modifications?
How does it do applying styles from an existing codebase?
We have style guides, strong base css, etc. If that was represented when it built in Figma, that could be interesting.
figma-use variable create "brand/primary" --collection <id> --type COLOR --value "#3B82F6"
Then reference them in JSX render: figma-use render ./Button.figma.tsx
const colors = defineVars({
primary: { name: 'brand/primary', value: '#3B82F6' },
})
export default () => (
<Frame style={{ backgroundColor: colors.primary }}>
<Text style={{ color: '#FFF' }}>Button</Text>
</Frame>
)
So if you map your design tokens to Figma variables first, components will reference them. Parsing CSS/Tailwind configs automatically could be a good feature though.Extra chars from JSON are the least of our problems with MCP.