Skills in Figma MCP: How to Transmit Your Team Rules to AI in a Single File

Each designer on the team writes AI prompts in their own way. One asks “make a component of the card”, the second – “a card according to our design guide, tokens from the Foundation library, indents for 8”, the third generally copies someone else’s prompt from Notion and is angry that it does not work. The output is three different components, three different sets of layers, three different ways to name variables.

The problem is not people or models. The problem is that the rules of the team live in minds, in Confluence and in the Figma library, and AI doesn’t know about them. Every conversation starts from scratch. Skills in Figma MCP is an attempt to close this gap: one rule file that the agent picks up automatically and then speaks the language of your command rather than the general Internet.

## What is Skills in the Context of MCP

MCP (Model Context Protocol) is a way to connect an AI agent with external sources: Figma, repository, design tokens, documentation. Skill is neither a plugin nor a model. This is an instruction: a set of rules, context, and examples that an agent reads before doing something.

If you simplify to everyday language: MCP is an outlet, Skill is a memo “as we do”. Without a memo, the agent works “in general”, with a memo – specifically for your system.

### What is usually in the Skill file

• Names and structure of your design system (libraries, tokens, nemespaces)
• Rules of naming layers, components, variants
• Grid, indentations, typographical scale
• What NOT to do (anti-team patterns)
• Examples of “was and became” on typical tasks
• References to sources of truth: Figma file ID, token repository, guidelines

It's not documentation for people. This is an instruction for an agent, written so that he can execute it, not quote it.

## Why it suddenly became important

A year ago, AI at Figma was a toy: "generate a cover," "invent an icon." Now agents are actually assembling screens, renaming layers, creating options, fixing auto-layouts. And here comes the same pain as with the Juns: without rules, they work quickly, but not there.

The teams faced typical scenarios:

• The agent creates a component past the library — looks like a new Frame with hard-cut flowers inside.
• The layers are called Frame 1247, Group, Rectangle 12 – after the agent, the file cannot be maintained.
• The wrong font token is used: it visually matches, breaks the theme in production.
• At the review, you have to explain the same thing every time: “We have 4/8/12/16 indentations, not arbitrary.”.

Skill relieves this recurring pain at the protocol level, not at the "let's negotiate again" level.

### When Skills Pay Off Exactly

• A team of three designers and a shared library.
• A design system with tokens, not just a style guide in PDF.
• Contractors or new people are connected regularly.
• AI is already used in daily work, not on Fridays to play.

If you are one person on a project without a system - Skill is not needed, a good system prompt will be enough.

## What does the minimum working Skill look like

It is not necessary to describe the entire design system at once. The minimum version is one markdown file that answers five questions.

### Checklist of first version

• What library is the source of truth (file ID, name)
• What tokens to use for color, typography, indentations
• How to name layers and components (pattern, examples)
• What counts as a mistake (3-5 anti-team patterns)
• One example of a typical problem as a whole: input, expected result, unwanted result

This is enough for the agent to stop hallucinating the structure and start working within your framework. Then Skill grows as you notice where it stumbles.

### Anti-Patterns of the First Version

• Copy the entire 80-page Figma guideline in Skill. The agent drowns in context, the important disappears.
• To write abstractly: “follow the principles of clarity and consistency.” This is a non-working instruction, the agent can't check it.
• Make Skill "for the future": describe tokens that are not yet in the library. Skill should reflect the current system, not the desired one.
• Hide Skill from one person in a personal folder. Then the team again has three different sets of rules, only now they are sewn into files.

### Questions for a review of your Skill

• Will the new designer, having read only this file, be able to assemble a typical screen?
• Is there any particular example of an “unwanted result” in the file?
• Do all these tokens and components actually exist in the library?
• What happens if the name of the library changes tomorrow - how painful will it be for Skill to rule?

Skill is not magic or a new format of documentation. This is a compact instruction that translates your command rules into the agent’s language and eliminates the need to explain the same thing in each prompt.

## Workflow: how Skill lives within the team

Skill doesn’t work like a file that was put in a repository and forgotten. He lives by the same rules as the design system itself: if no one is watching him, after two months, the agent begins to produce a result that contradicts the current library. Therefore, the process is more important than the content of the first version.

### Minimum cycle of work

1. The designer tasks the agent through Figma MCP, the agent pulls up Skill automatically.
2. The agent returns the result: components, variants, layers, tokens.
3. The designer checks not “beautiful”, but compliance with the rules from Skill.
4. If the agent misses, it is not “he is stupid” that is fixed, but a specific point that Skill lacks.
5. Skill is supplemented, PR-review runs like a regular code review, the new version goes to the public.

This is exactly the same cycle as the frontend with the linter. Skill is a lense for an agent, and its rules are written for the same reasons: something broke.

### Where Skill should lie

• In the same repository as the tokens, or next to the guidelines.
• Under versioning, with understandable commits of the form "added a rule about spacing in forms.".
• With one owner (usually a system designer), but with the ability to offer edits from anyone.
• Not Notion. Notion-page agent will not pick up automatically, and it instantly diverges from the real library.

