Дизайн-система для Claude Code

Самый слабый способ передать макет в Claude Code - приложить скриншот и попросить сделать так же. Скриншот показывает один результат в один момент. Он не раскрывает существующие компоненты, имена токенов, адаптивные правила, контентные состояния и проверки готовности.

У референса Private by Design в Refframe ясная композиция: доминирующий антиквенный заголовок, небольшие красные контурные блоки, иконка и контролируемое чёрное поле. Для реализации внутри продукта Claude Code должен знать, подключён ли нужный шрифт, какой красный токен обеспечивает требуемый контраст, как блоки перестраиваются на мобильном и какой компонент отвечает за их форму.

Начните с карты репозитория

До реализации дайте Claude Code минимальную карту, которая предотвращает лишний поиск и дублирование:

• фреймворк и пакетный менеджер;
• каталоги приложения и общей UI-библиотеки;
• файлы токенов и темы;
• публичные exports компонентов;
• правила иконок, изображений и шрифтов;
• маршрут и файл страницы;
• команды lint, type check, tests, build и screenshots;
• файлы и каталоги, которые нельзя менять.

Попросите сначала изучить указанные компоненты. Часто выясняется, что контейнер, кнопка, карточка или типографический utility уже существуют.

Постоянные правила храните в CLAUDE.md

Claude Code читает CLAUDE.md как постоянные инструкции проекта. Anthropic рекомендует делать их короткими и конкретными: команды, архитектура, соглашения и обязательные правила процесса.

Для дизайн-системы полезны такие записи:

• компоненты используют токены из указанного источника, raw hex не добавляется без причины;
• общие компоненты находятся в конкретном пакете;
• страницы собираются из публичного API, а не внутренних файлов;
• интерактивным элементам нужен видимый клавиатурный focus;
• скриншоты проверяются на заданных ширинах;
• новые токены и варианты проходят ревью системы.

Не превращайте CLAUDE.md в полный каталог компонентов. Документация Anthropic советует выносить многошаговые процедуры и редко нужный контекст в skills или правила, привязанные к путям.

Передавайте токены файлом, а не палитрой

Дайте агенту настоящий версионируемый источник токенов. В нём нужны устойчивые имена, типы, значения или алиасы, режимы и описания. Отдельно укажите, какие сгенерированные форматы нельзя редактировать вручную.

Сопоставьте названия Figma и кода:

• Figma action/background/primary соответствует color.action.background.primary;
• spacing/layout/gutter соответствует space.layout.gutter;
• text/heading/display соответствует компоненту или utility Display.

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

Подготовьте манифест компонентов

Манифест может быть Markdown или JSON и не обязан повторять TypeScript-типы. Его задача - быстро привести агента к правильному публичному интерфейсу.

Для нужных компонентов укажите:

• имя в Figma и коде;
• import path;
• назначение;
• варианты и состояния;
• контентные слоты;
• адаптивное поведение;
• accessibility-заметки;
• путь к примеру или story.

Для композиции выше манифест может ссылаться на PageContainer, DisplayHeading, AnnotationCard и FocusableLink. Если AnnotationCard отсутствует, агент должен сначала объяснить, повторяется ли паттерн и достоин ли он общей библиотеки. Один экран не обязан создавать глобальный компонент.

Опишите структуру страницы через отношения

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

Для каждой секции зафиксируйте:

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

Если страницу формируют несколько референсов, соберите их в Refframe и подпишите вклад каждого: масштаб заголовка, группировку карточек, плотность или движение.

Формулируйте задачу вокруг доказательств

Рабочая последовательность запроса:

1. изучить перечисленные файлы токенов, компонентов и маршрута;
2. назвать существующие элементы, которые будут переиспользованы;
3. отметить недостающие решения до редактирования;
4. реализовать страницу в заданных границах;
5. запустить целевые проверки;
6. снять скриншоты на указанных ширинах;
7. сравнить их с референсами и перечислить различия;
8. исправить существенные расхождения и объяснить намеренные.

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

Дайте результату возможность не пройти проверку

Anthropic называет проверяемые критерии одной из самых полезных частей запроса. Для интерфейса они могут выглядеть так:

• существующие токены и компоненты переиспользованы;
• новые raw-значения не добавлены без объяснения;
• заголовки и landmarks соответствуют структуре;
• focus, hover, error, loading и disabled работают;
• длинный текст и отсутствие медиа не ломают страницу;
• узкая ширина приводит к понятной перестройке;
• lint, types и целевые тесты проходят;
• визуальные различия действительно разобраны.

Качество результата зависит не от одного огромного промпта, а от цепочки проверяемого контекста: карты системы, токенов, API компонентов, структуры страницы, изученных референсов и команд, которые способны завершиться ошибкой.