Дизайн-система в коде: из Figma, с нуля или готовая

Пока интерфейсы собирали люди, дизайн-система жила в Figma, а код её догонял. Агент читает код, а не макет. Поэтому команды, которые работают с агентами, переносят источник правды в репозиторий: токены лежат в JSON, компоненты в коде со всеми состояниями, правила в файле для агента. Люк Вроблевски, собравший такую систему для агентов, пишет, что систему начали с макетов, перевели в код через Figma MCP, и источником правды стал код: писать изменения обратно в Figma на практике не понадобилось.

Figma при этом никуда не уходит. Она остаётся входом, когда агент читает библиотеку через MCP, и выходом, когда макет генерируется из кода для обсуждения с командой. Хранилищем правил она быть перестаёт.

Шаг 1. Приведи библиотеку в порядок до того, как подключать агента. Figma даёт короткий список: всё, что повторяется, — компонент; имена говорят о назначении (color/surface/primary, а не blue-500); цвета, отступы, радиусы и шрифты заданы переменными; auto layout вместо координат; библиотека опубликована. Слой Frame 427 ничего не говорит агенту, и он придумает значение сам. Абсолютные координаты в макете превращаются в абсолютное позиционирование в коде.

Шаг 2. Вынеси токены в JSON. Формат — DTCG, спецификация W3C Design Tokens Community Group (не стандарт W3C), первая стабильная версия вышла 28 октября 2025 года. Способа два: родной экспорт переменных Figma в JSON, анонсированный в октябре 2025 года и развёрнутый к декабрю, или плагин Tokens Studio, у которого бесплатный тариф синхронизирует один файл с Git. По отчётам пользователей, родной экспорт пока не отдаёт составные токены вроде типографики и теней, их придётся дописать руками. Этот JSON — канонический файл системы: из него Terrazzo собирает CSS-переменные и блок @theme для Tailwind v4; Style Dictionary тоже читает DTCG, но формат 2025.10 поддерживает пока не полностью. Когда переменные в Figma меняются, меняется JSON, а не код.

Шаг 3. Подключи Figma MCP и напиши правила. Удалённый сервер доступен на всех тарифах, десктопный — на Dev и Full seat платных планов. У Figma есть промпт create_design_system_rules: агент читает кодовую базу и пишет файл правил в CLAUDE.md или AGENTS.md: где лежат токены, что нельзя хардкодить, как взять компонент из проекта вместо нового. Без этого файла агент получает из MCP код на React и Tailwind с hex-значениями и собирает новую кнопку на каждый экран.

Шаг 4. Компоненты по одному. Начни с трёх-пяти самых частых: кнопка, поле ввода, карточка. Для каждого агент получает структуру узла через get_design_context, переменные через get_variable_defs и скриншот, пишет компонент на токенах, а ты сверяешь с макетом. Пропусков в матрице вариантов быть не должно: агент считает, что состояний у компонента столько, сколько он увидел. Запрос на целый экран не работает: ответ больше 25 000 токенов не влезает в клиент, и вместо системы получается один большой файл.

До

Без файла правил: агент берёт код из MCP как есть, с hex и пикселями. На следующем экране появится ещё одна такая кнопка.

После

С файлом правил: та же кнопка собрана из компонента проекта, а значения пришли из токенов.

Шаг 5. Свяжи макет с кодом. Code Connect показывает агенту настоящее имя и импорт компонента, когда тот встречается в макете; это доступно на тарифах Organization и Enterprise. Если тариф не позволяет, замена — таблица «компонент в Figma → файл в репозитории» в файле правил. Проверка после каждого компонента: скриншот из get_screenshot рядом с рендером, потом Storybook с визуальной регрессией.

Начни не с Figma, а с аудита того, что уже есть в продукте или прототипе. Потом выбери базу: shadcn/ui, если проект на React и агент её уже знает; Base UI или React Aria, если нужны свои компоненты без чужих стилей. Доступность агенту с нуля писать не нужно, она достаётся от базы.

Токены первыми, и их мало. Тедди Ни из Magic Patterns советует начинать с 20–30 токенов, а не с 200: цвета, типографическая шкала из пяти-семи уровней, отступы, два-три радиуса, тени. Для цветов удобно сразу задать пары фон и текст: для поверхности, основного и второстепенного действия и для ошибки. Имена по назначению, а не по виду. Токены сразу записываются в JSON и в CSS, а Figma подключается позже, если нужна.

Один компонент сначала. Самый частый, обычно кнопка, со всеми вариантами и состояниями, в Storybook с историей на каждое состояние. По этому файлу агент учится писать остальные. Потом файл правил: короткий, всегда в контексте, в форме запретов — не выдумывать токены, не ставить hex, не создавать компонент, если похожий есть. Дианна Альтер формулирует это так: самая сильная инструкция агенту — сказать, чего не делать.

Проверка живёт там, где работает агент. Скрипт, который ищет в коде hex и пиксели вне токенов; Playwright MCP, чтобы агент смотрел на свой результат; тесты доступности. Если при нарушении правила ничего не падает, агент будет нарушать его уверенно и часто. Figma из кода делается в конце, если она нужна команде: инструмент use_figma собирает макет из компонентов и переменных.

