Бібліотеку компонентів з Claude Code збирають у п'ять кроків: токени з Figma Variables у tokens.json, React-компоненти на цих токенах, сторі на кожен стан у Storybook, збірка в npm-пакет і публікація з версією. Дизайнер ставить задачі й приймає результат у Storybook, Claude Code пише код. На виході продукт ставить @company/ui однією командою, і кнопка в продакшні та в макеті - це одна й та сама кнопка.
Нижче - структура репозиторію, промпти на кожен крок, що збирати, а що ні, і як не зламати продукти при оновленні. Так я, Dmytro Nikolaienko, доводжу системи до коду на проєктах UX Hero, і цей пайплайн ми проходимо на курсі «Дизайн-система з AI».
Що таке бібліотека компонентів у коді і чим вона відрізняється від UI-kit?
Бібліотека компонентів - це пакет з готовими компонентами інтерфейсу, який продукти підключають як залежність, а не копіюють. UI-kit у Figma показує, як кнопка виглядає. Бібліотека в коді і є кнопкою: з пропсами, станами, фокусом, доступністю і версією.
| UI-kit у Figma | Папка компонентів у проєкті | npm-пакет | |
|---|---|---|---|
| Працює в продакшні | ні | так, в одному проєкті | так, у всіх проєктах |
| Версія і changelog | ні | ні | так (semver) |
| Оновлення в продуктах | - | копіювати руками | одна команда |
| Ризик розбіжностей | високий | високий після 2-3 копій | низький |
Детальніше про різницю між системою і набором макетів - у статті Дизайн-система vs UI-kit.
Що треба мати у Figma, перш ніж відкривати Claude Code?
Claude Code не виправить хаос у файлі, він його точно відтворить у коді. Мінімум перед стартом:
- Змінні в три шари: primitives → semantic → component, без хардкод-кольорів. Якщо HEX ще розкидані по макетах, спершу переведіть їх у Variables.
- Компоненти з варіантами і станами: default, hover, focus, disabled, loading, error. Назви варіантів у Figma стануть назвами пропсів у коді.
- Специфікація на кожен компонент: анатомія, пропси, поведінка. Шаблон - у матеріалі Специфікація компонента.
- Список першої хвилі: 5-8 компонентів, які є в кожному екрані. Зазвичай це Button, Input, Checkbox, Select, Badge, Card, Modal.
Як має виглядати репозиторій бібліотеки?
Одна проста структура, яку Claude Code легко тримати в голові:
ui/
tokens/tokens.json ← експорт з Figma Variables (W3C DTCG)
src/styles/tokens.css ← CSS-змінні, генеруються з tokens.json
src/components/Button/
Button.tsx ← компонент
Button.stories.tsx ← сторі на кожен стан
Button.mdx ← документація
src/index.ts ← що експортує пакет
AGENTS.md ← правила для Claude Code
package.json
Файл AGENTS.md - найважливіший для дизайнера. У ньому правила, які агент читає перед кожною задачею: «кольори тільки через CSS-змінні з tokens.css», «кожен стан має сторі», «не додавай залежностей без питання». Як його писати - у статті AGENTS.md для дизайн-системи.
Як зібрати бібліотеку з Claude Code: покроково
- Токени. Експортуйте змінні з Figma в
tokens.jsonі попросіть Claude Code згенерувати з ньогоtokens.cssзі світлою і темною темою. Для кількох платформ підійде Style Dictionary. - Каркас пакета. React + TypeScript, Storybook, збірка через Vite у library mode або tsup. Промпт: «Створи каркас бібліотеки компонентів за структурою з AGENTS.md. React і react-dom - peerDependencies, не бандлити. Збірка в ESM з типами .d.ts».
- Перший компонент. Дайте Claude Code специфікацію і посилання на фрейм у Figma (через MCP або скриншот):
Зроби компонент Button за специфікацією docs/specs/button.md.
Варіанти: primary, secondary, ghost, danger. Розміри: sm, md, lg.
Стани: hover, focus-visible, disabled, loading.
Кольори, відступи і радіуси - ТІЛЬКИ з src/styles/tokens.css, жодних HEX і px-констант.
Додай Button.stories.tsx зі сторі на кожен варіант і стан.
Не змінюй інших файлів. Наприкінці покажи список того, що не зміг зробити за спекою.
- Приймання у Storybook. Відкрийте Storybook поруч з Figma і пройдіться по кожному стану. Дизайнер тут - не глядач, а QA: розбіжність у 2 px або неправильний focus ring повертається задачею. Як читати Storybook - у матеріалі Storybook для дизайнерів.
- Решта першої хвилі тим самим промптом. Коли Button прийнятий, збережіть промпт як Claude Skill і проганяйте через нього Input, Checkbox, Select. Шаблон виправляйте, а не окремий компонент.
- Пакет і публікація. Назва в scope (
@company/ui), полеexportsу package.json, версія0.1.0. Публікацію краще одразу віддати GitHub Actions: реліз запускається з merge в main, а не з ноутбука дизайнера.
Орієнтовно, з готовою системою у Figma: каркас і токени - 1 вечір, кожен базовий компонент зі сторі - 30-60 хвилин з урахуванням приймання, перша хвиля з 6-8 компонентів - 1-2 тижні в спокійному темпі.
Куди публікувати пакет: npm чи приватний registry?
| Варіант | Коли брати | Що врахувати |
|---|---|---|
| Публічний npm | open source, портфоліо, особистий кит | scope-пакет публікується з --access public; варто налаштувати trusted publishing з GitHub Actions замість токена |
| Приватний scope в npm | компанія вже платить за npm | доступ по команді, той самий процес |
| GitHub Packages | код компанії вже на GitHub | доступ через права на репозиторій, у продуктах треба .npmrc з registry |
| Монорепо без публікації | один продукт, одна команда | пакет підключається через workspaces, версіонування простіше, але лише всередині репо |
Рекомендація: для внутрішньої системи - GitHub Packages, для портфоліо Design Engineer - публічний npm. Публічний пакет з живим Storybook - один з найсильніших артефактів, про це в статті Портфоліо Design Engineer.
Як оновлювати бібліотеку і не ламати продукти?
- Semver. Patch - виправили баг, minor - додали варіант, major - перейменували або прибрали проп. Подробиці і Changesets - у статті Версіонування дизайн-системи.
- Візуальні тести. Скриншот кожної сторі порівнюється з попереднім релізом, тож випадково змінений відступ видно до merge.
- Claude Code як рев'юер. Попросіть перевірити PR: «чи є тут breaking change для пропсів і чи всі кольори з токенів».
- Deprecation замість видалення. Старий проп живе ще один minor з попередженням у консолі, потім іде в major.
Як я збираю такий пакет наживо, від Figma до першого релізу, показую на YouTube-каналі UX Hero.
Чому це має робити дизайнер, а не тільки розробник?
Бо в бібліотеці компонентів найчастіше ламається саме дизайн: стани, які «забули», focus ring, який «не встигли», темна тема, яка «потім». Коли дизайнер сам доводить компонент до пакета, розрив між макетом і продакшном зникає на рівні джерела, а не правиться в кожному продукті.
У цьому й різниця, на якій стоїть UX Hero. Згенерувати красивий макет вміє будь-яка нейромережа. Довести систему до коду, який команда ставить однією командою і якому можна довіряти, вміє дизайнер, що працює з кодом.
Часті питання
Чи може дизайнер без досвіду в коді зібрати бібліотеку компонентів з Claude Code?
Так, якщо в нього вже є впорядкована система у Figma: змінні, компоненти з варіантами і станами. Claude Code пише код, а дизайнер ставить задачу, перевіряє результат у Storybook і приймає рішення. Перший компонент займає вечір, далі темп росте, бо шаблон уже є.
Навіщо пакувати компоненти в npm-пакет, якщо можна скопіювати папку?
Копія папки починає жити своїм життям у кожному проєкті, і через місяць у вас п'ять різних кнопок. Пакет має версію: продукт ставить @company/ui, оновлюється однією командою і бачить у changelog, що змінилось. Одне джерело правди замість копій.
Публічний npm чи приватний пакет?
Для внутрішньої системи компанії - приватний: GitHub Packages або приватний scope в npm. Публічний npm має сенс для open source бібліотеки або портфоліо Design Engineer. Код і процес однакові, різниться лише registry і доступ.
Чим бібліотека компонентів відрізняється від UI-kit у Figma?
UI-kit у Figma - це малюнок компонента, бібліотека в коді - сам компонент, який працює в продукті. Бібліотека має пропси, стани, доступність, тести і версію. Саме вона гарантує, що продакшн виглядає як макет.
Де навчитись збирати дизайн-систему до коду українською?
На курсі UX Hero «Дизайн-система з AI» від Dmytro Nikolaienko: аудит, Figma Variables, компоненти зі станами, документація і пайплайн до Storybook на живих файлах. Глибше в код, React і деплой веде курс «Design Engineer».
Почніть з однієї кнопки: токени в CSS, компонент зі сторі на кожен стан, версія 0.1.0. Коли перший компонент пройшов приймання у Storybook, решта бібліотеки - це повторення шаблону, а не нова магія.