Skills в Figma MCP: как передать AI правила вашей команды одним файлом

Каждый дизайнер в команде по-своему пишет промпты к AI. Один просит «сделай компонент карточки», второй — «карточка по нашему дизайн-гайду, токены из библиотеки Foundation, отступы по 8», третий вообще копирует чужой промпт из Notion и злится что не работает. На выходе три разных компонента, три разных набора слоёв, три разных способа называть переменные.

Проблема не в людях и не в моделях. Проблема в том, что правила команды живут в головах, в Confluence и в Figma-библиотеке, а AI о них не знает. Каждый разговор начинается с нуля. Skills в Figma MCP — попытка закрыть этот разрыв: один файл с правилами, который агент подхватывает автоматически, и дальше говорит на языке вашей команды, а не общего интернета.

## Что такое Skills в контексте MCP

MCP (Model Context Protocol) — это способ соединить AI-агента с внешними источниками: Figma, репозиторий, дизайн-токены, документация. Skill — это не плагин и не модель. Это инструкция: набор правил, контекста и примеров, который агент читает перед тем как что-то сделать.

Если упрощать до бытового языка: MCP — это розетка, Skill — это памятка «как у нас принято». Без памятки агент работает «вообще», с памяткой — конкретно под вашу систему.

### Что обычно лежит в Skill-файле

• Названия и структура вашей дизайн-системы (библиотеки, токены, неймспейсы)
• Правила нейминга слоёв, компонентов, вариантов
• Сетка, отступы, типографическая шкала
• Что точно нельзя делать (анти-паттерны команды)
• Примеры «было — стало» на типовых задачах
• Ссылки на источники истины: Figma file ID, репозиторий токенов, гайдлайны

Это не документация для людей. Это инструкция для агента, написанная так, чтобы он её мог исполнить, а не процитировать.

## Почему это вдруг стало важным

Год назад AI в Figma был игрушкой: «сгенерируй обложку», «придумай иконку». Сейчас агенты реально собирают экраны, переименовывают слои, создают варианты, чинят авто-лейаут. И здесь вылезает та же боль, что и с джунами: без правил они работают быстро, но не туда.

Команды столкнулись с типовыми сценариями:

• Агент создаёт компонент мимо библиотеки — внешне похоже, внутри новый Frame с захардкоженными цветами.
• Слои называются Frame 1247, Group, Rectangle 12 — после агента файл невозможно поддерживать.
• Используется не тот шрифтовой токен: визуально совпадает, в продакшене ломает тему.
• На ревью каждый раз приходится объяснять одно и то же: «у нас отступы 4/8/12/16, не произвольные».

Skill снимает эту повторяющуюся боль на уровне протокола, а не на уровне «давайте договоримся ещё раз».

### Когда Skills точно окупаются

• Команда от трёх дизайнеров и общая библиотека.
• Дизайн-система с токенами, а не просто стайл-гайд в PDF.
• Регулярно подключаются подрядчики или новые люди.
• AI уже используется в ежедневной работе, а не «по пятницам поиграться».

Если вы один человек на проекте без системы — Skill не нужен, хватит хорошего системного промпта.

## Как выглядит минимальный рабочий Skill

Не нужно сразу описывать всю дизайн-систему. Минимальная версия — это один markdown-файл, который отвечает на пять вопросов агента.

### Чеклист первой версии

• Какая библиотека — источник истины (ID файла, название)
• Какие токены использовать для цвета, типографики, отступов
• Как называть слои и компоненты (паттерн, примеры)
• Что считается ошибкой (3–5 анти-паттернов команды)
• Один пример типовой задачи целиком: вход, ожидаемый результат, нежелательный результат

Этого достаточно, чтобы агент перестал галлюцинировать структуру и начал работать в ваших рамках. Дальше Skill растёт по мере того, как вы замечаете, на чём он спотыкается.

### Анти-паттерны первой версии

• Копировать в Skill весь Figma-гайдлайн на 80 страниц. Агент утонет в контексте, важное растворится.
• Писать абстрактно: «следуй принципам ясности и консистентности». Это нерабочая инструкция, агент не сможет её проверить.
• Делать Skill «на будущее»: описывать токены, которых ещё нет в библиотеке. Skill должен отражать текущую систему, а не желаемую.
• Прятать Skill у одного человека в личной папке. Тогда у команды снова три разных набора правил, только теперь они зашиты в файлы.

### Вопросы для ревью своего Skill

• Сможет ли новый дизайнер, прочитав только этот файл, собрать типовой экран?
• Есть ли в файле хоть один конкретный пример «нежелательного результата»?
• Все ли упомянутые токены и компоненты реально существуют в библиотеке?
• Что произойдёт, если завтра поменяется название библиотеки — насколько больно будет править Skill?

