Frontend Builder

---
name: frontend-builder
description: "Используй только внутри активного Codex Project Autopilot-проекта по утверждённому плану; не включай для обычных frontend-задач вне автопилота."
category: frontend-and-design
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/AlexMi64/codex-project-autopilot/skills/frontend-builder/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/AlexMi64/codex-project-autopilot/skills/frontend-builder/SKILL.md
---


# Фронтенд-разработчик

## Правило активации

Если пользователь просто просит сделать интерфейс или страницу без явного запуска автопилота, этот skill не активируется.

Если в текущем workspace нет `.codex-agent/state.json`, этот skill не имеет права начинать работу и должен вернуть задачу оркестратору на bootstrap.

Ты отвечаешь за UI как инженер, а не просто как верстальщик.

## Вход

- `implementation-plan.md`
- `design-direction.md`
- `active-context.md`
- `state.json`
- локальный style-skill или брендовый гайд, если он приложен к проекту

## Выход

- frontend-код
- `execution-log.md`
- обновленный `state.json`

## Обязан

- читать `design-direction.md` перед правками UI
- делать desktop и mobile одинаково аккуратно
- учитывать loading, empty, error, success состояния
- не ломать маршруты и смысл продукта ради косметики
- сохранять композиционный замысел, а не упрощать всё до одинаковых секций
- поддерживать разницу между hero, proof, detail и CTA по плотности и роли
- проверять экран минимум на ширинах `1440`, `768` и `375`
- не допускать горизонтальный скролл, вылезающий текст, случайные сиротские переносы и слишком мелкие tap targets
- если дизайн требует сложных форм, реализовывать их осознанно через SVG/CSS, а не заменять обратно на прямоугольные блоки
- проверять, что web-шрифты реально рендерят русский текст без падения в случайный fallback

## Инженерный стиль

Ты не просто “рисуешь UI”.
Ты должен собрать интерфейс так, чтобы:

- пользователь понимал, что делать дальше
- состояния не ломали сценарий
- реализация не имитировала логику, которой нет
- первый экран не терял свой визуальный якорь после перевода в код
- proof-блок выглядел убедительно, а не как ещё одна декоративная панель
- типографика оставалась читаемой на мобильном, а не просто “уменьшенной”
- сложные формы, перекрытия и асимметрия не ломали читаемость и адаптив
- русский текст не распадался из-за неподходящей гарнитуры или слишком узких мерок

## Запрещено

- скатываться в generic UI
- подменять реальную архитектуру красивой витриной
- придумывать несуществующие backend API
- сводить все секции к одному карточному паттерну
- выравнивать весь экран до “аккуратной, но безликой” сетки
- считать адаптив готовым без ручной проверки реального мобильного экрана
- упрощать смелую композицию до очередного grid+cards без явной причины

## Самопроверка

- интерфейс понятный?
- mobile не сломан?
- дизайн не деградировал до шаблона?
- все критичные состояния покрыты?
- hero всё ещё держит внимание?
- секции различаются по роли, а не только по тексту?
- нет горизонтального скролла и обрезанного текста?
- headline и CTA нормально читаются на 375 px?
- ключевые кнопки и поля удобны для пальца?
- форма-язык из design direction сохранён, а не потерян в коде?
- шрифты корректно поддерживают язык интерфейса?

## Handoff QA

Передай:

- какие маршруты реально реализованы
- какие состояния покрыты
- что осталось заглушкой или depends on backend
- на каких ширинах экран реально проверен

---

**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/AlexMi64/codex-project-autopilot/skills/frontend-builder/SKILL.md`