Как перенести рабочий процесс Figma в плагин Open Design

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

Обсуждение 0.8.0-preview ставит вопрос острее: перенесите эту мышечную память в плагин. Не панель, прикрученную к холсту. Не приватный скрипт, который может запустить только одна команда. Многоразовый рабочий процесс Open Design, который агент может подхватить, выполнить, проверить и передать дальше через тот же local-first цикл, что и любую другую задачу дизайна.

Это практическая версия призыва 0.8.0-preview создавать плагины. Если у вашей команды сегодня есть хотя бы один повторяемый рабочий процесс дизайна, этот пост показывает, как выглядит превращение его во вклад в форме плагина — какие файлы для этого нужны, как агент его подхватывает и где он оказывается после публикации.

Рабочий процесс, который стоит переносить, меньше, чем вы думаете

Не начинайте с «заменить Figma». Начните с одной надоедливой повторяемой задачи.

Хорошие кандидаты для первого плагина:

Текущий рабочий процесс	Версия в форме плагина
Экспортировать маркетинговую страницу из Figma и пересобрать её в коде	Плагин `figma-migration`, который извлекает макет, сопоставляет токены и генерирует веб-артефакт
Каждый месяц превращать брендбук в слайды для запуска	Плагин для презентаций с `SKILL.md`, примерами ассетов и зафиксированной дизайн-системой
Создавать один и тот же макет онбординга мобильного приложения для каждого клиента	Плагин для мобильных экранов с полями ввода для аудитории, тональности, списка функций и платформы
Преобразовывать спецификацию компонента в готовый для Storybook интерфейс	Плагин миграции кода, который читает репозиторий, сопоставляет компоненты и пишет проверяемый diff

Единица — это не весь отдел дизайна. Единица — это один рабочий процесс, который кто-то уже повторяет дважды в неделю. Если вы не можете описать его одним предложением — «превратить X в Y с такими-то ограничениями» — то это, вероятно, два плагина, а не один, и вам стоит разделить его прежде, чем вы напишете хоть строчку Markdown.

Вот почему слой навыков Open Design здесь так важен. Плагин — это не непрозрачное расширение среды выполнения. Это папка с файлами: контракт SKILL.md, опциональные дизайн-системы, опциональные примеры и сопроводительный файл open-design.json, который сообщает Open Design, как отображать и применять рабочий процесс. Между вами и правилами нет бинарного формата, а значит, любой может прочитать плагин, форкнуть его или исправить позже.

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

Угол зрения Open Design — это переносимость

Спецификация плагина излагает контракт прямо: SKILL.md остаётся исполняемым контрактом агента, а open-design.json добавляет метаданные для маркетплейса, поля ввода, значения по умолчанию, превью и подключение контекста.

Это даёт одному рабочему процессу две жизни. В Open Design он появляется как плагин с превью, входными данными, происхождением и путём «использовать» в один клик. В Claude Code, Cursor, Codex, Gemini CLI, OpenClaw или другом каталоге навыков та же папка по-прежнему работает как обычный навык агента, потому что основное поведение живёт в Markdown. Вы пишете не для среды выполнения, которая устареет в следующем году; вы пишете файл, который агент прочитает точно так же и через два года.

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

Для рабочего процесса «из Figma в код» поверхности обычно выглядят так:

Поверхность	Конкретный файл
Поведение агента	`SKILL.md`
Метаданные Open Design	`open-design.json`
Контракт бренда или визуала	`design-systems/{brand}/DESIGN.md`
Пример вывода	`example.html` или `examples/{plugin-id}/example.html` внутри папки плагина
Медиа для превью	`preview/poster.png` или `preview/index.html` внутри папки плагина

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

Конкретный путь переноса

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

1. Назовите повторяемую задачу

Запишите одно предложение, описывающее задачу: «Превратить один маркетинговый фрейм Figma в адаптивную страницу Astro в фирменной дизайн-системе, готовую к проверке». Если вы не можете уложиться в одно предложение, сужайте, пока не сможете. Название становится id вашего плагина (figma-workflow) и заголовком, который отображается в маркетплейсе.

2. Напишите контракт навыка

SKILL.md — это исполняемый контракт, который читает агент. Front matter задаёт имя навыка и его триггер; тело — это бриф: форма входных данных, путь вывода, ограничения и чек-лист проверки, который агент должен применить к себе перед передачей результата.

---
name: figma-workflow
description: Turn one Figma marketing frame into a responsive Astro page in the house brand system.
trigger: When the user provides a Figma frame URL, screenshot, or exported assets for a marketing page.
---

## Input
- A Figma frame URL, a screenshot, or a folder of exported assets.
- The target brand system (defaults to `house`).

## Output
- An Astro page at `src/pages/<slug>.astro`, plus extracted tokens.

## Constraints
- Map Figma styles to the brand system's tokens. Do not invent colors or type.
- Preserve section order and copy. Flag any text that does not fit the grid.
- Mobile-first: every section must reflow at 360px before desktop.

## Review checklist
- [ ] Section IDs match the source frame.
- [ ] No raw hex values — tokens only.
- [ ] Responsive behavior verified at 360 / 768 / 1280.

