Терминальные агенты: настройка под себя — правила, скиллы, хуки, сабагенты

По умолчанию агент ничего не знает про конвенции конкретного проекта: какой стек используется, как называть файлы, какой линтер запускать перед коммитом. Объяснять это заново в каждой сессии не нужно. Почти все терминальные агенты умеют один раз прочитать специальный файл-инструкцию прямо из папки проекта и дальше держать его в виду всю работу. У Claude Code это файл CLAUDE.md в корне проекта; если его нет, он подхватит и чужой AGENTS.md. У Codex это AGENTS.md, у Gemini CLI — GEMINI.md, у Cursor — правила в папке .cursor/rules. По сути это один и тот же принцип под разными названиями. Тема «AI-first дизайн-системы» подробно разбирает такой файл на примере готовой дизайн-системы Astryx. Здесь — как завести свой с нуля, даже без готовой системы.

Файл — обычный markdown-текст. Попроси агента сгенерировать его самостоятельно, а потом донастрой руками:

Создай файл CLAUDE.md для этого проекта: опиши стек, структуру папок, конвенции именования компонентов, и явные правила «нельзя» — не писать инлайн-стили, не хардкодить цвета вместо токенов

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

Следующий уровень — skills: отдельные инструкции под конкретную повторяющуюся задачу («как у нас оформляется коммит-сообщение», «как проверять доступность перед сдачей»). CLAUDE.md агент держит в контексте всегда, а скилл подгружается, только когда понадобился. Агент сам понимает это по короткому описанию в его шапке, либо ты вызываешь его явно. Получается библиотека процедур команды, которую можно копить со временем, вместо того чтобы раздувать общий CLAUDE.md до бесконечности. У Claude Code скилл — это папка .claude/skills/<имя>/ с файлом SKILL.md. Рядом можно положить шаблоны, примеры и скрипты.

Есть ещё один способ не объяснять задачу заново каждый раз: отдельная личная команда вместо системного файла на весь проект. Любой скилл из раздела выше можно вызвать вручную, по имени его папки с косой чертой. Скилл в .claude/skills/handoff/SKILL.md запускается командой /handoff. Раньше для этого существовал отдельный механизм: markdown-файлы в папке .claude/commands/. Он по-прежнему работает, и в старых проектах и гайдах встретится именно он. Но команды и скиллы теперь объединены, и для нового сразу заводи скилл. Дальше та же задача вызывается одним словом, без повторного набора всего промпта:

/weekly-report

Команда может принимать аргумент через $ARGUMENTS. Всё, что написано после имени команды, подставляется в текст промпта вместо этой переменной:

/client-brief Студия «Заря»

Имена папок скиллов пиши латиницей: в документации все примеры такие, а с кириллицей вызов может не сработать.

Команды можно хранить прямо в проекте, в .claude/skills/. Тогда, если передать проект коллеге, они заработают у него без дополнительной настройки. Личные команды для всех твоих проектов живут в ~/.claude/skills/. Там же, в домашней папке, лежат личные настройки ~/.claude/settings.json и сабагенты ~/.claude/agents/. Промпт внутри файла — обычный текст без специального синтаксиса. Поменять поведение команды так же просто, как отредактировать этот файл. Пример для дизайнера, сохрани как .claude/skills/handoff/SKILL.md. Шапка с description в начале файла подсказывает агенту, когда вызывать скилл без явной команды:

---
name: handoff
description: Собирает handoff-документ для разработчика по текущему состоянию проекта
---
Собери handoff-документ для разработчика по текущему состоянию проекта: список компонентов с их состояниями (default/hover/error/empty), использованные токены отступов и цвета, и список того, что ещё не реализовано. Сохрани в файл handoff.md

Ещё один уровень настройки поверх CLAUDE.md и скиллов — hooks. Это небольшие скрипты, которые запускаются автоматически на конкретное событие в работе агента, а не по явной команде пользователя. Настраиваются в файле .claude/settings.json внутри проекта. Событий много, для начала достаточно знать четыре. PreToolUse: перед тем, как агент выполнит действие, и его можно заблокировать. PostToolUse: сразу после действия, можно проверить результат. Notification: когда агенту самому нужно что-то от человека, можно прислать системное уведомление, чтобы не проверять терминал каждые пять минут. Stop: агент собирается закончить работу, и можно не дать ему это сделать, пока, например, не пройдут тесты.

Самый практичный пример для дизайнера, который только начинает доверять агенту автономный режим, — хук безопасности. Скрипт получает текст каждой команды перед её выполнением. Если находит в ней явно опасные паттерны (rm -rf, sudo, chmod 777), останавливает действие и объясняет причину. Внимательность из темы «Безопасность вайбкодинг-проекта» он не заменяет. Это дополнительный барьер, который срабатывает и тогда, когда человек в этот момент отвлёкся от экрана.

