Автоматизація дизайн-системи: перенесення ShadCN у Figma через Claude Code

Що всередині

•Як підготувати промпт для Claude Code, щоб автоматично перенести ShadCN-тему у Figma

•Що робить агент всередині: розгортання пресету, конвертація кольорів, генерація змінних

•Перевірка результату: колекції змінних, семантичні токени, радіуси, типографія

•Перенесення окремих компонентів ShadCN у Figma з варіантами та стейтами

•Чому варто планувати дії до запуску агента — і як це скорочує дебагінг

•Як зберігати flow у вигляді скілів для повторного використання в нових проєктах

•Self-sustained інструкція: як Claude сам оновлює свої скіли на основі нового досвіду

Для кого цей матеріал

•Вебдизайнерів і UX-дизайнерів, які хочуть автоматизувати побудову дизайн-системи у Figma

•Фронтенд-розробників, які шукають спосіб синхронізувати кодову базу ShadCN з Figma-файлом

•Продуктових команд, які будують UI-бібліотеку одночасно в коді і дизайні

•Усіх, хто вже використовує Claude Code і хоче розширити його застосування на дизайн-задачі

Ідея та вихідна точка

Завдання — перенести ShadCN-тему з кастомного пресету, створеного через конструктор на сайті ShadCN, у Figma: з кольорами, шрифтами, радіусами і семантичними токенами. Вручну це займало б значний час і вимагало б розгортання нового проєкту локально.

Підхід полягає в тому, щоб передати Claude Code посилання на пресет і попросити зробити все автоматично. Ключова перевага: пресет, згенерований на сайті ShadCN через розділ Create, містить динамічне URL-посилання, в яке вбудований весь набір налаштувань теми. Це дає змогу передати Claude одне посилання замість того, щоб вручну описувати всі параметри.

Перед запуском основного завдання зроблено попередній крок: Claude Code отримав посилання і спочатку проаналізував, що саме повертає ця URL-адреса всередині. На основі цього аналізу він сам згенерував детальний промпт — інструкцію для подальшої роботи. Такий підхід «спочатку дати Claude вивчити контекст, потім просити його написати промпт» значно підвищує якість фінального результату.

Принцип: Перед тим як ставити завдання агенту, варто дати йому вивчити контекст і попросити самого написати промпт. Це дає більш точний результат, ніж одразу формулювати завдання вручну.

Що робив Claude Code: покроковий процес

Після запуску в автономному режимі агент виконав усе завдання приблизно за 12–13 хвилин без жодного ручного втручання. Ось що відбувалось під капотом.

Крок 1. Розгортання пресету в тимчасовій папці

Claude створив приховану папку всередині проєкту і розгорнув у ній пресет — запустив команду встановлення тихо, у фоновому режимі. Це дало змогу отримати необхідні файли без повного розгортання нового Next.js або Vite-проєкту. Після завершення роботи тимчасова папка була видалена.

Три ключові файли, які потрібно було витягти з пресету: global CSS із темізацією і змінними, файл шрифтів, інформація про компоненти і їхні налаштування.

Крок 2. Конвертація кольорового простору

У ShadCN кольори описані в форматі OKLCH — сучасному кольоровому просторі, який дає перцептивно рівномірні переходи. Figma API цього формату не підтримує. Claude самостійно виявив цю несумісність ще на етапі аналізу пресету і заздалегідь написав скрипт для конвертації OKLCH у HEX.

Це показовий приклад того, як добре сформований контекст у промпті дає змогу агенту передбачати технічні проблеми і вирішувати їх до того, як вони виникнуть.

Крок 3. Генерація Variables у Figma

Claude використав Figma Console як міст між кодом і дизайн-файлом та створив три колекції Variables:

•Семантичні колірні токени — surface, sidebar, chart та інші значення з теми, конвертовані в HEX

•Радіуси — значення border-radius з пресету

•Типографія — шрифти і їхні параметри

