Как научить Codex делать хороший дизайн
Зачем это изучать
Codex должен не просто написать HTML и CSS. Он должен открыть готовый сайт в браузере, посмотреть на него, найти слабые места, исправить их и проверить ещё раз.
Проверено: 23 августа 2026 года.
Мы не рисуем макет в Canva, Figma или Photoshop. Codex сам придумывает внешний вид сайта и сразу создаёт его в коде.
Работа выглядит так:
Понять задачу
↓
Придумать внешний вид
↓
Сделать страницу в коде
↓
Открыть её в браузере
↓
Найти и исправить проблемы
↓
Проверить мобильную и desktop-версиюЧто нужно подключить
Для начала достаточно двух skills.
1. $skill-creator
$skill-creator помогает создать собственный skill с правилами дизайна.
Представьте skill как постоянную инструкцию для Codex. Вы один раз объясняете, как нужно делать сайты, а потом вызываете эту инструкцию короткой командой.
Например, мы создадим skill $frontend-quality-loop. Он будет напоминать Codex:
- изучить проект перед работой;
- самому выбрать подходящий стиль;
- не делать шаблонный «нейросетевой» дизайн;
- проверить сайт в браузере;
- исправлять недостатки до хорошего результата.
Официальная инструкция: как создавать и использовать skills.
2. $playwright-interactive
$playwright-interactive позволяет Codex открыть настоящий сайт в браузере.
Без этого Codex видит код, но не видит итоговую страницу. С Playwright он может:
- сделать screenshot;
- проверить сайт на телефоне и большом экране;
- нажать кнопки и заполнить формы;
- найти обрезанный текст и горизонтальную прокрутку;
- проверить меню, ошибки и состояния загрузки;
- исправить страницу и открыть её снова.
Официальный пример OpenAI: создание responsive-интерфейсов с Codex и Playwright.
3. $imagegen — только если нужны изображения
ImageGen нужен не для рисования макета сайта, а для отдельных материалов:
- фоновой иллюстрации;
- изображения товара;
- декоративной текстуры;
- обложки;
- набора изображений в одном стиле.
Структуру страницы, кнопки, текст, сетку и адаптивность Codex всё равно делает в коде.
Нужны ли плагины
Для создания дизайна — нет. Skill и browser-проверка важнее любого плагина.
Плагин нужен, только если информация находится не в проекте. Например:
| Где лежит информация | Зачем может понадобиться plugin |
|---|---|
| GitHub | прочитать issue, обсуждение или требования из pull request |
| Linear | получить описание задачи и критерии готовности |
| Notion | прочитать brief, правила бренда или описание продукта |
| Sentry | увидеть реальные ошибки интерфейса |
| Analytics | понять, на каком шаге пользователи уходят со страницы |
Проверить доступные плагины и способ установки можно в официальном каталоге плагинов Codex.
Не подключайте plugin «на всякий случай». Если вся информация уже есть в репозитории, Codex сможет работать без него.
Skill и plugin — простое различие
| Простыми словами | Пример | |
|---|---|---|
| Skill | инструкция, как выполнять работу | «Всегда проверяй сайт на mobile и desktop» |
| Plugin | подключение к внешнему сервису | «Прочитай требования из GitHub issue» |
Подробнее: Skills & Plugins в официальной документации OpenAI.
Готовый промпт для создания skill
Этот промпт нужно выполнить один раз:
Используй $skill-creator и создай skill `frontend-quality-loop`.
Этот skill должен помогать Codex самостоятельно создавать качественные сайты
сразу в коде, без макетов в Canva, Figma или Photoshop.
Порядок работы:
1. Прочитать AGENTS.md, README и инструкции проекта.
2. Изучить существующие страницы, компоненты, цвета и шрифты.
3. Понять, для кого сайт и какое действие на нём главное.
4. Придумать 2–3 разных варианта визуального направления.
5. Самостоятельно выбрать лучший вариант и коротко объяснить выбор.
6. Создать страницу с настоящим содержанием, а не с бессмысленным lorem ipsum.
7. Использовать существующие компоненты и не добавлять библиотеки без причины.
8. Открыть страницу через $playwright-interactive.
9. Проверить mobile и desktop, кнопки, формы, меню, длинный текст, загрузку,
пустое состояние и ошибки.
10. Сделать screenshots, найти три самые заметные проблемы и исправить их.
11. Повторять проверку, пока серьёзных проблем не останется.
12. Запустить тесты и production-сборку проекта.
Codex не должен делать шаблонный AI-дизайн: огромный пустой первый экран,
градиенты и свечение без причины, карточку вокруг каждого текста, одинаковые
кнопки-пилюли и случайные иконки.
В конце skill должен сообщать:
- что изменено;
- что проверено в браузере;
- какие команды выполнены;
- что осталось непроверенным.
Используй документы из `docs/design/` как стандарт качества. Проверь созданный
skill на нескольких простых примерах.После создания skill длинную инструкцию повторять не нужно.
Промпт: создать новый сайт
Используй $frontend-quality-loop.
Создай сайт для небольшой семейной пекарни. Главная задача сайта — помочь
человеку посмотреть ассортимент и оформить предзаказ.
Сделай дизайн тёплым и живым, но не шаблонным. Сам выбери типографику, цвета,
сетку и характер изображений. Не используй макет из графического редактора —
сразу создавай рабочую страницу в коде.
Добавь главную страницу, каталог, карточку товара и форму предзаказа. Покажи
обычное состояние, загрузку, пустой результат, ошибку и успешную отправку.
Открой сайт через $playwright-interactive. Проверь его на ширине 390 и 1440 px,
исправь визуальные и функциональные проблемы. Заверши только после успешной
сборки и повторной проверки в браузере.Промпт: улучшить существующую страницу
Используй $frontend-quality-loop.
Улучши страницу `/pricing`. Не меняй API, маршруты и работу оплаты.
Сделай тарифы понятнее: усили визуальную иерархию, убери лишний шум, покажи
различия между тарифами и сделай главное действие заметным. Сохрани стиль и
компоненты проекта.
Открой страницу в браузере. Проверь mobile и desktop, длинные названия тарифов,
клавиатуру, focus, загрузку и ошибку. Исправь найденные проблемы и покажи, чем
подтверждён результат.Промпт: только проверить дизайн
Этот запрос ничего не меняет:
Используй $playwright-interactive и проверь страницу `/checkout`.
Посмотри её на mobile и desktop. Проверь понятность главного действия,
типографику, отступы, переполнение, клавиатуру, focus, ошибки формы, загрузку и
успешное завершение.
Код не меняй. Для каждой проблемы напиши:
1. где она находится;
2. что увидел пользователь;
3. почему это мешает;
4. как лучше исправить;
5. насколько проблема серьёзная.Промпт: взять задачу из plugin
Если требования находятся, например, в GitHub:
Прочитай требования из GitHub issue №125 с помощью подключённого GitHub plugin.
Затем используй $frontend-quality-loop и реализуй интерфейс в текущем проекте.
Issue является источником требований, но дизайн создай самостоятельно сразу в
коде. После реализации проверь страницу через $playwright-interactive.
Не изменяй issue и не отправляй комментарии без отдельной просьбы.Что Codex должен проверить сам
Перед завершением работы Codex должен ответить «да» на простые вопросы:
- Понятно ли за несколько секунд, о чём эта страница?
- Видно ли главное действие?
- Удобно ли читать текст?
- Работает ли сайт на телефоне?
- Можно ли пройти главный путь клавиатурой?
- Есть ли состояния загрузки, ошибки и пустого результата?
- Не обрезается ли текст?
- Не появилась ли горизонтальная прокрутка?
- Не выглядит ли страница как случайный AI-шаблон?
- Прошла ли production-сборка?
Если ответ «нет», Codex должен исправить проблему и повторить проверку.
Короткий вариант
Если skill уже создан, для обычной задачи достаточно написать:
Используй $frontend-quality-loop. Создай эту страницу сразу в коде, сам выбери
сильное визуальное направление, проверь результат через $playwright-interactive
на mobile и desktop и исправляй проблемы до успешной сборки.