Настраивать хуки с нуля без опыта в скриптах не обязательно. Попроси агента написать хук самостоятельно:

Настрой hook, который перед выполнением любой команды в терминале проверяет её на rm -rf, sudo и chmod 777 и блокирует выполнение с объяснением причины, если находит такой паттерн

Один агент в одном терминале — не единственный сценарий работы. Когда проект вырастает, полезно знать, что агентов можно запускать несколько одновременно. Делать это лучше осознанно, чтобы они случайно не путали один и тот же файл.

Параллельно, на независимых частях задачи. Если фронтенд и бэкенд (или два разных экрана) не зависят друг от друга, открой два терминала и запусти в каждом свою сессию агента над отдельной задачей. Они не будут мешать друг другу, пока не трогают одни и те же файлы. Чтобы физически не столкнуться на одной ветке, у Claude Code есть встроенная поддержка git worktree. Это отдельная рабочая копия того же репозитория в другой папке, привязанная к своей git-ветке. Два агента буквально работают в разных папках на диске и потом сливаются в основную ветку по отдельности. Так они не редактируют одни и те же файлы одновременно и не путаются в изменениях друг друга.

Последовательно, как конвейер ролей. Другой паттерн: один агент проверяет за другим. Например, один прогон агента пишет фичу, а второй, отдельной сессией с чистым контекстом, проверяет тот же код на баги и несостыковки со спецификацией. Он работает как независимый ревьюер, а не как тот же собеседник, который подсознательно защищает собственное решение. У Claude Code для этого есть встроенный механизм сабагентов (subagents). Это вспомогательные агентные сессии с собственным контекстом и узкой ролью («ревьюер», «тестировщик»). Основной агент вызывает их сам по ходу работы, и расписывать эту логику вручную в каждом промпте не нужно.

Сильнее всего этот приём работает с ролью-персонажем, которому явно запрещено сглаживать несостыковки, а не с ролью-функцией («тестировщик»). Сабагент с ролью «скептичный арт-директор» получает инструкцию конкретнее, чем «покритикуй». Если данные или аргументация противоречат друг другу, он не выбирает удобную версию за автора, а явно выносит это противоречие в отдельный список вопросов. Для ревью макета или брифа можно завести сразу несколько таких персонажей параллельно, каждый со своей узкой оптикой:

Заведи три сабагента для ревью макета ./mockups/checkout.png (или фрейма по ссылке через Figma MCP): «адвокат доступности» (ищет проблемы с контрастом, размером тапа, навигацией с клавиатуры), «сторонник экономии бюджета» (отмечает всё, что требует кастомной разработки вместо готовых компонентов), «бренд-пурист» (сверяет с брендбуком). Каждый должен явно называть, если ему не хватает данных для оценки, а не додумывать. Собери их выводы в один список, а расхождения между сабагентами вынеси отдельно, не разрешая их за них

Это тот же одиночный приём «придирчивый арт-директор» из темы «Оценка и критика результатов ИИ», только сразу в несколько параллельных, узко сфокусированных голосов вместо одного универсального критика.

Если у тебя пока немного опыта в вайбкодинге, многоагентные сценарии — продвинутый приём, и начинать с него не нужно. Пока не появилось ощущение, что один агент в одном терминале стал узким местом, параллельные потоки скорее запутают, чем ускорят. Ещё дальше по той же линии — экспериментальная функция Agent Teams. Там несколько сессий Claude Code работают как команда: ведущая сессия раздаёт задачи, а участники общаются друг с другом напрямую и сами берут задачи из общего списка, а не только отчитываются наверх. Чтобы они не перезаписывали друг друга, работу делят так, чтобы у каждого был свой набор файлов. Функция экспериментальная, включается переменной CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, и начинать с неё тоже не нужно. Но полезно знать, куда идёт развитие этой темы.

Изучи проект и создай CLAUDE.md не длиннее одного экрана: стек, структура папок, конвенции именования и явные „нельзя“. Всё, что и так очевидно из кода, не пиши

Я уже в третий раз объясняю тебе, как у нас оформляется handoff для разработчика. Оформи это как скилл в .claude/skills/handoff: когда применять, шаги, формат результата. Покажи файл перед сохранением

Настрой хук, который перед выполнением любой команды в терминале проверяет её на rm -rf, sudo и chmod 777 и блокирует выполнение с объяснением причины

Заведи сабагента-ревьюера с правами только на чтение: после каждой крупной правки он сверяет результат с CLAUDE.md и возвращает список нарушений, ничего не исправляя

Объясни простыми словами разницу между CLAUDE.md, скиллом, хуком и сабагентом — на примере дизайнера, который ведёт один лендинг и один небольшой продукт. Что из этого мне нужно в первую очередь?