Claude Skills для дизайна и фронтенда

Зачем дизайнеру и фронтендеру отдельные навыки

Без навыка каждый новый чат начинается с нуля: вы заново объясняете, какие используете отступы, какой у вас набор цветов, что кнопки скруглены на 12px, а не на 4, и что иконки — из одного набора. Через десять таких итераций накапливается усталость и рассинхрон: две страницы, сделанные в разные дни, выглядят как из разных продуктов.

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

• Токены и переменные. Модель перестаёт выдумывать #3B82F6 и берёт var(--accent), потому что в навыке записан список токенов и запрет на хардкод цветов.
• Состояния компонентов. В навыке можно потребовать, чтобы у каждого интерактивного элемента были прописаны hover, focus-visible, active, disabled и loading — то, о чём в обычном промпте забывают в 9 случаях из 10.
• Доступность. Контраст, размеры зон нажатия, семантические теги, атрибуты aria — их проще один раз внести в навык как обязательный чек-лист, чем каждый раз ловить на ревью.

Как устроен design-скилл: минимальная рабочая структура

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

ui-kit/
├── SKILL.md          ← правила: токены, сетка, состояния, запреты
├── tokens.css        ← источник правды по цветам/размерам
├── components/
│   ├── button.html   ← эталонная разметка
│   └── card.html
└── checklist.md      ← что проверить перед выдачей результата

Тело навыка полезнее всего писать не абзацами, а в виде правил и запретов — модель их соблюдает точнее, чем описательный текст:

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

Подборка навыков под конкретные задачи

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

Разберём три самых полезных подробнее.

ui-kit — базовый. Именно он превращает Claude из генератора абстрактной вёрстки в исполнителя, который работает внутри вашего проекта. Ключевой пункт внутри — жёсткий запрет на изобретение новых значений: если нужного токена нет, модель должна сказать об этом, а не подобрать «похожий» цвет.

a11y-check окупается быстрее всех, потому что доступность — это чистый чек-лист, а чек-листы модель выполняет почти безошибочно. Минимальный набор проверок: контраст текста к фону, видимый фокус на всех интерактивных элементах, alt у смысловых картинок, корректные заголовки h1–h3 без пропусков уровней, зоны нажатия не меньше 44×44 px на мобильных.

design-review — навык не для генерации, а для критики. Он полезен, когда вы уже сверстали страницу и хотите второй взгляд: попросите пройтись по чек-листу и вернуть список проблем с приоритетами, а не переделывать сразу. Это тот случай, когда ценность модели не в скорости, а в занудстве.

Как подключить навык

Механика одинаковая для всех навыков: положить папку в каталог навыков проекта или пользователя и убедиться, что описание достаточно конкретное, чтобы модель поняла, когда его применять.

# навык уровня проекта — работает только в этом репозитории
.claude/skills/ui-kit/SKILL.md

# навык уровня пользователя — доступен во всех проектах
~/.claude/skills/a11y-check/SKILL.md

Проектные навыки логично держать в репозитории и коммитить — тогда правила дизайн-системы едут вместе с кодом и работают у всей команды. Личные навыки вроде design-review удобнее хранить у себя: они не зависят от конкретного продукта.

Если Claude Code ещё не установлен, начните с инструкции для вашей системы: установка на Windows или установка на macOS. Заодно имеет смысл сразу настроить разрешения, чтобы агент не переспрашивал на каждой правке файла — на дизайнерских задачах правок много, и постоянные подтверждения съедают весь выигрыш в скорости.

Пример: от макета до свёрстанной секции

Типичный рабочий цикл с навыком выглядит так — обратите внимание, что промпт становится коротким, потому что все правила уже лежат в навыке.

Свёрстай секцию «Тарифы»: три карточки, средняя выделена.
Макет — в приложенном скриншоте. Используй ui-kit.

Что происходит дальше: модель подтягивает токены, берёт структуру карточки из эталонного компонента, добавляет состояния и адаптив по вашим брейкпоинтам, а в конце проходит по чек-листу из навыка. Результат почти никогда не идеален с первого раза, но правки становятся точечными («увеличь отступ между карточками на шаг шкалы»), а не «переделай всё».

Второй заход — ревью: «Проверь секцию навыком a11y-check». На выходе — список конкретных проблем, а не общие слова про доступность. Такой двухшаговый цикл (сделать → отревьюить другим навыком) даёт заметно более стабильное качество, чем попытка получить идеальный результат одним промптом.

Навык переносит проверку качества с вашей головы на инструмент. Вы описываете стандарт один раз, а соблюдается он в каждой задаче.

Если работа идёт не в репозитории, а в чате, часть тех же задач закрывается через Artifacts — интерактивный предпросмотр интерфейса прямо в переписке. Это удобно для быстрых прототипов, но токены и дизайн-система туда не подтягиваются, поэтому для продакшена связка «репозиторий + навык» надёжнее.

Частые ошибки

• Один навык на всё. Огромный SKILL.md на 400 строк модель применяет хуже, чем три коротких по 60. Дробите по задачам.
• Правила без запретов. «Используй наши цвета» работает слабее, чем «запрещено писать hex-значения в коде, только переменные из tokens.css».
• Нет примеров разметки. Один эталонный компонент экономит десятки строк словесных объяснений и держит именование классов в одном стиле.
• Навык не обновляется. Дизайн-система поехала, а навык остался прежним — и агент аккуратно воспроизводит устаревшие правила. Обновление навыка стоит вписать в тот же процесс, что и обновление токенов.
• Слепое доверие результату. Вёрстка компилируется и выглядит правдоподобно, но это не гарантия корректности: проверяйте на реальных данных, длинных текстах и узких экранах. Общий подход к безопасной работе с сгенерированным кодом разобран в статье про безопасность вайбкодинга.