← Назад в журнал

31 навык, 72 системы: как устроена библиотека Open Design

Прогулка по четырём примитивам, которые делают Open Design компонуемым: навыки, системы, адаптеры и daemon. С конкретными примерами того, как файл Markdown превращается в идеальный до пикселя результат.

31 навык, 72 системы: как устроена библиотека Open Design

Open Design с механической точки зрения — это четыре примитива, выстроенных друг на друге:

  1. Навыки (Skills) — что должен делать агент
  2. Системы (Systems) — как должен выглядеть результат
  3. Адаптеры (Adapters) — какой агент выполняет работу
  4. Daemon — цикл, который связывает их воедино

Каждый примитив — это папка с файлами. Ни один из них не требует базы данных, среды выполнения плагинов или размещённого сервиса. Это вся библиотека целиком — за стеной входа не прячется никакой пятый концепт. Этот пост по очереди проходит по каждому из них и показывает, что происходит, когда вы направляете своего агента на реальный бриф. Если вам сначала нужны аргументы, почему мы придали этому именно такую форму, а уже потом — как, начните с почему мы построили Open Design как слой навыков, а не как продукт.

Навыки: единица возможности

Навык — это папка, содержащая один файл SKILL.md и ноль или больше вспомогательных файлов. Файл Markdown — это контракт агента; всё остальное в папке существует, чтобы помочь агенту его выполнить.

Анатомия папки навыка

Типичный навык выглядит так:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md объявляет имя навыка, условия срабатывания, форму входных данных, форму выходных данных и любые встроенные указания для агента. Папки templates/ и examples/ необязательны, но тянут на себе многое: примеры — это заведомо хорошие артефакты, по образцу которых агент может работать, и именно в этом разница между тем, что «сделай мне презентацию» выдаёт что-то связное, а не что-то импровизированное.

Front matter — это та часть, которую читает daemon, чтобы зарегистрировать навык; тело — та часть, которую читает агент, чтобы его выполнить:

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

Почему файл и есть реестр

Когда daemon запускается, он сканирует skills/ и регистрирует каждую папку, содержащую SKILL.md. Нет манифеста плагина. Нет поля версии. Нет шага загрузки, нет очереди на проверку, нет сборки. Есть файл, и файл — это источник истины. Положите внутрь новую папку, перезапустите daemon — и навык появляется в селекторе. Удалите её — и его нет; никаких осиротевших записей реестра, указывающих на код, которого больше не существует.

Сейчас мы поставляем 31 навык. Одни — генераторы презентаций, другие создают мобильные макеты, третьи строят редакционные страницы, четвёртые пишут офисные документы (Word, Excel, PowerPoint). Каждый — это папка, которую можно форкнуть, отредактировать или заменить. Поскольку контракт — это простой текст, «написать навык» и «прочитать навык, чтобы понять, что он делает» — это одно и то же действие: вы проверяете его, просто открыв.

Одна карточка навыка в виде простого текста с подписанным заголовком и несколькими строками, выделенная зелёной рамкой на почти белом редакционном фоне
Навык — это атомарная единица возможности: один простой файл, который агент может взять, прочитать и выполнить.

Системы: единица вкуса

Если навык описывает, что делать, то система описывает, как это должно выглядеть. Система — это файл DESIGN.md плюс необязательные референсные ресурсы. Она описывает визуальную идентичность в машиночитаемой форме:

  • Цвет — значения OKLch для текста, фона, акцента, ошибки и так далее
  • Типографика — стек шрифтов, начертания, типографическая шкала, соглашения о высоте строк
  • Пространство — базовая единица, шкала отступов, ширины контейнеров, правила интервалов
  • Позиция вёрстки — выбор сетки, правила асимметрии, предпочтения по плотности
  • Голос — типографика слов: тон, лексика, ритм предложений

DESIGN.md — это контракт, а не библиотека компонентов

На практике DESIGN.md читается как короткий, выраженный по позиции бренд-бриф, который агент не сможет истолковать неправильно:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

Цвета заданы в OKLch, поэтому они остаются перцептивно ровными на светлых и тёмных поверхностях; типографическая шкала — это лестница, с которой агент не сойдёт; правила позиции — это разница между десятью сгенерированными экранами, которые ощущаются как один продукт, и десятью, которые ощущаются как десять разных стажёров. Агент читает это один раз и уважает на протяжении всей работы.

Система — это не библиотека Figma. Нет компонентов, нет вариантов, нет вложенных экземпляров, нет двоичного формата, стоящего между вами и правилами. Это контракт, который может прочитать любой агент и проверить любой человек. Из коробки мы поставляем 72 системы, включая портативные версии Linear, Vercel, Stripe, Apple, Cursor, Figma и длинный хвост редакционных и брендовых систем.

Смешивайте, форкайте, владейте

