Кодовый агент в терминале выглядит как чат: написал задачу, получил правки в файлах. Первую неделю так и работают — и упираются в одно и то же. Сессия распухает и агент начинает забывать начало. Одни и те же правила проекта приходится повторять каждый раз заново. Агент лезет в файл, который трогать не просили.
Всё это чинится десятком команд. Ниже — тот набор, который реально нужен в первую неделю, на примере Claude Code. У других агентов набор похожий, а привычки переносятся целиком.
Запуск и возврат к прошлому разговору
Агент запускается из каталога проекта, и каталог для него важнее всего остального: он определяет, какие файлы агент видит и какие правила проекта прочитает.
claude
claude "добавь отмену заказа, тест на неё уже есть"
Первая строка открывает разговор, вторая сразу отдаёт задачу. Разницы между ними нет никакой, кроме экономии одного нажатия.
Дальше начинается то, о чём не догадываются: разговор не обязан быть одноразовым. Закрыли терминал, вернулись через час — история на месте.
claude -c
claude -r
claude -n отмена-заказа
-c продолжает последний разговор в этом каталоге, -r показывает список прошлых и даёт выбрать. Второе полезнее, чем кажется: у задачи, растянутой на два дня, весь контекст уже собран, и возвращаться в него дешевле, чем пересказывать заново. Третья строка даёт разговору имя сразу при запуске, и через неделю в списке видно, что это было, а не «вчера в 14:20».
Файл, вывод команды и картинка
Пересказывать агенту содержимое файла своими словами — самая частая потеря времени новичка. Файл передают ссылкой:
Объясни, что делает @src/main/java/ru/example/OrderService.java
Символ @ открывает подсказку по файлам проекта, и выбранный файл агент прочитает целиком перед ответом. Так же передают каталог — тогда агент посмотрит, что в нём лежит.
Вывод упавшей команды не пересказывают, а вставляют. Прямо в реплику, целиком, вместе со стектрейсом: агент ищет в нём то, на что человек не смотрит. Если команду удобнее запустить самому, её вывод можно отдать сразу на вход:
./gradlew test | claude -p "почему падает этот тест?"
Картинку вставляют из буфера. Скриншот сломанной вёрстки, фотография доски с архитектурой, кусок диаграммы — агент их читает.
Контекст кончился: три команды
Окно контекста конечно, и длинный разговор его съедает: файлы, которые агент прочитал, его собственные ответы, вывод команд. Когда место кончается, качество падает раньше, чем появляется сообщение об ошибке: агент начинает терять то, о чём договорились в начале.
Посмотреть, сколько занято, можно в любой момент:
/context
Дальше два разных инструмента, и путать их не стоит.
/compact
/clear
/compact сжимает историю: агент пересказывает сам себе, о чём был разговор, и продолжает с этим пересказом вместо полной переписки. Задача остаётся, детали частично теряются. Это то, что делают посреди длинной задачи.
/clear начинает разговор с нуля в том же каталоге. Ничего не переносится. Это то, что делают между задачами, и делают недостаточно часто: разговор, в котором сначала чинили тест, потом спросили про деплой, а потом вернулись к тесту, работает заметно хуже двух отдельных.
Правило простое: новая задача — новый разговор.
Рядом живёт /diff: она показывает, что агент уже наменял в рабочем дереве. Полезно перед тем, как соглашаться с очередным «готово»: список изменённых файлов почти всегда шире, чем ожидаешь.
CLAUDE.md: правила, которые не надо повторять
«Мы не пишем комментарии в коде», «тесты кладём вот сюда», «сборка запускается вот так» — всё это агент не угадает и будет нарушать раз за разом, пока вы не устанете поправлять. Написанное в файле правил он читает сам, в начале каждого разговора.
Файл называется CLAUDE.md и лежит в корне репозитория. Рядом с кодом, в git, общий для команды. Завести его можно руками или командой:
/init
Она пройдёт по проекту и предложит черновик: стек, как собирать, как запускать тесты. Черновик обязательно надо прочитать и урезать.
Что туда кладут:
- соглашения, которые ничем не проверяются — именование, границы слоёв, что можно и чего нельзя;
- как собрать и как проверить — команда сборки, команда тестов, команда линтера;
- чего не делать — «не трогай сгенерированные файлы», «миграции не правим, добавляем новые».
Личные привычки, не относящиеся к проекту, держат отдельно — в ~/.claude/CLAUDE.md. Он действует во всех проектах и в git не попадает. Разделение простое: в репозитории то, что верно для всей команды, у себя — то, что верно для вас.
Главная ошибка с этим файлом — раздуть его. Двести строк правил не работают: они съедают контекст и теряются в собственном шуме. Работающий файл короткий, и из него регулярно выбрасывают то, что агент и так делает правильно.
Что агент делает без спроса
Агент умеет не только писать файлы, но и запускать команды. Поэтому у него есть режим разрешений: что проходит само, что спрашивают, что запрещено совсем.
Переключается режим прямо в разговоре, по Shift+Tab, и текущий всегда виден строкой над полем ввода: plan mode on, auto mode on и так далее. Тот же набор задаётся флагом при запуске, claude --permission-mode plan:
| Режим | Что делает |
|---|---|
default | спрашивает перед каждой правкой файла и каждой командой |
plan | только читает и предлагает план, ничего не меняет |
acceptEdits | правит файлы сам, на команды спрашивает |
auto | решает сам, опасное блокирует и спрашивает |
dontAsk | выполняет только то, что разрешено заранее |
bypassPermissions | не спрашивает ничего |
Двум крайним стоит уделить по фразе. plan — правильный режим для незнакомого кода и для задач, где цена ошибки выше цены лишней минуты: агент показывает намерения до того, как что-то тронет. bypassPermissions снимает все проверки разом, и единственное место, где он оправдан, — одноразовый контейнер, который не жалко.
Постоянные разрешения живут в настройках: одни команды разрешают навсегда, другие запрещают навсегда.
{
"permissions": {
"allow": ["Bash(./gradlew test)", "Bash(git status)"],
"deny": ["Bash(git push --force *)"]
}
}
Смысл списка запретов не в недоверии к агенту, а в том же, в чём смысл защиты от случайного rm -rf: ошибиться может кто угодно, а последствия у некоторых команд необратимые.
Скиллы, субагенты, MCP и хуки
Четыре слова, которые встречаются в документации и которые новичок путает между собой. Каждое решает свою задачу.
Скилл — процедура, записанная один раз и вызываемая по имени. «Разобрать аварию по шагам», «сделать ревью по нашему чек-листу». Лежит в .claude/skills/<имя>/SKILL.md, вызывается как /имя. Отличается от записи в файле правил тем, что правило действует всегда, а скилл срабатывает тогда, когда его позвали.
Субагент — отдельный агент со своим контекстом, которому отдают кусок работы. Нужен там, где работа требует прочитать много, а вам нужен только вывод: «разберись, как устроена авторизация» прочитает тридцать файлов и вернёт абзац, не засорив ваш разговор.
MCP — единый способ подключить агенту внешнюю систему: базу, трекер, документацию. Раньше под каждый инструмент писали свою обвязку, теперь протокол один.
claude mcp add --transport http трекер https://mcp.example.com/mcp
Хук — команда, которую агент запускает сам в заданный момент: после правки файла, перед запуском инструмента. Разница с правилом в файле важная: правило агент может забыть, хук выполняется всегда. Поэтому форматирование и линтер после правки — это хук, а не просьба в CLAUDE.md.
Глубже: разовый запуск и работа в конвейерерасширенное
Агент нужен не только в разговоре. Флаг -p делает из него обычную утилиту: получил вход, выдал ответ, вышел.
claude -p "одной строкой: что меняет этот диф" < diff.txt
git log --oneline -20 | claude -p "сгруппируй по темам"
В таком виде его ставят в конвейер сборки: черновик описания изменения, разбор упавшего прогона, проверка diff на забытые отладочные строки. Для машинной обработки ответ просят структурой, а не текстом:
claude -p "перечисли затронутые модули" --output-format json
Две оговорки. Разовый запуск не видит истории, поэтому весь нужный контекст кладут во вход. И у агента в конвейере должен быть жёсткий потолок шагов и узкие разрешения: то, что в разговоре поправит человек, в конвейере поправить некому.
Глубже: что идёт не так в первую неделюрасширенное
Один разговор на весь день. Начали с теста, отвлеклись на конфиг, вернулись к тесту. Контекст забит чужой задачей, агент путается. Лечится командой /clear между задачами.
Чинить по третьему кругу. Агент сделал не то, вы поправили, он сделал не то снова. После второй неудачной попытки добавлять третью поправку бессмысленно: проще начать разговор заново и сформулировать задачу с учётом того, что вы за эти две попытки поняли.
Просить без критерия проверки. «Сделай валидацию почты» — и дальше вы единственный, кто может понять, работает ли. «Сделай валидацию почты, напиши на неё тест, запусти и покажи зелёный прогон» — и агент проверяет себя сам. Разница в одном предложении, а в результате разница между «похоже на правду» и «работает».
Просить изучить всё. «Разберись в проекте» заканчивается тем, что агент прочитал сотню файлов и контекст кончился. Область сужают или отдают субагенту.
Коротко
- Каталог запуска определяет, что агент видит и какие правила прочитает;
claude -cпродолжает прошлый разговор,claude -rдаёт выбрать из списка. - Файл передают ссылкой
@путь, вывод команды вставляют целиком, картинку вставляют из буфера. /contextпоказывает, сколько места занято;/compactсжимает историю посреди задачи,/clearначинает новую задачу с чистого листа,/diffпоказывает, что агент уже наменял.CLAUDE.mdв корне репозитория агент читает сам в начале каждого разговора; личные привычки держат в~/.claude/CLAUDE.md, а раздутый файл правил не работает.- Режим переключается по
Shift+Tabи виден строкой над полем ввода;planдаёт посмотреть намерения до правок,bypassPermissionsснимает проверки и уместен только в одноразовом контейнере. - Правило агент может забыть, хук выполняется всегда: форматирование после правки вешают хуком.
- Флаг
-pпревращает агента в утилиту для конвейера, но там ему нужны потолок шагов и узкие разрешения. - Между задачами начинают новый разговор, а после второй неудачной попытки переписывают задачу, а не добавляют третью поправку.
Что почитать дальше
- Базовый цикл работы с агентом — как устроена продуктивная сессия, если смотреть не на команды, а на порядок работы.
- Настройка агентов под проект — четыре слоя настройки и границы прав, когда одного файла правил уже мало.
- День с агентом — три рабочих сценария целиком: разобраться в чужом коде, сделать функциональность, починить ошибку.
- Контекстное окно — почему место кончается и что именно его занимает.