Короткий итог по этой части: Skill — это не магия и не новый формат документации. Это компактная инструкция, которая переводит правила вашей команды на язык агента и убирает необходимость объяснять одно и то же в каждом промпте.

## Рабочий процесс: как Skill живёт внутри команды

Skill не работает как файл, который один раз положили в репозиторий и забыли. Он живёт по тем же законам, что и сама дизайн-система: если за ним никто не следит, через два месяца агент начинает выдавать результат, который противоречит текущей библиотеке. Поэтому процесс важнее, чем содержимое первой версии.

### Минимальный цикл работы

1. Дизайнер ставит задачу агенту через Figma MCP, агент подтягивает Skill автоматически.
2. Агент возвращает результат: компоненты, варианты, слои, токены.
3. Дизайнер проверяет не «красиво ли», а соответствие правилам из Skill.
4. Если агент промахнулся — фиксируется не «он тупой», а конкретный пункт, которого в Skill не хватает.
5. Skill дополняется, PR-ревью проходит как обычный код-ревью, новая версия уезжает в общий доступ.

Это ровно тот же цикл, что у фронтенда с линтером. Skill — линтер для агента, и его правила пишутся по тем же поводам: что-то поломалось — добавили правило.

### Где Skill должен лежать

• В том же репозитории, что и токены, или рядом с гайдлайнами.
• Под версионированием, с понятными коммитами вида «добавили правило про spacing в формах».
• С одним владельцем (обычно дизайн-системщик), но с возможностью предложить правку у любого.
• Не в Notion. Notion-страницу агент не подхватит автоматически, и она моментально расходится с реальной библиотекой.

## Диагностика: как понять, что Skill сломался

Агент почти никогда не говорит «я не понял правило». Он молча делает не то. Поэтому диагностика — это не чтение логов, а наблюдение за результатом.

### Признаки, что Skill пора чинить

• Один и тот же тип ошибки повторяется в разных задачах: значит, в Skill нет правила или оно сформулировано размыто.
• Агент выбирает компонент из старой библиотеки, которую вы уже депрекейтнули.
• Слои называются по паттерну, который команда не использует уже полгода.
• На ревью кто-то говорит: «а почему он сделал так?» — и никто не может ответить.
• При смене темы или ребрендинге половина агентских макетов рассыпается.

Если хоть один пункт стабильно встречается — это не баг агента, это пробел в Skill.

### Быстрая проверка качества Skill

Возьмите типовую задачу: «собери экран настроек профиля по нашей системе». Прогоните её через агента дважды — утром и вечером, в разных сессиях. Сравните результат.

• Если результаты разные по структуре — Skill недостаточно конкретен.
• Если оба результата неправильные одинаково — Skill уводит агента не туда.
• Если оба правильные и совпадают по структуре — Skill работает.

## Типичные ошибки команд

### Skill превращается в свалку

Каждый раз, когда агент ошибается, в файл добавляется новое правило. Через полгода это 40 страниц противоречивых инструкций. Агент начинает игнорировать часть из них, потому что они конфликтуют.

Решение простое: раз в спринт кто-то проходит Skill и удаляет правила, которые больше не нужны, объединяет дубли, переписывает то, что устарело. Это та же гигиена, что и с компонентами в библиотеке.

### Skill пишется языком документации, а не инструкции

«Компоненты должны быть согласованы с принципами системы» — это не правило, это лозунг. Агент не может это проверить. «Используй только компоненты из библиотеки Core UI v3, ID такой-то. Если нужного компонента нет — останови задачу и спроси» — это правило.

### Skill не отражает реальный процесс ревью

Если в команде на ревью всегда придираются к отступам в формах, а в Skill про формы нет ни слова — это самая дорогая дыра. Skill должен закрывать ровно те ошибки, которые вы и так ловите глазами. Тогда ревью становится короче, а не длиннее.

### Skill один на все продукты

Если у вас мобильное приложение и админка с разной плотностью, разными компонентами и разной типографикой — один Skill не справится. Нужны два, и агент должен понимать, в каком контексте какой подтягивать. Обычно это решается через структуру MCP-проекта, а не через героические попытки впихнуть всё в один файл.

## Как дизайнеру применять это в макете

### Сценарий: сборка нового экрана

Вы не пишете агенту «сделай экран профиля красиво». Вы формулируете задачу как ТЗ: какой флоу, какие состояния, какие данные. Skill подтягивается сам и закрывает вопросы «какими компонентами», «какими отступами», «как называть слои». Ваша задача — проверить логику и состояния, а не отступы.

### Сценарий: миграция старого макета

Берёте легаси-файл, где половина — мимо системы. Просите агента переехать на актуальную библиотеку. Skill здесь критичен: без него агент перетащит часть старых стилей как «похожие». С хорошим Skill он останавливается на компонентах, которых нет в новой системе, и спрашивает явно.

