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

На первом запуске Claude Code просит подтвердить доверие к рабочему каталогу, и это не формальность. Project settings, project MCP, agent hooks и другие исполняемые кастомизации могут прийти из клонированного репозитория - то есть быть написаны кем-то другим. Пока workspace не доверен, Claude Code намеренно игнорирует часть project-approvals и hooks. Доверие здесь - осознанное решение допустить исполняемую конфигурацию репозитория, а не кнопка "ок" на пути к работе.

Сразу после входа полезно выполнить диагностический минимум и прочитать, что реально загрузилось. Команды /status, /context и /permissions показывают текущий каталог и корень репозитория, модель и provider, загруженные user-, project- и local-источники настроек, memory-файлы, активный permission mode и уже существующие MCP-серверы и плагины. Это снимок среды: пока вы его не увидели, вы не знаете, в каких условиях работает агент, и любая неожиданность потом будет стоить дороже.

Стартовый CLAUDE.md удобно создать командой /init, но относиться к нему надо как к заготовке, а не к источнику истины. /init исследует проект и предлагает первый CLAUDE.md, а если файл уже есть - предлагает улучшения, а не молча перезаписывает. Из заготовки убирают очевидное, что Claude и так видит в package.json, и добавляют то, что нельзя надёжно угадать по коду: команды проверки, границы ("не менять миграции без подтверждения") и определение готовности.

Полезно один раз увидеть, каким должен быть осмысленный CLAUDE.md - контракт проекта, а не пересказ структуры. Ниже - компактный пример с командами, границами и определением готовности. К этой форме возвращаются, наполняя память проекта: она держит инструкции короткими и проверяемыми, называет то, что агент не выведет сам, и задаёт критерий, по которому задача считается выполненной.

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