## Diagnosis: How to tell if Skill is broken

The agent almost never says, “I didn’t understand the rule.” He's silently doing the wrong thing. Therefore, diagnosis is not reading logs, but observing the result.

### Signs Skill is Time to Fix

• The same type of error is repeated in different tasks, meaning that Skill has no rule or is vague.
• The agent selects a component from an old library you've already deprecated.
• The layers are named after a pattern the team has not used for six months.
• At a review someone says, "Why did he do that?" and no one can answer.
• When changing the topic or rebranding, half of the agency layouts fall apart.

If at least one item is stable is not an agent bug, it is a gap in Skill.

### Quick Skill quality check

Take a typical task: “gather a screen of profile settings on our system”. Run it through the agent twice - morning and evening, in different sessions. Compare the result.

• If the results are different in structure, Skill is not specific enough.
• If both results are wrong, Skill takes the agent in the wrong direction.
• If both are correct and the same in structure, Skill works.

## Typical team mistakes

### Skill becomes a landfill

Every time an agent makes a mistake, a new rule is added to the file. In six months, that's 40 pages of contradictory instructions. The agent begins to ignore some of them because they are in conflict.

The solution is simple: once in a sprint, someone passes Skill and removes rules that are no longer needed, combines takes, rewrites what is outdated. This is the same hygiene as the components in the library.

### Skill is written with documentation, not instructions

“Components must be consistent with the principles of the system” is not a rule, it is a slogan. The agent can't verify that. “Use only components from the Core UI v3 library, so-and-so ID.” If you don’t have the right component, stop the task and ask, that’s the rule.

### Skill does not reflect the actual review process

If the team at the review always picks on indentations in forms, and in Skill there is no word about the form - this is the most expensive hole. Skill should cover exactly the mistakes you catch. Then the review becomes shorter, not longer.

### Skill one for all products

If you have a mobile application and an admin with different density, different components and different typography, one Skill will not cope. You need two, and the agent must understand which context to pull up. This is usually done through the structure of an MCP project, rather than through heroic attempts to fit everything into a single file.

## How a designer can apply this to the layout

### Scenario: assembling a new screen

You don't text an agent to "make the profile screen beautiful." You formulate the problem as TK: what flow, what states, what data. Skill pulls up itself and closes the questions with “what components”, “what indentations”, “how to call layers”. Your job is to check logic and states, not indentations.

### Scenario: Migration of the Old Model

You take a legacy file, where half of it is past the system. Ask the agent to move to the current library. Skill is critical here: without it, the agent will drag some of the old styles as "similar." With a good Skill, he dwells on components that aren't in the new system and asks explicitly.

### Scenario: contractor on the project

The contractor does not need to delve into your system for two weeks. He works through the same agent with the same Skill. The result at the entrance to the review is closer to your standards than the average indoor june without Skill.

### Questions for an agency layout review

• Are all components from the current library, not visual twins?
• Do the tokens match the ones in Skill?
• Are there no hardcut values where the token should be?
• Are the layers named after the team pattern or is it Frame 1832?
• Are there states that float requires, or has the agent only defaulted?

Skill pays off not when you write it, but when the team stops repeating the same remarks at the review. If this effect is not visible after a couple of sprints, fix not the agent, but the file.

## Advanced scenarios: where Skill really pulls

After a couple of sprints on basic tasks, there is a temptation to stop. Don't be. The most interesting thing begins where the designer used to spend half a day on “assembling correctly” rather than “inventing”.

### Scenario: Versioning of the design system

The library rarely stands still. You rolled out v3, but half the product files are still on v2. If Skill is rigidly tied to one version, it either breaks down old layouts or inhibits migration.

The working approach is two modes in one Skill. The first is: “We are working in the current version, we only use it.” Second, we work in legacy, we don’t offer v3 components, but we mark the places where they should be tightened in the next iteration. The agent should explicitly ask what mode the task is in unless it is obvious from the file.

### Scenario: design variations under A/B

When a product asks “give two versions of onboarding, one shorter by a step,” copypaste and discrepancies usually begin. Skill relieves this pain: you describe what changes (step count, CTA, illustrations) and ask the agent to assemble both versions from the same system. The main rule in Skill: variations differ only in what is stated in the TK. Everything else is identical to the pixel.

### Scenario: Multi-brand system

One food frame, several brands on top. It used to turn into five parallel files and constant drift. Skill+MCP allows you to keep the structure one and the theme variable. The file states: “structural tokens are single, color and typographic are pulled up from the brand preset.” When switching a brand, the agent has no right to touch the structure.

## Team Context: Whose Business Is It

Skill is not a personal lead folder. It's a team artifact, and you have to treat it like code.

### Who owns

There should be one person in charge of Skill: usually a design systemist or lead. Not “everyone can rule,” but “everyone can offer, merjit alone.” Otherwise, in a month, three ways to name layers and two conflicting rules about indentations will appear in the file.

### How to make changes

Any change in Skill is a PR with a description: what we change, why, what case broke without it. The review does not look at the wording, but at whether the rule covers the real problem. If the rule is added "just in case" - reject.

