Я зробив тулзу, яка поєднала Figma із Claude Code без Figma MCP

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт! Я Денис, дизайн інженер і продуктовий дизайнер вже більше 15 років. Багато часу зараз присвячую тому, щоби знаходити шляхи оптимізації дизайнерів інтерфейсів під нові АІ реалії. Будую пайплайни, тулзи, повноцінні продукти, які здатні робити дизайн в коді. І саме ця розповідь про одну мою тулзу.

Трохи контексту, щоби було зрозуміло навіщо все це. Мій основний робочий процес вже давно живе не у Figma, а в репозиторії: ресерч, вайрфрейми, токени, компоненти, документація, все це код, який веде Claude Code. Але команди, з якими я працюю, живуть у Figma. Дизайн-системи лежать у Figma, ревʼю проходять там же, хендофф часто теж через Figma. Тому мені потрібен був надійний міст: щоби агент міг не просто подивитись на макет, а системно читати і писати у файл. Читати структуру сотень компонентів, привʼязувати токени, малювати макети на компонентах бібліотеки. Саме на цій потребі і зʼявилась Figmosha 2.

Моя історія створення інструменту почалася банально: я робив аудит дизайн-системи через Claude Code і офіційний Figma MCP. Всі, хто стикався із таким, знають наскільки велика ця робота за обсягом і особливо часом. Тому використання Аішки мало б дуже сильно допомогти із цим. Але за пару годин роботи в Claude Code через Figma MCP закінчився місячний ліміт запитів на стороні Фігми. У мене Pro підписка Figma. Аудит був зроблений відсотків на десять.

Так я дізнався що офіційний міст між AI-агентом і Figma розрахований на разові запити типу дай мені специфікацію цієї кнопки, а не на системну роботу з файлом. А мені потрібна була саме системна: пройтись по всій бібліотеці, зчитати структуру кожного компонента, перевірити привʼязки токенів. Один компонент це один-два запити, але коли компонентів двісті і кожен треба спочатку прочитати, потім виправити, потім перечитати і перевірити, лічильник запитів тане на очах. Місячний ліміт зʼїдається за один робочий ранок, і далі сиди чекай наступного місяця, або плати Фігмі додатково.

Далі розкажу як я прийшов до власного рішення через дві невдалі ітерації, і чому в результаті воно вмістилось у 500 рядків Python.

Ітерація нуль: Я просто копіпастив код

Перший робочий пайплайн виглядав так. Мій Figma-плагін зчитує структуру компонента у YAML. Claude Code читає YAML, підбирає семантичні токени і генерує apply-скрипт. А далі я руками: відкриваю плагін Scripter у Figma, вставляю згенерований код, тисну Run.

Чому саме Plugin API, а не Figma REST API, спитаєте ви. Бо REST API для такої задачі майже безкорисний. Він чудово читає файл як JSON і експортує картинки, але писати у дизайн він практично не вміє: створити фрейм, привʼязати токен до заливки, поправити автолеяут, нічого з цього через REST не зробиш. А робота з Variables через REST взагалі доступна тільки на Enterprise плані. Тобто для реальної маніпуляції дизайном лишається один шлях: Plugin API зсередини самої Figma. Питання було тільки в тому, як дати агенту доступ до нього.

Я так мігрував бібліотеку з примітивів через стилі на семантичні веріабли, репо з цим пайплайном лежить на моєму GitHub. Але я все одно багато робив руками. Клод код генерує скрипт за секунди, а потім чекає поки я скопіюю, вставлю і запущу. На кожен компонент. На кожну ітерацію виправлень. Уфф, це так бісило!

Ітерація один: Playwright

Логічний наступний крок: прибрати себе з циклу. Перша версія робила це через Playwright: відкривала Figma в браузері, знаходила Scripter, вставляла код у редактор, натискала Run, чекала результат. Це було дуже повільно, хоча і не руками. Браузерна автоматизація наче робить все як людина: чекає рендер, шукає елементи в DOM, бореться з фокусом вікон. Одна операція займала десятки секунд і були часті глюки Коли агенту треба 2-3 цикли виправлень на складний макет, сесія розтягувалась на хвилини очікування там де роботи на секунди. Простіше вже було руками робити...

І це окремий урок, який я виніс з тієї ітерації. Браузерна автоматизація для агентних пайплайнів це майже завжди крайній засіб. Вона імітує людину там де людина взагалі не потрібна. Якщо у системи є програмний інтерфейс, треба йти в нього напряму, навіть якщо для цього доведеться написати трохи власної інфраструктури. Клік по кнопці через DOM це найкрихкіша ланка яку тільки можна вбудувати в автоматичний цикл.

Ітерація два: викинути браузер

І тут появилася проста думка. Scripter це просто плагін який виконує TypeScript через Figma Plugin API. Plugin API це найстабільніший і найпотужніший інтерфейс Figma, на ньому тримаються тисячі плагінів. Проблема тільки в тому що він замкнений всередині UI Figma. То чому б не зробити власний плагін який тримає відкритий WebSocket до локального сервера? Агент шле код по HTTP, сервер передає його плагіну, плагін виконує через Plugin API і повертає результат.

