Чтобы перенести проект из Claude Code в Codex или Gemini CLI, сохраните код, рабочие инструкции и описание текущей задачи в папке проекта. Затем настройте новый инструмент и проверьте, что он прочитал правила. Историю чата целиком переносить обычно не требуется: полезнее зафиксировать решения и ограничения. Ниже разберём, какие файлы подготовить, как учесть различия между агентами и с какой задачи начать проверку, чтобы случайно не сломать рабочий сайт.
Что нужно сохранить перед сменой ИИ-агента?
Представим сайт небольшой компании: каталог уже работает, а агент помогает менять карточки товаров. Часть требований лежит в коде, часть осталась в переписке. Например, владелец попросил сохранить адреса страниц, но в файлах проекта этого нет. Новый помощник увидит код, однако сам о такой договорённости не узнает.
Перед переносом соберите рабочий контекст в папке проекта. В материале о блокировках Claude описан именно такой подход: инструкции хранят обычным текстовым файлом, чтобы они оставались у владельца при смене инструмента (источник: vc.ru, «Бан в Claude показал главное: ваша работа не должна жить внутри чата»).
- Сохраните текущую версию кода. Если используете Git, систему учёта изменений, зафиксируйте рабочее состояние отдельным коммитом.
- Запишите, как запустить сайт и проверить сборку. Берите команды из самого проекта, не просите нового агента угадывать их.
- Опишите текущую задачу: что уже готово, что осталось и по каким признакам вы примете результат.
- Перечислите ограничения: какие страницы, тексты и настройки нельзя менять без согласования.
- Сохраните список известных ошибок, чтобы агент не принял старую проблему за последствие своих правок.
Если переносите проект на другой компьютер, проверьте и рабочее окружение: установлены ли нужные программы, доступны ли зависимости. Файлы с паролями и ключами доступа передавайте отдельно от общих инструкций. В правилах достаточно написать, какой доступ нужен для запуска, без самих секретов.
Как перенести CLAUDE.md в Codex или Gemini CLI?
Claude Code использует файл CLAUDE.md для правил проекта. Для Codex ориентиром будет AGENTS.md, а для Gemini CLI — GEMINI.md. Названия таких файлов упоминаются в материалах о переносимости инструкций и работе с агентами (источники: vc.ru, «Бан в Claude показал главное: ваша работа не должна жить внутри чата»; Хабр, «Как работать с Claude Code, Antigravity и Codex в 2026: база вайбкодинга»).
Начните с копии содержимого CLAUDE.md, затем отредактируйте её под новый инструмент. Простого переименования мало, если внутри есть команды или ссылки на возможности Claude Code. Отдельно проверьте, где установленная версия агента ищет инструкции и какие правила имеют приоритет.
| Что переносим | Что с этим делать |
| Назначение сайта и ограничения бизнеса | Сохранить по смыслу: кому нужен сайт, что на нём должно работать, какие изменения требуют согласования. |
| Команды запуска и тестов | Перенести и сверить с файлами проекта. Удалить команды, которые больше не работают. |
| Указания для Claude Code | Проверить вручную. Заменить обращения к его функциям на понятный порядок действий. |
| Скиллы и внешние подключения | Настроить отдельно. Упоминание подключения в тексте ещё не даёт новому агенту доступ к нему. |
| История обсуждения задачи | Сжать до принятых решений, открытых вопросов и следующего действия. |
Если продолжаете пользоваться несколькими агентами, держите общие требования в отдельном документе. В файлах для каждого инструмента укажите, что этот документ нужно прочитать перед работой. Затем проверьте, что агент действительно его открыл: одна ссылка внутри инструкции не подтверждает чтение.
Скиллы тоже стоит пересмотреть. Это дополнительные инструкции для отдельных задач, и переносить их все подряд нет смысла. Для такой ревизии пригодится разбор, как выбрать skill и безопасно подключить его к проекту.
Что написать в рабочих инструкциях проекта?
Хорошая инструкция помогает принять решение в конкретной ситуации. Фраза «делай качественно» не объясняет, можно ли менять меню или устанавливать новую библиотеку. Лучше прямо назвать границы работы и способ проверки.
Для сайта услуг можно взять такой каркас и заполнить его своими сведениями. Это пример структуры, а не готовые требования для любого проекта:
- Назначение: сайт описывает услуги и помогает посетителю отправить заявку.
- Границы задачи: менять только согласованную страницу; меню и адреса страниц сохранить.
- Порядок работы: сначала изучить файлы и предложить план, затем дождаться согласования правок.
- Проверка: использовать команды из документации проекта, проверить страницу на узком экране и работу формы.
- Завершение: перечислить изменения, результаты проверок и всё, что проверить не удалось.
- Остановка: при неожиданном изменении файлов или ошибке сборки сообщить о проблеме до продолжения работы.
Долгосрочные правила отделите от заметок по текущей задаче. Указание «сегодня меняем заголовок главной страницы» быстро устареет, а запрет менять адреса страниц без согласования останется полезным. Так в основном файле не накопятся поручения, которые уже выполнили.
Если проект передаёт подрядчик, включите эти документы в состав результата: инструкцию запуска, правила для агента и перечень незавершённых задач. При проверке сайта после вайбкодинга такой комплект помогает разобраться, что именно сделали и как воспроизвести проверку.
Как проверить, что новый агент понял проект?
Первый запуск проведите без разрешения менять файлы. Попросите агента прочитать инструкции и пересказать задачу своими словами. Вот пример запроса: «Изучи правила проекта. Перечисли файлы, из которых ты взял инструкции, объясни порядок запуска и проверки. Укажи ограничения и противоречия. Пока ничего не изменяй».
Сверьте ответ с документами. Если агент не упомянул запрет менять адреса страниц, уточните, прочитал ли он нужный файл. Сначала устраните расхождение, затем переходите к правкам.
- Выберите небольшую задачу, например изменение текста на одной странице, и заранее запишите ожидаемый результат.
- Попросите план с перечнем файлов, которые агент собирается менять. Уберите из него действия вне задачи.
- После правок посмотрите список изменений. Замена заголовка не должна попутно менять настройки сборки без объяснения.
- Выполните проверки проекта и откройте страницу в браузере. Зафиксируйте рабочую версию отдельно от предыдущей.
В руководстве по вайбкодингу на Хабре работу с агентами описывают как управляемый цикл: требования, план, задачи, контекст, тесты и коммиты. Такой порядок подходит и для переноса между инструментами (источник: Хабр, «Как работать с Claude Code, Antigravity и Codex в 2026: база вайбкодинга»).
Для дополнительного разбора изменений можно поручить другому агенту ревью. Схема «Claude Code пишет, Codex проверяет» помогает разделить роли. Но замечания второго агента тоже нужно сверять с задачей, а работоспособность сайта подтверждать тестами и проверкой в браузере.
Типичные ошибки при переносе проекта
- Переносить всю переписку без разбора. Вместе с решениями новый агент получит отвергнутые варианты; лучше оставить краткое описание актуального состояния.
- Хранить разные версии одних правил в нескольких файлах. При каждом изменении сверяйте их или вынесите общую часть в отдельный документ.
- Считать настройки подключений частью текстовой инструкции. Доступность инструментов проверяйте отдельно перед первой задачей.
- Сразу поручать переделку всего сайта. Начните с ограниченной правки, для которой легко проверить результат и выполнить откат.
- Принимать фразу «всё работает» без отчёта. Попросите назвать команды проверок, их результаты и действия, которые агент не выполнил.
Начните перенос с рабочей копии проекта и короткого описания текущей задачи. Затем подготовьте файл инструкций для нового агента и проверьте его понимание без правок. Когда первая небольшая задача пройдёт проверку, сохраните результат в Git: у вас останутся и рабочая версия сайта, и понятный порядок продолжения работы.
