Разработка с Claude Code: от задачи до проверенного pull request

Допустим, у вас небольшой интернет-магазин. Покупатель открывает каталог из нескольких сотен товаров и просит поиск по названию. Claude Code может изучить проект, изменить код, запустить проверки и помочь оформить pull request. Чтобы такой цикл оставался управляемым, заранее определите результат для покупателя и точки, в которых будете проверять работу.

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

Что означают ветка, коммит и PR

Ветка — отдельная линия разработки в Git. В ней удобно собирать изменения одной задачи. Коммит фиксирует выбранное состояние файлов и сообщение о выполненной работе. Pull request, или PR, показывает коллегам изменения ветки и открывает обсуждение перед слиянием.

Claude Code работает с этими операциями через доступные инструменты. В частности, официальный сценарий создания PR использует GitHub CLI — команду gh. Для обращения к GitHub потребуются установленный клиент и авторизация. Возможности такого рабочего процесса описаны в документации Claude Code.

Договоритесь о границе заранее: можно ли агенту создавать коммиты, отправлять ветку в GitHub и открывать PR. Каждое из этих действий имеет свой результат. Локальная готовность функции, отправленная ветка и опубликованный PR должны звучать в отчёте отдельно.

Шаг 1. Превратите пожелание в проверяемую задачу

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

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

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

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

Сначала покажи план: связанные файлы, поток данных, команды проверки и открытые вопросы. Изучи git status и текущий diff. На этом этапе только чтение.

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

Шаг 2. Сохраните исходное состояние

Перед началом посмотрите git status и git diff. В рабочей папке могут лежать чужие изменения, эксперимент или незавершённая правка дизайна. Агенту нужно знать, какие файлы относятся к текущей задаче.

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

Выберите имя ветки по правилам команды, например feature/catalog-search. Зафиксируйте исходные команды тестирования из проекта. Полезно один раз выполнить целевой тест до изменений: так вы увидите, какие ошибки существовали ещё до начала задачи.

Команды из интернета здесь легко вводят в заблуждение. В одном проекте проверка называется npm run test, в другом используется pnpm test, в третьем нужен отдельный пакет. Claude должен прочитать конфигурацию и объяснить свой выбор.

Шаг 3. Сделайте первую законченную правку

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

Создай ветку feature/catalog-search от согласованной исходной ветки. Реализуй поиск по утверждённому плану, сохрани существующие фильтры и стиль интерфейса. Изменения других задач оставь нетронутыми.

Добавь тесты на пустую строку, регистр, пробелы и совместную работу с категорией. Запусти целевые проверки. Покажи список изменённых файлов, краткое объяснение diff и фактический результат команд. Коммит и отправку ветки пока оставь следующим этапом.

После выполнения откройте diff. Ищите связь с задачей: откуда берутся товары, где нормализуется строка, в каком порядке применяются условия. Обратите внимание на добавленные зависимости и изменения конфигурации. Для простой функции они требуют конкретного объяснения.

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

Шаг 4. Проверьте путь покупателя

Автоматический тест подтверждает отдельное поведение кода. Проверка в браузере показывает, как это поведение собрано в интерфейсе. В нашем примере пройдите короткую последовательность:

1. Откройте каталог и выберите категорию «Напитки».
2. Введите «чай», затем « ЧАЙ » и сравните результаты.
3. Включите фильтр наличия и убедитесь, что условия работают совместно.
4. Введите заведомо отсутствующее название и проверьте сообщение.
5. Очистите строку и убедитесь, что категория сохранилась.

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

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

Шаг 5. Оформите понятный коммит

Перед коммитом ещё раз сравните список файлов с задачей. В индекс Git добавляйте конкретные пути; затем смотрите git diff --cached, чтобы проверить состав будущего коммита. Работа индекса описана в официальной документации Git.

Название коммита объясняет изменение, например: feat: add catalog search with existing filters. Если у команды другой стиль, ориентируйтесь на её историю. Для маленькой функции обычно достаточно одного содержательного коммита; крупную задачу удобнее разделять по законченным изменениям.

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

Шаг 6. Подготовьте PR для коллеги

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

Проверь итоговый diff относительно целевой ветки и подготовь коммит только по задаче поиска. Затем составь заголовок и описание PR: пользовательская проблема, изменённое поведение, выполненные проверки, ограничения.

Сверь названия проверок с фактическими запусками. До отправки покажи подготовленный текст и состав коммита. Отдельно укажи, какие действия с GitHub ещё предстоят.

Учебный образец описания:

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

Когда отправка разрешена, PR можно создать через gh pr create; флаг --draft открывает черновик для раннего обсуждения. Параметры команды собраны в руководстве GitHub CLI. После создания откройте сам PR и проверьте целевую ветку, файлы, описание и состояние проверок.

Если возник конфликт или ревью вернуло замечания

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

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

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