Поскольку система — это просто текст, вы можете форкнуть её и отредактировать на месте, выпустить вариант или написать собственную с нуля примерно за 30 минут сосредоточенной работы. Вы даже можете смешивать системы посреди проекта — типографику из Linear, логику цвета из Vercel, вёрстку из внутренней спецификации, — потому что ничто не заперто в проприетарном двоичном формате. Разделение между папками skills/ и design-systems/ сделано намеренно: возможность и вкус ортогональны, поэтому любой навык может работать под любой системой, и любая система может управлять любым навыком.

Адаптеры: единица агента

Навыки и системы — это инертный текст. Адаптеры — это небольшое количество кода, который связывает их с агентом, фактически выполняющим работу. Адаптер — это короткий файл TypeScript в adapters/, который умеет:

  • определять, установлен ли агент в $PATH пользователя
  • запускать сессию с этим агентом
  • передавать вызов навыка внутрь
  • собирать результат обратно

Сегодня мы поставляем адаптеры для 12 агентов: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. Daemon автоматически определяет, какие из них присутствуют, и предлагает их в виде выпадающего списка при первом запуске — вы ничего не настраиваете, вы просто видите агентов, которые у вас уже есть.

ПримитивРасположен вФайлИсточник истины
Навыкskills/SKILL.mdфайл на диске
Системаdesign-systems/DESIGN.mdфайл на диске
Адаптерadapters/один файл .tsвызов register()

Если вы хотите добавить новый адаптер, файл — это примерно 80 строк TypeScript и единственный вызов register(). Никакого SDK для изучения, никаких разрешений для запроса, никакого центрального реестра для публикации. Тот самый агент, которому вы уже доверяете на своём ноутбуке, становится движком — Open Design никогда его не заменяет. (Сопутствующий материал рабочий процесс дизайна BYOK разбирает, как направить адаптер на ваш собственный ключ.)

Daemon: цикл, который связывает всё воедино

Daemon — единственный работающий процесс в системе. Это небольшой процесс Node, который вы запускаете командой pnpm tools-dev, и он делает четыре вещи последовательно:

  1. Detect (Обнаружение) — сканирует $PATH на наличие установленных агентов и skills/ на наличие установленных навыков при запуске
  2. Discover (Выяснение) — открывает интерактивную форму с вопросами, чтобы уточнить поверхность, аудиторию, тон, масштаб и брендовый контекст текущего брифа
  3. Direct (Направление) — представляет 5 детерминированных визуальных направлений (палитра в OKLch, стек шрифтов, подсказки по позиции вёрстки) и просит пользователя выбрать одно
  4. Deliver (Доставка) — вызывает выбранный навык с зафиксированной системой, позволяет агенту записать на диск и показывает предпросмотр результата в изолированном iframe

Весь цикл умещается примерно в 1500 строк кода. Он намеренно мал. Хитрость — в навыках, а не в среде выполнения: задача daemon — сканировать папки, провести бриф через четыре шага и не мешать. Эта малость и есть суть: здесь очень мало того, что может прогнить, и почти ничего, что могло бы взять вашу работу в заложники.

Каково это на практике

Предположим, вам нужна презентация о запуске новой функции продукта. Вот ход работы:

  1. Вы запускаете pnpm tools-dev в терминале. Daemon стартует на localhost:7780.
  2. Вы открываете URL. Daemon показывает, каких агентов он нашёл (например, Claude, Cursor, Codex).
  3. Вы выбираете guizang-ppt из списка навыков.
  4. Всплывает 30-секундная форма с вопросами: кто аудитория, какой тон, какой брендовый контекст.
  5. Вам показывают 5 визуальных направлений — разные палитры, шрифтовые пары, позиции вёрстки. Вы выбираете одно.
  6. Агент записывает на диск. Изолированный iframe показывает результат. Вы можете экспортировать в HTML, PDF, PPTX, ZIP или Markdown.

Проследите это обратно через примитивы — и всё целиком становится прозрачным: шаг 3 выбрал навык, шаг 5 зафиксировал систему, агент за ним пришёл через адаптер, а daemon прогнал четырёхшаговый цикл. Результат настоящий. Файлы — ваши. Вы можете отредактировать их в любом редакторе, передать дизайнеру или скормить обратно другому навыку.

Почему файлы, а не база данных

Каждый примитив — навыки, системы, адаптеры — это папка с текстовыми файлами. Нет центральной базы данных. Нет «аккаунта Open Design». Нет размещённого сервиса, который должен продолжать работать, чтобы продолжала работать ваша работа.

Это намеренный компромисс. Мы отказываемся от возможности делать хитрую кросс-пользовательскую аналитику, кросс-проектную память или размещённую совместную работу. Взамен мы получаем: портативность, долговечность, проверяемость и возможность для любого форкнуть всю библиотеку и выпустить собственный вариант. SKILL.md, написанный сегодня, читается одинаково для агента через два года и для человека вообще без какого-либо инструментария — чего не скажешь о плагине, привязанном к прошлогоднему API.

Если вы наблюдали, как целое поколение инструментов для дизайна умирало, унося ваши файлы с собой, вы поймёте, почему этот компромисс того стоит.

Связанные материалы


← Назад в журнал GitHub · Источник ↗