### Anti-teamwork patterns with Skill

• Skill lives with one person on a computer, the rest learn about the rules after the fact.
• No one knows which version is relevant because it is in three places.
• Designers rule Skill over their task and don’t bring changes back.
• Skill is written by some, and reviews of agency layouts are done by others - and they do not compare.

## How to explain decisions to the team and stakeholders

When a product asks “why this screen is assembled this way,” the standard answer is “because the system” no longer rolls. Skill makes the best argument: here's the rule, here's the line, that's why it came about.

### Transparency as a side effect

Previously, design decisions were in the designer’s head. Now some of them are in a text file available to everyone. This changes the conversation with the development and product: the argument “I think the button should be higher” turns into “let’s see what about this in Skill, and update if it is outdated.”.

### What to show on demo

Not Skill itself - it's boring. Show before/after: the same request to an agent with an empty Skill and a combat one. The difference in the number of revisions convinces faster than any slides.

### Skill maturity checklist in the team

• The file has one person in charge and the team knows who it is.
• Change goes through a review, not directly.
• On the review of layouts, there is a habit of checking "whether it matches Skill.".
• Once in a sprint, someone cleans the file of outdated rules.
• The new designer understands in a day how Skill works, without personal explanation.
• Contractors get the same Skill as the team, without a simplified version.

### Questions to ask yourself before the next release

• Which of the three comments was repeated most often in the last review? Are they in Skill?
• That Skill never worked in a quarter? Why is it there?
• If the author of Skill leaves tomorrow, will the team be able to support him?

In a nutshell, advanced Skill is no longer a rule file, but a way to negotiate within a team what counts as “our.” The agent here is simply the most diligent performer of this arrangement, who never forgets the rule about indentations in forms.

## Anti-patterns of Skill itself: what should not be in the file

Teams quickly reach the point of starting a Skill. Then the interesting thing begins: the file lives, overgrown with rules and gradually turns into a dump if you do not follow it.

### Skill Romance

A twenty-screen file that has everything: brand history, philosophy, links to Behance, motivational quotes. The agent reads it, but it's 10% of the practical. The rest is noise that blurs priorities. Skill is not onboarding for Jun, it is a work instruction.

### The Twin Rules

"Use grid 8" and through three sections "indentations are multiples of 8". Formally, they do not contradict, but the agent begins to figure out which rule is more important. Any duplication sooner or later diverges – one is corrected, the second is forgotten.

### Hidden exceptions

“We usually do that, but marketing landings are different, and on on-boarding is different.” If there are more than two exceptions, this is not an exception, but a separate regime. It should be put in your Skill or in the explicit “context: marketing” block.

### Rules without example

“Use a clear hierarchy of headlines.” What does "understand" mean - the agent does not know, the person on the review is also arguing. Any rule that cannot be checked by looking at the layout is useless. Either rewrite before the test, or delete.

### Skill as a stilgide

Token descriptions, component specifications, accessibility rules are dragged there. It's already in Figma and in the design system. Skill should refer to the source of truth, not duplicate it. Otherwise, when you update the system, the file becomes obsolete silently.

## Skill health checklist

Walk through it once in a sprint. If the answer is no, it’s time to sit down and clean.

• Each rule can be checked by looking at the layout, without guessing.
• There are no two rules that say the same thing in different words.
• All exceptions are clearly marked, not hidden in the text.
• From the file deleted everything that has never been useful in the quarter.
• For every complicated rule, there is an example of "so-yes, so-no.".
• Skill refers to the design system, not retells it.
• The length of the file does not grow linearly with age - the old leaves, the new comes.
• The new person on the team understands the unaccompanied file structure.

## Questions for review layouts collected by Skill

When the agent brings results, refrain from the usual “well, like norms” and go through the list. It takes five minutes and covers most of the problems.

• Which Skill rule does this layout break? If not, were you really looking closely?
• What in the layout is done “by eye”, without relying on the rule? Is it a gap in Skill or an allowable freedom?
• If tomorrow another agent collects the same screen on the same Skill, will the result be the same or will it vary greatly?
• What decision did the agent make for you? Do you agree that this is his area and not yours?
• What in this layout will you rule your hands before surrendering? Why doesn't Skill do that?

The last question is the most useful. Any manual editing after an agent is either a bug in Skill or a conscious exception. There is no third option, and both require action: either to finalize the rule, or to fix that it is always manual.

## When it’s time to rewrite Skill from scratch

Sometimes cosmetic cleaning is not enough. Signs that the file has lived:

• Editing in Skill became more common than editing in the layouts themselves.
• For each new product, you have to add a block of exceptions.
• The team bypasses Skill - "I know it says it, but let's do it differently.".
• No one remembers why half the rules were added.

At this point, it's cheaper to sit down for a day and assemble a new Skill from last quarter practice than to patch up the old one.

## Short summary

Skill is a team contract with itself, written so that it can be executed by an agent. It works as long as it stays short, verifiable and alive: rules are added for real pain, removed for non-use, rehearsed as code. Everything else is jewelry that looks beautiful in the first month and interferes with the third.