Create skills for the Figma MCP server
Skills let you package a repeatable Figma workflow into a reusable instruction set. Instead of rewriting long prompts and re-explaining conventions each time, a skill gives your MCP client a stable sequence of steps to follow, which improves consistency and reduces drift across runs.
For the Figma MCP server specifically, custom skills are how you teach an agent to extend your existing design system rather than working around it. A well-written skill can direct the agent to search your libraries first, apply your variable naming and modes, and build with real components and auto layout structure that matches your team’s standards.
- Migrate legacy styles or one-off values to Variables using your library’s taxonomy (including light/dark or brand modes).
- Standardize or generate component sets to match your team’s variant/property conventions and token usage.
- Generate screens from existing library components, with validation steps to catch mismatches and iterate.
- Run “update and sync” workflows that check what exists, update what changed, and keep design assets aligned with code.
Set up your skill
To get started, follow the instructions for your client.
Claude Code (Anthropic)
- Create a skill directory in your repo:
.claude/skills/<skill-name>/. - Create
SKILL.mdin that directory:.claude/skills/<skill-name>/SKILL.md.
Codex by OpenAI
- In the Codex CLI or desktop app, run:
$skill-creator. - Follow the prompts; the creator will generate a new skill (a folder containing
SKILL.md).
Cursor
- In Cursor chat, run:
/create-skill. - Describe the skill you want and follow the prompts; Cursor will scaffold a new skill (a folder containing
SKILL.md, stored in your workspace skills location).
Craft your skill
-
Name your skill. Use a short, stable identifier in lowercase with hyphens, and make it match the skill folder name (for example,
convert-to-variables). -
Describe when the MCP client should use your skill. Write a
descriptionthat says what it does and when to use it (for example, “Build a full-page screen using existing library components and variables” rather than “Generate screens”). -
Add a clear title and purpose in the body. Start the markdown body with a
#heading that matches the workflow (for example,# Generate screen). -
List when to use it. Add a
## When to usesection with a few bullets describing the situations where this workflow applies. For example, “creating new screens that must follow an existing design system library”. -
Write the instructions as an ordered procedure. Add an
## Instructionssection with numbered steps the agent should follow, in the correct order, using imperative language. For example:- “Search the library first”
- “Bind fills/strokes/text to variables”
- “Prefer semantic tokens”
-
Include at least one concrete example. Add an
## Examplessection showing a representative input request and the expected output summary (what gets created/updated, at what scope). -
Document common edge cases and fallbacks. Add a
## Common edge casessection describing what to do when the ideal path fails. For example, missing components/tokens, ambiguous mappings, unsupported node types. -
Use optional frontmatter only when needed. Add fields like
compatibility,metadata, orallowed-toolsonly if you have a real requirement to express, such as “requires Figma MCP server tools” or internal ownership/versioning.
Advanced
As your skills become more capable, you may want to include more than a single SKILL.md file. In addition to the main instructions file, a skill can also include supporting files such as scripts, references, and assets.
These extra files are useful when your workflow needs more detail, reusable resources, or structured inputs. They can also help you keep the main SKILL.md focused on the core instructions, while moving longer or more specialized material into files the client can load only when needed.
Scripts
A skill can include executable scripts in a scripts/ folder. These are useful when part of the workflow is easier, safer, or more consistent to handle with code instead of with natural-language instructions alone.
For example, you might use a script to transform input data, validate a file before making changes, generate a repeated structure, or check output for common errors. In general, scripts work best when they are self-contained, clearly document any dependencies, and return helpful error messages so the MCP client can understand what happened and what to do next.
References
A skill can also include additional documentation in a references/ folder. Reference files are helpful when your workflow depends on more detailed guidance than you want to place in the main SKILL.md.
For example, you might include a naming guide, a variable taxonomy, component rules, a schema reference, or a longer technical playbook for a specific workflow. Keeping these files focused and scoped to a single topic makes them easier for the MCP client to use when needed, without adding unnecessary length to the main skill instructions.
Assets
A skill can include static resources in an assets/ folder. Assets are useful when the workflow depends on reusable materials that the MCP client may need to read from, compare against, or use as a starting point.
For example, assets might include templates, example files, diagrams, lookup tables, or structured data files. In a Figma workflow, this could mean things like a starter content template, a naming map, or an example of the output structure you want the client to follow. Assets are especially useful when you want your skill to produce results that are more consistent across files, teams, or repeated runs.