Результат одразу містив і світлу, і темну тему з правильними назвами токенів. Перевірка підтвердила: колір card-foreground (#0a0a0a) у Variables Figma точно відповідає значенню з вихідного CSS-файлу.

Принцип: Якщо агент сам знайшов технічну проблему (несумісність кольорових просторів) і вирішив її в рамках одного промпту — це ознака якісно підготовленого контексту, а не випадок.

Перенесення компонентів ShadCN у Figma

Після того як тема і токени засетаплені, можна переносити окремі компоненти. Підхід ідентичний: дати Claude посилання на сторінку компонента в документації ShadCN і попросити відтворити його у Figma.

Щоб результат був якісним, рекомендується спочатку попросити агента вивчити документацію компонента і зрозуміти, як він встановлюється і що з'являється при встановленні — і тільки потім генерувати Figma-компонент. Можна також одразу попросити Claude написати промпт для цього кроку, замість того щоб формулювати його вручну.

Результат для компонента Button

Claude затягнув компонент у тимчасову папку, проаналізував стейти і варіанти, а потім відтворив їх у Figma. Результат:

•Усі варіанти кнопки з ShadCN перенесені як Figma-варіанти

•Токени прив'язані до Variables, створених на попередньому кроці

•Стейти hover, focus, disabled відтворені коректно

•Додано toggle для іконки ліворуч і праворуч з прив'язкою до компонента-іконки

Цікавий технічний момент: у ShadCN деякі стейти реалізовані через Tailwind-клас з альфа-каналом — наприклад, bg-primary/80 (80% непрозорості). У Figma такого CSS-синтаксису немає. Claude самостійно знайшов workaround: встановив прозорість на рівні компонента 80%. Рішення чисте і технічно коректне для контексту Figma.

Вибіркове перенесення стейтів

Не всі стейти з документації ShadCN варто переносити в Figma — це важлива практична деталь. Наприклад, для компонента Calendar є базовий стейт, range і date-picker. Їх логічно перенести як варіанти. Але такі речі, як відображення номерів тижнів, для більшості проєктів можна залишити на рівні ручного доопрацювання — без компонентизації.

Підхід: копіювати сторінку документації компонента, приносити її в Claude, пояснювати, які саме стейти потрібні — і агент відтворює тільки релевантне.

Принцип: Не варто переносити всі стейти компонента автоматично. Свідомий відбір того, що потрібно у Figma, — це частина дизайнерського рішення, а не технічна деталь.

Чому варто планувати дії до запуску агента

Один із ключових інсайтів цього підходу — цінність попереднього планування. Ідея проста: чим точніше описано план дій перед запуском Claude Code, тим менше помилок, менше дебагінгу і менше повторних запусків.

При цьому планування не є обов'язковим — модель добре розуміє контекст і часто справляється без детальних інструкцій. Але практика показує: якщо певний принцип описаний заздалегідь, переносити наступні сутності можна майже без помилок, не перевіряючи результат по двадцять разів.

Рекомендований підхід: спочатку попросити Claude вивчити документацію і Figma API, зрозуміти, що Figma взагалі дає змогу створювати через API, — і тільки потім формувати фінальний промпт. Це займає більше часу на підготовку, але суттєво скорочує час на виправлення.

Принцип: Результат агента — це відображення якості інструкції. Час, витрачений на підготовку промпту, повертається скороченням дебагінгу.

Скіли: збереження flow для повторного використання

Після завершення роботи над кожним компонентом або flow Claude отримує команду зберегти результат у вигляді скіла. Скіл — це збережена інструкція, яка описує порядок дій, best practices, знайдені в процесі, і посилання на допоміжні скрипти.

У цьому прикладі Claude створив два скіли:

•Preset to Figma Tokens — інструкція для перенесення ShadCN-теми (пресету) у Figma з кольорами, шрифтами і радіусами

•ShadCN Component to Figma — інструкція для перенесення окремого компонента з документації ShadCN у Figma з варіантами і стейтами

Кожен скіл містить: покроковий порядок дій, best practices, виявлені в процесі роботи, папку references із конвертаційним скриптом OKLCH → HEX і таблицю неймінгу токенів (як токен називається в ShadCN, як у Figma і які дефолтні скоупи потрібні).

Self-sustained інструкція: скіли, які оновлюються самі

Найцінніша властивість цього підходу — скіли живуть і розвиваються. Після роботи з кожним новим компонентом можна попросити Claude порівняти поточну інструкцію зі скіла з тим, що він дізнався в процесі нового завдання, і додати важливі нові деталі.

Приклад: під час роботи з компонентом Claude зіткнувся з питаннями щодо class variance authority — бібліотеки, яка керує варіантами в ShadCN. Він виніс це в окремий мікродок всередині скіла. Наступного разу він одразу знатиме, як із цим поводитись.

Після того як скіл збережений, наступне завдання формулюється максимально просто: назвати скіл і передати назву компонента. Наприклад: shadcn_component_to_figma, Calendar — і агент виконає все ідентично тому, як це було зроблено з кнопкою. Нічого пояснювати заново не потрібно.

Що містить скіл після збереження:

Принцип: Скіл — це інвестиція. Перший запуск займає час і потребує перевірки. Кожен наступний запуск того самого скіла — швидший і передбачуваніший.

Практичне застосування: від теми до повноцінної дизайн-системи

Описаний підхід масштабується на будь-яку UI-бібліотеку в коді — не тільки ShadCN. Якщо є вихідний код проєкту, навіть просто набір компонентів, які надали розробники, — це достатня база для побудови дизайн-системи у Figma через Claude Code.

Загальна послідовність дій для нового проєкту:

•Передати Claude посилання на пресет або джерело теми — агент аналізує, що там є, і пише промпт

•Запустити перенесення теми: кольори, типографія, радіуси → Variables у Figma

•Зберегти скіл «Preset to Figma Tokens»

•Переносити компоненти по одному, відбираючи потрібні стейти вручну

•Зберегти скіл «Component to Figma», оновлювати після кожного нового компонента

•Використовувати той самий flow для Storybook або інших проєктів без повторного налаштування

Цей же підхід добре спрацьовує у зворотному напрямку — з дизайну в код. Один раз пропрацьований flow перенесення можна перевикористовувати без кінця. Наприклад, так можна збирати Storybook для кількох проєктів: один раз написати скіл — і запускати його для кожного нового.

Принцип: Дизайн-система, побудована через Claude Code, — це не одноразове завдання, а процес, який з кожним компонентом стає швидшим і точнішим. Чим більше скілів накопичено, тим менше часу займає кожен наступний крок.