# Frontend Engineering

> Создать или изменить интерактивный frontend-сценарий, компонент или переход клиентского состояния, включая доступность и адаптивность. Применять для реализации продукта; браузерные регрессионные тесты относятся к E2E-тестированию frontend, а запрос только на проверку — к review кода.

- Skill: `fbakiyev/frontend-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/frontend-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/frontend-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/frontend-engineering

---


# Frontend-разработка

## Начать с пути пользователя

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

## Решения при реализации

- Связывай асинхронный результат с состоянием, из которого он был запрошен. Если пользователь меняет выбор или запрос до прихода ответа, старый ответ не должен перезаписать новое намерение. Выбери отмену, идентификатор запроса или другой существующий механизм и проверь обратный порядок завершения.
- Отличай оптимистическое отображение от подтверждённого состояния сервера. Для изменения определи поведение при повторной отправке, восстановление после ошибки и то, что остаётся видно после навигации или перезагрузки. Отключение кнопки не заменяет серверную дедупликацию, а отмена не доказывает, что изменение отменено.
- Предпочитай нативную семантику элементов управления и осмысленные имена для средств доступности. Для изменяемых диалогов, навигации и валидации проверь работу с клавиатуры, установку и возврат фокуса, а также восприятие статусов и ошибок без опоры только на цвет. Одного визуального сходства недостаточно для подтверждения доступности.
- Определи единственного владельца состояния, общего для компонентов, URL, кеша или хранилища. Дублируемое вычисляемое состояние может разойтись; сохраняй предусмотренное проектом поведение навигации и перезагрузки вместо добавления независимых копий ради одного экрана.
- Проверь реальные ограничения содержимого: длинные имена, переведённые подписи, сообщения валидации, узкий экран и масштабирование, где это уместно. Скриншот с короткими заглушками может скрыть переполнение или недоступное основное действие.

Ограничивай изменения запрошенным дизайном и поведением. Не добавляй посторонний редизайн и не оставляй основной сценарий за неработающим элементом управления.

## Результат и проверка

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

Для доказанной гонки состояния или сбоя восстановления добавь прицельный тест. Браузерное E2E-покрытие оставляй для границ, которые нельзя проверить на нижних уровнях. Просмотри изменённые макеты на характерных ширинах вместо заявления о проверке всех устройств.

Верни работающее изменение, перечень фактически проверенного поведения и недоступные проверки браузера или доступности. Прикладывай скриншоты только когда они поясняют видимый результат; отдельный план тестирования или передача контекста зависят от задачи, а не обязательны для каждой UI-правки.