Перед новой сессией сохраните состояние задачи в файле HANDOFF.md внутри проекта, затем попросите Claude Code прочитать его и проверить текущее состояние кода. Запишите цель доработки, последние изменения, результаты проверок и ближайшее действие. Так продолжение работы будет опираться на файлы и понятный план. Ниже разберём, что включить в такой документ, как отделить рабочие решения от предположений и с какой инструкции начать следующую сессию, чтобы не повторять уже выполненную работу.
Почему после сброса контекста Claude Code теряет задачу?
В переписке остаются детали, которых нет в самом коде: почему вы отказались от одного варианта, какую ошибку уже проверяли и что решили пока не менять. Когда эта часть истории недоступна новой сессии, агенту приходится восстанавливать замысел по файлам. При этом код показывает текущее устройство сайта, но не объясняет все решения владельца.
Например, вы дорабатываете форму заявки на сайте небольшой компании. Кнопка уже работает, однако сообщение об ошибке перекрывает соседнее поле. В переписке вы договорились сохранить расположение полей и исправить только сообщение. Без этой договорённости Claude Code может предложить переделать всю форму.
Файл передачи задачи связывает запрос владельца с текущим состоянием проекта. Название HANDOFF.md здесь условное: это обычный текстовый документ, который нужно явно поручить прочитать. Само имя файла не гарантирует, что агент загрузит его в новой сессии.
Если агент снова исследует знакомые файлы и повторяет прежние попытки, проверьте, достаточно ли конкретно описана точка остановки. Другие причины такого поведения разобраны в статье почему Claude Code тратит токены без результата и как его остановить.
Что сохранить перед новой сессией Claude Code?
Остановитесь на понятной границе работы: после отдельной правки или проверки. Попросите агента обновить файл передачи и показать его содержимое. Для небольшой задачи достаточно следующих блоков.
- Цель и критерий готовности. Опишите видимый результат: «При пустом поле форма показывает подсказку рядом с ним и не отправляет заявку».
- Текущее состояние. Укажите, что уже работает, что осталось сделать и какие файлы менялись. Отдельно отметьте чужие правки, которые нельзя затрагивать.
- Решения и ограничения. Объясните, почему выбран текущий подход. Например: «Сохраняем существующие стили формы, потому что их используют другие страницы».
- Проверки и доказательства. Запишите команду или ручной сценарий, фактический результат и область проверки. Если тест не запускали, напишите это прямо.
- Следующее действие. Назовите одну задачу, с которой нужно продолжить: «Воспроизвести перекрытие подсказки в узком окне браузера».
Разделяйте факт и предположение. Фраза «ошибка связана со стилями» слишком уверенная, если причину ещё не проверили. Точнее так: «Перекрытие видно в узком окне. Предположение: причина в позиционировании подсказки. Проверить правило position в стилях формы».
Не переносите весь разговор. Повторные просьбы, отвергнутые формулировки и длинные журналы затрудняют поиск текущего решения. Из журнала ошибки сохраните характерную строку и действие, после которого она появляется. Если полный журнал нужен для диагностики, укажите путь к отдельному файлу.
Как выглядит файл передачи задачи для доработки сайта?
Ниже условный пример для формы заявки. Пути и результаты иллюстрируют структуру документа; перед использованием замените их сведениями из своего проекта. Текст можно сохранить в HANDOFF.md обычными абзацами.
Задача: исправить показ ошибок в форме заявки. Готово, когда подсказка появляется возле нужного поля, не перекрывает соседние элементы и исчезает после корректного ввода.
Текущее состояние: проверка пустых полей добавлена. По ручной проверке в широком окне подсказки видны. В узком окне сообщение под полем телефона перекрывает кнопку. Отправку корректно заполненной формы после последних правок не проверяли.
Файлы: src/components/RequestForm.tsx содержит логику формы; src/styles/request-form.css задаёт расположение полей и подсказок. Перед продолжением проверить, существуют ли эти пути в текущей версии проекта.
Решения: сохранить порядок полей и существующий способ отправки заявки. Не менять остальные формы сайта. Предыдущую попытку с фиксированной высотой блока отклонили: длинный текст подсказки не помещался.
Проверки: вручную открыли форму в широком и узком окне, оставили телефон пустым и нажали кнопку отправки. Перекрытие воспроизводится в узком окне. Автоматические тесты не запускали. Следующее действие: проверить стили подсказки и предложить локальную правку.
У такого описания есть практическая ценность и для владельца бизнеса: видно, что уже можно попробовать самостоятельно. В этом примере проверка доступна без чтения кода — открыть форму, оставить поле пустым и посмотреть, где появилась подсказка.
Постоянные правила проекта храните отдельно от временной передачи задачи. В CLAUDE.md можно описать принятые команды и ограничения работы с кодом; в HANDOFF.md — текущую точку остановки. Шаблоны CLAUDE.md упоминаются и в русскоязычном руководстве по Claude Code из подборки источников (GitHub, sfrangulov/claude-code-handbook-ru). Не копируйте туда историю каждой доработки.
Как запустить новую сессию и проверить, что задача восстановлена?
Начните с инструкции на чтение и сверку. Сразу разрешать новые правки не стоит: файл передачи мог устареть, пока другой человек менял проект. Подойдёт такой запрос:
«Прочитай HANDOFF.md и инструкции проекта. Пока ничего не меняй. Проверь текущее состояние файлов и локальные изменения. Кратко назови цель, что уже сделано, что осталось и с какого действия предлагаешь продолжить. Если описание расходится с кодом, перечисли расхождения».
Дальше двигайтесь по короткой последовательности. Каждый этап заканчивайте понятным результатом.
- Сверьте пересказ задачи. Агент должен назвать нужную форму, ограничение на изменения и конкретную ошибку.
- Попросите воспроизвести проблему доступным способом. Если среда не позволяет открыть сайт или запустить тест, пусть агент укажет это ограничение.
- Разрешите одну локальную правку. Согласуйте её границы до изменения файлов.
- Проверьте результат исходным сценарием и убедитесь, что соседний рабочий сценарий сохранился.
- Обновите HANDOFF.md: что изменилось, чем проверили и на чём остановились.
После сверки полезно зафиксировать состояние прямо в разговоре: «Задача восстановлена, правки ещё не начаты; следующий шаг — воспроизвести перекрытие». Такая отметка помогает вернуться к работе после перерыва и сразу увидеть текущий этап.
Просьбу «проверь всё» замените конкретным сценарием. Для формы это пустое поле, исправление ошибки и отправка корректного ввода. Когда правка затронула несколько частей сайта, полезен отдельный просмотр изменений: как организовать его, разобрано в материале «Claude Code пишет, Codex проверяет».
Если сайт после вайбкодинга передают на техническую проверку или доработку, приложите тот же файл к задаче исполнителя. По нему можно определить границы работ и составить план тестирования. При этом запись «работает» всё равно требует проверки на текущей версии сайта.
Типичные ошибки при передаче задачи
- Записывать «почти готово». Замените оценку перечнем: какая часть работает, какой сценарий ломается и что ещё не проверяли.
- Выдавать предположение за найденную причину. Помечайте гипотезу и рядом указывайте действие, которое её подтвердит или опровергнет.
- Считать старый тест доказательством для нового кода. Если после проверки меняли связанные файлы, повторите нужный сценарий.
- Разрешать агенту попутную переделку проекта. Зафиксируйте границы: какие файлы и поведение относятся к текущей задаче.
- Оставлять устаревшее следующее действие. После завершения этапа замените его новым, иначе следующая сессия начнётся с уже выполненной работы.
Сейчас создайте HANDOFF.md в папке проекта и запишите одну строку: «Следующее действие: …». Укажите конкретную проверку или правку, с которой продолжите работу; это займёт меньше двух минут.