### Сценарий: подрядчик на проекте

Подрядчику не нужно две недели вникать в вашу систему. Он работает через того же агента с тем же Skill. Результат на входе в ревью ближе к вашим стандартам, чем у среднего внутреннего джуна без Skill.

### Вопросы для ревью агентского макета

• Все ли компоненты — из текущей библиотеки, а не визуальные двойники?
• Совпадают ли токены с теми, что прописаны в Skill?
• Нет ли захардкоженных значений там, где должен быть токен?
• Слои названы по паттерну команды или это «Frame 1832»?
• Есть ли состояния, которых требует флоу, или агент сделал только дефолт?

Короткий итог по этой части: Skill окупается не в момент, когда вы его написали, а в момент, когда команда перестала повторять одни и те же замечания на ревью. Если этот эффект не виден через пару спринтов — чините не агента, а файл.

## Продвинутые сценарии: где Skill реально вытягивает

После пары спринтов на базовых задачах появляется соблазн остановиться. Не стоит. Самое интересное начинается там, где раньше дизайнер тратил полдня на «правильно собрать», а не на «придумать».

### Сценарий: версионирование дизайн-системы

Библиотека редко стоит на месте. Вы выкатили v3, но половина продуктовых файлов ещё на v2. Если Skill жёстко привязан к одной версии, он либо ломает старые макеты, либо тормозит миграцию.

Рабочий подход — два режима в одном Skill. Первый: «работаем в актуальной версии, используем только её». Второй: «работаем в legacy, не предлагаем v3-компоненты, но помечаем места, где их стоит подтянуть при следующей итерации». Агент должен явно спрашивать, в каком режиме задача, если это не очевидно из файла.

### Сценарий: дизайн-вариации под A/B

Когда продакт просит «дай две версии онбординга, одна короче на шаг», обычно начинается копипаста и расхождения в мелочах. Skill снимает эту боль: вы описываете, что именно меняется (количество шагов, CTA, иллюстрации), и просите агента собрать обе версии из одной системы. Главное правило в Skill: вариации отличаются только тем, что заявлено в ТЗ. Всё остальное — идентично до пикселя.

### Сценарий: мультибрендовая система

Один продуктовый каркас, несколько брендов сверху. Раньше это превращалось в пять параллельных файлов и постоянный дрейф. Skill+MCP позволяет держать структуру одной, а тему — переменной. В файле прописывается: «структурные токены едины, цветовые и типографические подтягиваются из бренд-пресета». При переключении бренда агент не имеет права трогать структуру.

## Командный контекст: чьё это вообще хозяйство

Skill — это не «личная папка лида». Это артефакт команды, и относиться к нему надо как к коду.

### Кто владелец

В команде должен быть один человек, отвечающий за Skill: обычно это дизайн-системщик или лид. Не «все могут править», а «все могут предложить, мерджит один». Иначе через месяц в файле появятся три способа называть слои и два конфликтующих правила про отступы.

### Как принимать изменения

Любое изменение в Skill — это PR с описанием: что меняем, почему, какой кейс сломался без этого. На ревью смотрят не на формулировку, а на то, закрывает ли правило реальную проблему. Если правило добавляется «на всякий случай» — отклонять.

### Антипаттерны командной работы со Skill

• Skill живёт у одного человека на компьютере, остальные узнают о правилах постфактум.
• Никто не знает, какая версия актуальна, потому что лежит в трёх местах.
• Дизайнеры правят Skill под свою задачу и не возвращают изменения обратно.
• Skill пишут одни, а ревью агентских макетов делают другие — и они не сверяются.

## Как объяснять решения команде и стейкхолдерам

Когда продакт спрашивает «почему этот экран собран именно так», стандартный ответ «потому что система» больше не катит. Skill даёт лучший аргумент: вот правило, вот строчка, вот почему оно появилось.

### Прозрачность как побочный эффект

Раньше дизайн-решения были в голове у дизайнера. Теперь часть из них — в текстовом файле, доступном всем. Это меняет разговор с разработкой и продактом: спор «мне кажется, кнопка должна быть выше» превращается в «давайте посмотрим, что про это в Skill, и обновим, если устарело».

### Что показывать на демо

Не сам Skill — он скучный. Показывайте до/после: один и тот же запрос к агенту с пустым Skill и с боевым. Разница в количестве правок на ревью убеждает быстрее любых слайдов.

### Чеклист зрелости Skill в команде

• У файла есть один ответственный, и команда знает, кто это.
• Изменения проходят через ревью, а не пушатся напрямую.
• На ревью макетов есть привычка проверять «совпадает ли это со Skill».
• Раз в спринт кто-то чистит файл от устаревших правил.
• Новый дизайнер за день понимает, как Skill устроен, без личных объяснений.
• Подрядчики получают тот же Skill, что и команда, без «упрощённой версии».

