Схема промпта из прошлого урока выглядит очевидной, пока вы не сядете за настоящую задачу. Тогда выясняется, что «область» — это не один файл, а маршрут, компонент, стили и валидация; что «образец» надо ещё найти в проекте; а «критерий проверки» для интерфейса не сводится к прогону тестов.

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

После этого урока вы проведёте задачу целиком: от постановки в plan mode до принятого результата с замкнутым циклом проверки.

Что уже умеем / что добавим

В уроке 4.1 вы разобрали промпт на пять блоков и научились передавать контекст через @, изображения и пайпы. Сейчас применим это к сквозной задаче: разберём, как декомпозировать её на промпты, какой контекст собрать до начала работы и как проверять результат по шагам, а не в конце.

Что вы узнаете в рамках статьи

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

Ключевые термины

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

Постановка: что именно мы делаем

Начнём с того, что задачу надо сформулировать для себя, прежде чем формулировать для агента. «Сделать страницы авторизации» — это не постановка, это направление.

Разложим на осязаемое:

• Страница входа: поля почты и пароля, кнопка отправки, ссылка на регистрацию
• Страница регистрации: почта, пароль, подтверждение пароля, кнопка, ссылка на вход
• Валидация на клиенте: формат почты, минимальная длина пароля, совпадение подтверждения
• Состояния: ошибка отдельного поля, ошибка от сервера, блокировка кнопки во время отправки
• Доступность: связь label с полем, фокус, сообщения об ошибке доступны скринридеру

Обратите внимание, что здесь нет ни слова о том, как это реализовать. Это список результатов, а не решений — ровно то, что нужно агенту.

Сбор контекста до первого промпта

Худший способ начать — сразу попросить «сделай». Агент напишет код, который работает, но выглядит чужим в вашем проекте: другой подход к формам, другие имена классов, своя обработка ошибок.

Начните с исследования в plan mode. Включите его нажатием Shift+Tab — статусная строка покажет ⏸ plan mode on.

Разберись, как в проекте устроены формы и маршруты.
Посмотри @src/components, @src/routes и найди существующую форму,
которую можно взять за образец. Расскажи: какой подход к валидации
используется, как показываются ошибки полей, как оформлены кнопки
и есть ли готовые компоненты ввода.

Ответ на этот запрос — ваш будущий блок «образец». Если в проекте нашлась, скажем, форма профиля, дальше вы будете ссылаться именно на неё, и агенту не придётся изобретать стиль.

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

Первый промпт: страница входа целиком

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

Возьмите одну страницу. Она даст проверяемый результат и заодно задаст шаблон для второй.

Сделай страницу входа по маршруту /login.

Образец: @src/components/ProfileForm.tsx — тот же подход
к валидации и та же разметка полей.

Требования:
- поля: email и password, у обоих связанный label
- валидация на клиенте: email по формату, password не короче 8 символов
- кнопка отправки заблокирована, пока идёт запрос
- ошибка от сервера показывается над формой, не затирая введённое
- ссылка на /register под формой

Новых зависимостей не подключай.
Проверка: запусти dev-сервер, открой /login, сделай скриншот.

Разберём, почему промпт устроен так. «Образец» снимает вопрос о стиле. Требования сформулированы как наблюдаемые признаки: не «сделай хорошую валидацию», а «password не короче 8 символов» — это можно проверить, глядя на экран. Ограничение про зависимости отсекает соблазн подключить библиотеку форм. Критерий проверки завершается скриншотом, потому что результат здесь визуальный.

Вторая страница и уточнения

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

По тому же образцу сделай /register.
Отличия: добавь поле подтверждения пароля с проверкой совпадения,
ссылку снизу веди на /login.

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

Сообщение об ошибке поля появляется только после отправки формы.
Нужно, чтобы оно показывалось при уходе фокуса с поля, если
значение уже невалидно. При этом пока пользователь печатает
в поле, ошибка не должна мигать.

Если после двух уточнений результат по-прежнему не тот, не идите на третий круг: /clear и новый промпт, в который вошло всё выясненное, работают лучше, чем сессия с накопленными неудачными попытками.

Приёмка результата

Критерий приёмки стоит записать до начала работы — тогда вы принимаете результат по списку, а не по ощущению.

- /login и /register открываются и отрисовываются
- у каждого поля есть связанный label
- невалидная почта даёт ошибку при уходе фокуса
- короткий пароль даёт ошибку с указанием минимальной длины
- несовпадение подтверждения на /register даёт ошибку
- во время отправки кнопка заблокирована
- ошибка сервера видна, введённые значения не потеряны
- ссылки между страницами работают в обе стороны

Пройдите список руками: это займёт пару минут и почти всегда вскрывает пункт-другой, которые агент счёл выполненными, а вы — нет.

Полезен и ещё один приём: попросить скриншот каждого состояния и сравнение с ожидаемым. Тогда цикл проверки замыкается на стороне агента, а вам остаётся просмотреть картинки.

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

• Одна большая задача одним промптом. Обе страницы, вся валидация и все состояния в одном запросе дают дифф, который невозможно нормально проверить. Делайте страницу за страницей: первая задаёт образец для второй.
• Пропуск фазы исследования. Без явного указания на существующую форму агент напишет код в своём стиле, и вы получите правильно работающий, но чужеродный кусок проекта. Полминуты на поиск образца экономят час на приведении к стилю.
• Непроверяемые требования. «Красивая форма», «удобная валидация», «понятные ошибки» невозможно принять или отклонить объективно. Переводите такие формулировки в наблюдаемые признаки: минимальная длина, момент появления ошибки, состояние кнопки.
• Приёмка по общему впечатлению. Если список критериев не записан заранее, вы проверите то, что вспомните, а вспомните обычно самое очевидное. Состояния ошибок и блокировка кнопки выпадают чаще всего.

Наиболее частые вопросы

• Что делать, если в проекте нет подходящего образца формы? — Тогда решение о подходе принимаете вы и записываете его в промпт явно: какой способ валидации, как показывать ошибки. Иначе агент выберет сам, и следующие формы придётся подгонять под этот выбор.
• Нужно ли давать макет, если дизайна ещё нет? — Нет, достаточно списка требований. Но если макет есть, приложите его изображением: это точнее любого словесного описания и даёт агенту материал для сравнения со скриншотом результата.
• Насколько подробно описывать валидацию? — Ровно до уровня проверяемых чисел и условий: формат почты, минимальная длина, момент показа ошибки. Всё, что нельзя проверить взглядом на экран, стоит переформулировать.
• Стоит ли просить тесты для формы? — Да, если в проекте уже есть тесты интерфейса и вы можете указать образец. Если тестовой инфраструктуры нет, разворачивать её внутри этой задачи не нужно — это отдельная работа.
• Агент сделал обе страницы, но регистрация отличается по стилю. Как быть? — Точечным промптом: назовите файл-эталон и файл, который надо привести к нему, и перечислите конкретные расхождения.

Итоги

Поздравляем: вы провели полноценную задачу от постановки до приёмки по схеме, а не наугад. Вы разложили расплывчатое «сделать авторизацию» на наблюдаемые требования, собрали контекст до первого запроса, разбили работу на промпты проверяемого размера и приняли результат по записанным заранее критериям.

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