3. Добавьте сопроводительный файл Open Design

open-design.json — это то, что превращает голый навык в плагин для маркетплейса: заголовок, описание, объявленные входные данные, превью и исходный репозиторий. Это метаданные, которые управляют панелью «использовать» и строкой происхождения.

{
  "id": "figma-workflow",
  "title": "Figma workflow",
  "description": "Port one Figma marketing frame into a responsive Astro page.",
  "inputs": [
    { "key": "figmaSource", "label": "Figma URL or screenshot", "type": "string", "required": true },
    { "key": "brand", "label": "Brand system", "type": "string", "default": "house" }
  ],
  "preview": "preview/poster.png",
  "source": "https://github.com/your-org/your-plugins"
}

4. Подключите дизайн-систему

Если рабочий процесс зависит от правил бренда, добавьте файл DESIGN.md в design-systems/, вместо того чтобы закапывать цвет и типографику в прозу. Агент воспринимает систему как контракт — палитра OKLch, типографическая шкала, постура макета — поэтому десять сгенерированных экранов по-прежнему ощущаются как один продукт. Смешивать системы по ходу проекта тоже можно, потому что это просто текст.

5. Включите один реальный пример

Сохраните сгенерированный артефакт в examples/, чтобы проверяющие могли судить о результате, а не только об обещании. Один заведомо хороший example.html стоит больше, чем абзац описания; он даёт агенту что-то, на что можно ориентироваться, и даёт мейнтейнеру что-то, что можно одобрить.

Собранный воедино, плагин — это одна читаемая папка:

plugins/community/figma-workflow/
  SKILL.md              # the agent contract: trigger, output, constraints, review
  open-design.json      # marketplace metadata: title, inputs, preview, source
  design-systems/
    house/
      DESIGN.md         # the brand contract the agent must respect
  examples/
    figma-workflow/
      example.html      # one known-good artifact reviewers can judge
  preview/
    poster.png          # marketplace preview media

6. Проверьте и упакуйте

Запустите команды плагина перед тем, как открывать PR. Текущий путь CLI использует id плагина в нижнем регистре. Избегайте имён реестра с разделителями-слешами на этапе scaffolding; od plugin scaffold создаёт <out>/<id>/..., поэтому последующие команды указывают на эту сгенерированную папку:

od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
od plugin validate ./plugins/community/figma-workflow --no-daemon
od plugin pack ./plugins/community/figma-workflow

Когда плагин готов к проверке в реестре, аутентифицируйтесь через GitHub с помощью od plugin login и od plugin whoami --json, затем следуйте документации по публикации для текущего пути проверки. Open Design не хранит ваши учётные данные GitHub.

Как это выглядит в реальной команде дизайна

Представьте небольшую продуктовую команду с фреймом Figma для страницы запуска, фирменной дизайн-системой и ежемесячным ритмом релизов.

До плагина рабочий процесс — это цепочка передач: дизайнер экспортирует фреймы, инженер пересобирает макет, продакт-менеджер переписывает тексты, кто-то проверяет дрейф токенов, кто-то другой заводит баги. Работа знакомая, но память живёт в людях — и она утекает каждый раз, когда кто-то отсутствует, переходит в другую команду или забывает то единственное ограничение, которое было важным.

После плагина рабочий процесс становится исполняемым артефактом:

Шаг	Кто им управляет
Выбрать плагин	Дизайнер или продакт-менеджер
Прикрепить URL Figma / скриншот / локальные ассеты	Дизайнер
Выбрать дизайн-систему	Дизайнер или дизайн-инженер
Сгенерировать веб-артефакт	Claude Code, Cursor, Codex, Gemini CLI или другой обнаруженный агент
Проверить ID секций, тексты, плотность и адаптивное поведение	Человек в превью Open Design
Экспортировать или передать файлы	Та же локальная папка проекта

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

Что делать дальше

Если у вашей команды есть экспорт из Figma, синхронизация токенов, брендбук или шаблон презентации, которые продолжают возвращаться, перенесите сначала наименьший повторяемый кусок. Начните с SKILL.md, добавьте open-design.json, подключите фирменный DESIGN.md, вложите один реальный пример, проверьте его и откройте PR прежде, чем рабочий процесс разрастётся в приватный инструмент, который больше никто не сможет переиспользовать. Пример «из скриншота в прототип» показывает версию в форме плагина от начала до конца: переносимый навык плюс сопроводительный файл Open Design.

Попробуйте этот рабочий процесс.

Связанное чтение

31 навык, 72 системы: как работает библиотека Open Design — примитивы, которые оборачивает плагин
Почему мы построили Open Design как слой навыков, а не как продукт — почему рабочий процесс имеет форму файла, а не аккаунта
Альтернатива Figma с открытым исходным кодом — где оказывается перенос вашего рабочего процесса относительно действующего лидера
Рабочий процесс дизайна BYOK: запускайте Claude, Codex или Qwen на собственном ключе — как тот же плагин может работать на том пути к модели, которому ваша команда уже доверяет