Create Figma Sync skill [WIP]

[LanesGood]

This skill adds the figma-sync-codebase skill, which scans a project’s UI code and generates a matching Figma file with the same component structure, styles, and routed pages. It maps library components, local composites, and design tokens to a 1:1 code-to-Figma representation to align design with implementation.

I created this skill with the help of Claude, have used it locally on multiple projects, and find it to provide a quite useful starting point.

Why does this exist?
This skill is mainly for use on projects that already have a codebase with frontend UI code, but no designs in Figma. Designers tasked with updating a project or adding new features often need to recreate a project from scratch in design tools. We can take shortcuts and just use layered screenshots, adding new design elements as needed, or even just wireframe or even ignore existing features in favor of speed. However, rebuilding a codebase in design grants designers the ability to make global changes that can then be reviewed and accepted by stakeholders before implementation, and/or can ensure that new features are designed with existing structural or product limitations and business needs in mind.

Prompting with a generic "generate designs for X project in Figma" command in Claude will typically create screens that either are approximations of screenshots, or are simply not accurate. This skill relies on both the official figma-mcp plugin and the powertool figma-console-mcp to instead reproduce a codebase in the most accurate and componentized way possible. It does this by:

1. Inspecting the codebase for existing use of common UI libraries which already have equivalent Figma design libraries
2. Creating an appropriate project-level page structure for new Figma files
3. Capturing all local color, typography and other design system variable definitions, and mapping these in the figma file
4. Creating a figma page for each defined route in the application (assuming routing does a lot of the heavy lifting of a product)
5. Creating local (to the figma file) reusable figma components any time a UI component is reused in the codebase
6. Staying faithful to the naming of components and wrapping elements in the codebase, using these in the Figma layers panel
7. Using real content when possible - inserting content from tests or mocks if those exist in the codebase

There are a lot of gotchas/project-specific things that may prevent this from being a widely useful public skill including:

• the requirement of having a Figma account already to use the skill, with the appropriate plan level to use libraries
• the requirement of having Figma-mcp and Figma-console-mcp installed
• A strong predisposition to UI libraries (Radix, ChakraUI, ShadCN, etc)
• Claude can have a hard time with figma libraries, and sometimes requires manual connections to these.
• Icons are often recreated from scratch.

There are also lots of areas that could still be customized or treated as user options - things like the "single page for every route" could potentially be further configured so that there is just one figma page for each route screen.

The skill does seem to use a lot of tokens - I'm not entirely sure how much is normal. Running this on a recent project, to create file structure, design tokens, shared local components, and the irst full screen took ~178,000 tokens. Claude says each additional screen in this project would be 15,000–25,000 tokens, and there are 20 routes identified in this project for a total of 250,000–400,000 tokens.

This could use a review from @dannybauman @wrynearson or @yellowcap for a review of best practices for Claude Skills. I'm unsure if this is an appropriate length or format. Would also love for @ricardoduplos @faustoperez @fannycc to test this out for greater refinement and ensuring it is applicable across design contexts.

[dannybauman]

awesome thanks @LanesGood !

I haven't tested the actual Figma part so I'll leave that to others to confirm. as for Skill best practices, I'm still learning, here are some thoughts I had (with Claude's help):

length and format

the file length of your SKILL.md is long but ok, the issue is that all 450 lines load every run. ~150 lines are Figma MCP reference material (the tool table, the libraryKey vs fileKey distinction, what each tool can and can't do, the community library mappings, the 3 JS snippets) and those only matter once you're deep in a build. you could decompose this into smaller pieces and have it only load what's needed. See veda-story-creator in this repo as an example: a ~200 line SKILL.md with other files (datasets.md, examples.md, lessons.md) that get pulled in when needed.

parts to turn into a script

the skill asks Claude to read the codebase and work out the imports, the components, the theme tokens, the routes and the test data. It does that from scratch on every run, gets it slightly different each time, and it doesn't say what it found before it starts writing to Figma.

A small code script that does the reading and spits out one JSON file would fix all 3 of those. It runs once and it's cheap, and would reduce the need to use tokens. You or another dev can look at the output file and fix anything it got wrong before anything gets written to Figma. And when the code changes later, you compare the new file to the old one instead of rebuilding everything, which is what would make it "sync" both ways.

Two similar small things:

• the page setup in Step 1 (Cover, Tokens, Components, one per route, Desktop/Mobile/States at 160/80/120) is always the same steps, so it doesn't need to be described in markdown, it could be a script
• Step 10 says to check that every layer uses auto layout, that overrides are bound to variables, and that components match their code counterparts. Those are things a script can check. Right now Claude just eyeballs it

Everything that needs a judgment call can stay as it is, that's where markdown/LLMs are helpful.

small stuff to fix

• the description: field is blank. That line is what tells Claude when to use the skill, so with it empty the skill never fires
• there are 3 different names: devseed-figma-sync-codebase at the top, figma-sync as the folder, figma-sync-codebase as the heading
• it's not listed in this repo's marketplace.json, so /plugin install won't find it. most of the skills here also have a .claude-plugin/plugin.json
• the README template has a Requirements section worth filling in: which Figma plan you need, both MCPs, and a link to figma-use, which comes up 4 times without an explanation of what it is

The skill saves Figma file keys, library keys, and variant keys into the project's CLAUDE.md in 8 different places. CLAUDE.md gets read at the start of every session in that repo, so everyone loads those keys whether they use this skill or not, and they end up committed for everyone. A figma-sync.profile.json in .gitignore would keep them on your machine.