Критерия выбора четыре: фреймворк проекта; есть ли официальные MCP и скиллы; нужен ли Figma-кит с переменными; лицензия. Есть системы, которые брать не нужно. Polaris React архивирован в сентябре 2026 года. PrimeVue с пятой версии и PrimeReact с одиннадцатой распространяются по лицензии PrimeUI, бесплатной только для небольших компаний с выручкой до миллиона долларов. Material Web без активной разработки с 2024 года.

shadcn/ui — не библиотека, а способ распространения кода: команда shadcn add копирует исходник компонента в проект, и дальше он твой. Автор снабдил её всем, что нужно агенту: MCP-сервер, официальный скилл, файл llms.txt, команда info --json с конфигурацией проекта, реестры, из которых компоненты других авторов ставятся той же командой. С июля 2026 года база доступности по умолчанию — Base UI, Radix остаётся по флагу.

Плюсы. Код принадлежит проекту, и агент правит его как свой. Агенты знают её без подсказок, потому что в обучающих данных она встречается чаще других. Доступность достаётся от базы. Токены уже семантические, пары background и foreground перекрашиваются под бренд, для этого есть редактор tweakcn. Всё бесплатно под MIT.

Минусы. Компоненты не обновляются сами, флаг --diff у команды add только показывает расхождения. Интерфейсы на нетронутых токенах выглядят одинаково: в исследовании 500 сайтов с Show HN 23,5% использовали компоненты без изменений. Официального Figma-кита нет. Самый полный кит, shadcndesign, платный и независимый от shadcn/ui, хотя автор библиотеки его публично одобрил; бесплатные киты в Figma Community есть, но за их полноту никто не отвечает. Только React и Tailwind. Кода в проекте больше, и отвечаешь за него ты.

Правило простое. shadcn/ui подходит, если проект на React и ты переопределишь токены под свой бренд до первого экрана. Если библиотека в Figma большая и команда ждёт официальный кит, смотри Chakra или MUI.

У дизайнера библиотека из 30 компонентов на тарифе Professional и пет-проект на React, пример условный. Аудит занял день: у 12 компонентов не было вариантов, 40 цветов стояли без переменных. После правок переменные получили имена по назначению, а библиотека была опубликована. Экспорт в JSON и сборка через Terrazzo дали tokens.css и блок @theme.

Дальше агент поставил shadcn/ui с пресетом, переписал переменные под tokens.css и получил в файле правил таблицу: 22 компонента из библиотеки соответствуют компонентам shadcn/ui, 8 — свои. Восемь своих агент перенёс по одному через get_design_context, с историями в Storybook. Code Connect на Professional недоступен, его заменила та же таблица. В конце скрипт проверки нашёл в коде ноль hex-значений вне tokens.css, и на этом система была готова к первому экрану.

Так выглядит начало этой таблицы в CLAUDE.md:

ИИ вредит, когда агент получает целый экран вместо компонента. Когда токены переносятся из макета как hex. Когда у компонента в коде один вариант, потому что в Storybook одна история. Когда файл правил написан один раз и не обновляется с ростом системы. Когда проверка делается глазами после, а не скриптом во время. И когда система выбирается за популярность, а не за совместимость с фреймворком проекта.

Прочитай узел [ссылка на компонент в Figma с node-id] через get_design_context и get_variable_defs. Напиши компонент [имя] в src/components/ui на токенах из src/styles/tokens.css. Hex-значений и пикселей вне токенов быть не должно. Сделай все варианты и состояния из макета, для каждого — история в Storybook. Покажи скриншот из get_screenshot рядом со своим рендером и перечисли расхождения

Пройди по опубликованной библиотеке [ссылка] и составь таблицу: компонент в Figma → файл в репозитории, который ему соответствует. Для компонентов без соответствия напиши "нет". Запиши таблицу в CLAUDE.md в раздел "Соответствие макета и кода"

Вот tokens.json в формате DTCG. Настрой Terrazzo так, чтобы из него собирались tokens.css с CSS-переменными и блок @theme для Tailwind v4. Семантические имена сохрани, составные токены типографики разложи на шрифт, размер и высоту строки. Добавь npm-скрипт tokens:build и проверку, что в src нет hex-значений вне tokens.css

Создай файл правил дизайн-системы в CLAUDE.md: где лежат токены и компоненты; что нельзя хардкодить; как проверить, есть ли похожий компонент, прежде чем создавать новый; что делать, если нужного токена нет — остановиться и спросить, а не придумывать. Правила в форме запретов, не длиннее 60 строк

Мы на shadcn/ui. Перепиши переменные в globals.css под эту палитру: [цвета бренда]. Пары background и foreground сохрани, контраст текста на фоне проверь по WCAG AA, значения запиши в OKLCH. Потом собери страницу с кнопкой, полем ввода и карточкой во всех вариантах, чтобы я посмотрел результат

У меня проект на [фреймворк], команда из [число] человек, тариф Figma [тариф], библиотека на [число] компонентов. Сравни shadcn/ui, Chakra UI и Mantine по пяти критериям: фреймворк, официальные MCP и скиллы, Figma-кит с переменными, лицензия, обновления. Дай рекомендацию и раздели, что в ней следует из моих ограничений, а что — из общих свойств систем