Так з’явилась Figmosha 2.0. Вся система: один Python файл сервера на 200 рядків, один CLI на 300 рядків, плагін на 250 рядків. Без npm і фреймворків. Плагін імпортується в dev-режимі маніфестом, публікувати нічого не треба. Я і Claude Code збудували це за пару днів.

Claude Code тепер пише скрипт і виконує його у Figma через curl або CLI. Читання ноди займає мілісекунди. Порівняно з Playwright-версією різниця у швидкості виконання операцій вийшла від 150 до 950 разів залежно від типу задачі. Плагін працює навіть коли Figma згорнута!

Окремо скажу про безпеку, бо виконання довільного коду звучить страшно. Вся система локальна: сервер слухає тільки localhost, код виконується у твоїй відкритій Figma на твоїй машині, назовні нічого не ходить. Немає ні токенів доступу, ні хмарних посередників, ні чужих серверів між агентом і файлом. Це той самий рівень довіри, що і запуск скрипта у Scripter руками, просто без рук.

Хелпери: досвід замість шаблонного коду

Голий Plugin API має ще ті свої граблі. Масив fills заморожений і його не можна мутувати напряму. Текст не запишеш поки не завантажив шрифт. Синхронний getVariableById задеприкейчений. Кожен хто писав скрипти для Figma через Scripter думаю стикався із цим всім.

Тому в рантайм плагіна вшиті 15 хелперів. h.setText сам завантажує шрифти перед записом тексту. h.bF правильно прив’язує Variable до fill через копію масиву. h.cloneNext клонує ноду і ставить поруч з відступом. Типовий скрипт з хелперами коротший на 60-70 відсотків.

Зробив я їх не тому, що просто захотів, а на основі помилок на реальних задачах. Я ганяв тулзу на робочих кейсах: малювання макетів на компонентах з бібліотеки, автолеяути, привʼязка токенів. Кожен повторюваний шматок коду і кожні граблі ставали хелпером. Тобто хелпери це не абстрактна бібліотека зручностей, а буквально конденсований досвід помилок. Якщо агент тричі спіткнувся об одні і ті самі граблі, ці граблі перетворюються на функцію, і наступна сесія їх вже не бачить.

Хінти: агент лікує себе сам

Друга важлива деталь: коли скрипт падає з відомою помилкою, відповідь містить поле hint з підказкою. Наприклад скрипт впав на незавантаженому шрифті, і у відповіді написано: використай h.setText, він сам завантажує шрифти.

Це зроблено не для мене, а для Claude Code. Агент читає хінт, переписує свій скрипт і запускає знову, без моєї участі. На практиці це виглядає так: я пишу створи компонент кнопки, агент малює його на компонентах бібліотеки з правильними стейтами і токенами, потім сам зчитує результат і перевіряє: чи не поламались констрейни, чи правильні налаштування автолеяутів. Якщо макет складний і з першого разу вийшло криво, агент проходить 2-3 цикли виправлень сам. І це вже робоча схема!

Взагалі звʼязка хелпери плюс хінти це маленький приклад загального принципу, який я застосовую у всіх своїх агентних пайплайнах: не намагайся написати ідеальну інструкцію наперед, а зроби так, щоб система сама повертала агенту знання в момент помилки. Інструкція на п’ять сторінок в контексті забувається, хінт у відповіді на впалий запит спрацьовує завжди, бо приходить рівно тоді, коли потрібен.

А як же готові рішення

Чесне питання яке я собі ставив: навіщо своє, якщо є figma-console-mcp з 1.7k зірок і 103 тулзами, плюс офіційний Figma MCP. Офіційний MCP відпав через ліміти, з цього все і почалось.

figma-console-mcp архітектурно дуже схожий на моє рішення: там теж плагін-міст через WebSocket і теж є виконання довільного коду. Але це продукт: Node.js, MCP-протокол, конфіги клієнтів, personal access token Figma, чотири режими підключення, 103 тулзи. Мій інструмент не потребує навіть токена, бо не ходить у Figma REST API взагалі: все виконується локально через Plugin API.

І от ці 103 тулзи мене найбільше бентежать. Кожна тулза це опис у контексті агента, тобто постійний податок на кожну сесію. Мій підхід протилежний: одна операція exec плюс 15 хелперів. Агент який вміє писати код не потребує сотні обгорток над API, йому потрібен прямий доступ і короткий шлях до виконання. Плюс 500 рядків коду можна продебажити і розширити за вечір. Новий хелпер додається в один файл і працює в наступному запиті.

Це до речі ширша розмова ніж один плагін. Індустрія зараз масово будує MCP-сервери за логікою чим більше тулзів тим краще, а по факту для сильної моделі кожна зайва тулза це шум. Код був і лишається найкомпактнішим інтерфейсом між агентом і системою. Дай агенту exec і документацію на одну сторінку, і він зробить більше, ніж зі стома обгортками. Це і є харнесс, до якого прагне не тільки дизайн інженер, а взагалі вся індустрія агентної розробки

Що не так

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

Що далі

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

Код відкритий під MIT, ставте, тестуйте і пишіть фідбеки: github.com/denysosadchyi/figmosha2