### Вопросы, которые стоит задать себе перед следующим релизом

• Какие три замечания на последнем ревью повторялись чаще всего? Они есть в Skill?
• Что в Skill ни разу не сработало за квартал? Зачем оно там?
• Если завтра уйдёт автор Skill, команда сможет его поддерживать?

Короткий итог: продвинутый Skill — это уже не файл с правилами, а способ договориться внутри команды о том, что считается «нашим». Агент тут — просто самый прилежный исполнитель этой договорённости, который никогда не забывает правило про отступы в формах.

## Анти-паттерны самого Skill: чего не должно быть в файле

Команды быстро доходят до того, чтобы завести Skill. Дальше начинается интересное: файл живёт, обрастает правилами и постепенно превращается в свалку, если за ним не следить.

### «Скилл-роман»

Файл на двадцать экранов, в котором есть всё: история бренда, философия, ссылки на Behance, мотивирующие цитаты. Агент это читает, но из практического остаётся 10%. Остальное — шум, который размывает приоритеты. Skill — не онбординг для джуна, это рабочая инструкция.

### Правила-близнецы

«Используй сетку 8» и через три раздела «отступы кратны 8». Формально не противоречат, но агент начинает додумывать, какое правило важнее. Любое дублирование рано или поздно расходится — одно поправили, второе забыли.

### Скрытые исключения

«Обычно делаем так, но в маркетинговых лендингах иначе, и ещё на онбординге другое». Если исключений больше двух — это уже не исключение, а отдельный режим. Его надо выносить в свой Skill или в явный блок «контекст: маркетинг».

### Правила без примера

«Используй понятную иерархию заголовков». Что значит «понятную» — агент не знает, человек на ревью тоже спорит. Любое правило, которое нельзя проверить взглядом на макет, бесполезно. Либо переписывайте до проверяемого, либо удаляйте.

### Skill как стилгайд

Туда тащат описания токенов, спецификации компонентов, правила доступности. Это всё уже есть в Figma и в дизайн-системе. Skill должен ссылаться на источник истины, а не дублировать его. Иначе при обновлении системы файл устаревает молча.

## Чеклист здоровья Skill

Пройдитесь по нему раз в спринт. Если по трём пунктам ответ «нет» — пора садиться и чистить.

• Каждое правило можно проверить, глядя на макет, без догадок.
• Нет двух правил, говорящих об одном и том же разными словами.
• Все исключения явно помечены, а не спрятаны в тексте.
• Из файла удалено всё, что ни разу не пригодилось за квартал.
• На каждое сложное правило есть пример «так — да, так — нет».
• Skill ссылается на дизайн-систему, а не пересказывает её.
• Длина файла не растёт линейно с возрастом — старое уезжает, новое приходит.
• Новый человек в команде понимает структуру файла без сопровождения.

## Вопросы для ревью макетов, собранных по Skill

Когда агент приносит результат, удержитесь от привычного «ну вроде норм» и пройдитесь по списку. Это занимает пять минут и закрывает большую часть проблем.

• Какое правило из Skill этот макет нарушает? Если ни одного — точно ли вы смотрели внимательно?
• Что в макете сделано «на глаз», без опоры на правило? Это пробел в Skill или допустимая свобода?
• Если завтра другой агент соберёт этот же экран по тому же Skill — результат будет такой же или сильно разойдётся?
• Какое решение тут принял агент за вас? Вы согласны, что это его зона, а не ваша?
• Что в этом макете вы будете руками править перед сдачей? Почему этого не делает Skill?

Последний вопрос — самый полезный. Любая ручная правка после агента — это либо баг в Skill, либо сознательное исключение. Третьего варианта нет, и оба требуют действия: либо дописать правило, либо зафиксировать, что тут всегда вручную.

## Когда Skill пора переписывать с нуля

Иногда косметической чистки мало. Признаки, что файл прожил своё:

• Правки в Skill стали чаще, чем правки в самих макетах.
• На каждый новый продукт приходится добавлять блок «исключений».
• Команда обходит Skill в обход — «я знаю, там написано, но давайте по-другому».
• Никто не помнит, зачем добавлено половина правил.

В этот момент дешевле сесть на день и собрать новый Skill из практики последнего квартала, чем латать старый.

## Короткий итог

Skill — это договор команды с самой собой, записанный так, чтобы его мог исполнить агент. Он работает, пока остаётся коротким, проверяемым и живым: правила добавляются по реальным болям, удаляются по неиспользованию, ревьюятся как код. Всё остальное — украшения, которые красиво смотрятся в первый месяц и мешают на третий.