К этому моменту у вас в руках несколько инструментов, которые внешне решают одну и ту же задачу: научить Claude делать что-то повторяющееся. Правило в CLAUDE.md, скилл, скилл с context: fork, свой подагент, форк через /subtask, отдельная фоновая сессия. Выбор неочевиден, и типичный итог — либо всё подряд оформляется скиллами, либо на каждую мелочь заводится подагент.

Цена ошибки реальная. Инструкция, засунутая в CLAUDE.md вместо скилла, висит в контексте каждой сессии и жрёт токены, даже когда не нужна. Задача, отданная подагенту вместо главной беседы, теряет половину смысла, потому что подагент не видел вашего разговора. Отдельная сессия, заведённая там, где хватило бы подагента, требует ручного присмотра. После этого урока у вас будет работающий алгоритм выбора.

Что уже умеем / что добавим

Вы прошли большой путь: CLAUDE.md и правила, скиллы с их frontmatter и context: fork, подагенты со своими инструментами и моделями, форки, параллельный запуск и изоляцию через worktree. Каждый инструмент разобран по отдельности.

Теперь мы соберём картину целиком. Добавим не новую механику, а критерии выбора: по какому признаку отличать случаи и как комбинировать инструменты, когда одного не хватает.

Что вы узнаете в рамках статьи

• Чем скилл принципиально отличается от подагента
• Как связаны скиллы и подагенты в обе стороны
• Когда задачу пора выносить в отдельную сессию
• Алгоритм выбора по трём вопросам
• Как комбинировать инструменты в одном рабочем процессе

Ключевые термины

• Скилл — набор инструкций, загружаемый по требованию; отвечает на вопрос «как делать».
• Подагент — отдельный исполнитель со своим контекстом, промптом и правами; отвечает на вопрос «кто делает».
• Отдельная сессия — самостоятельная беседа со своей историей, живущая независимо от текущей.
• context: fork — поле скилла, отправляющее его на выполнение в отдельный контекст подагента.
• Поле skills — поле подагента, подгружающее содержимое перечисленных скиллов в его стартовый контекст.

Скилл против подагента: разные вопросы

Главная развилка проходит здесь, и формулируется она коротко.

Скилл — это инструкция. Он отвечает на вопрос «как делать» и выполняется тем же агентом, который уже с вами разговаривает. Контекст общий, история беседы на месте, ничего не изолируется.

Подагент — это исполнитель. Он отвечает на вопрос «кто делает»: у него свой контекст, свой системный промпт, свой набор инструментов и своя модель.

Отсюда практический критерий: если вам нужна изоляция контекста или ограничение прав — это подагент. Если нужно просто зафиксировать порядок действий — это скилл.

# Скилл: как оформлять коммиты. Изоляция не нужна,
# работа идёт в вашей беседе с вашим контекстом
---
name: commit
description: Создаёт коммит по принятому в команде формату сообщений
---

Соберите изменения, составьте сообщение в формате
<тип>(<область>): <описание> и создайте коммит.

# Подагент: кто ревьюит. Нужна изоляция и запрет на правки
---
name: code-reviewer
description: Проверяет изменения перед коммитом и возвращает список замечаний
tools: Read, Grep, Glob, Bash(git diff:*)
---

Есть и промежуточный случай — скилл с context: fork. Это скилл, выполняющийся в отдельном контексте подагента: содержимое скилла становится задачей, а поле agent выбирает исполнителя. Берите его, когда процедура одна, но её вывод шумный и в главной беседе не нужен.

---
name: deep-research
description: Тщательно исследует заданную тему по коду проекта
context: fork
agent: Explore
---

Исследуйте $ARGUMENTS: найдите файлы, прочитайте код,
верните сводку со ссылками на конкретные места.

Обратите внимание на важную оговорку из документации: context: fork имеет смысл только для скиллов с явной задачей. Если скилл содержит одни рекомендации вроде «соблюдайте такие-то соглашения», подагент получит их без задачи и вернётся ни с чем.

Как они соединяются

Скиллы и подагенты работают вместе в обе стороны, и это стоит держать в голове как две симметричные схемы.

Первое направление — скилл с context: fork выбирает исполнителя. Системный промпт берётся от типа агента, задачей становится содержимое скилла. CLAUDE.md загружается, кроме случаев, когда агентом выбраны Explore или Plan.

Второе направление — подагент подключает скиллы полем skills. Здесь системный промпт берётся из тела файла агента, задачей становится делегирующее сообщение от Claude, а скиллы подгружаются как справочный материал вместе с CLAUDE.md.

---
name: api-developer
description: Реализует эндпоинты API по принятым в команде соглашениям
skills:
  - api-conventions
  - error-handling-patterns
---

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

Разница по сути такая: в первом случае вы пишете задачу и выбираете исполнителя, во втором — описываете исполнителя и даёте ему справочники.

Когда нужна отдельная сессия

Подагент возвращает результат и исчезает. Отдельная сессия живёт своей жизнью, и это качественно другое.

Заводите отдельную сессию, когда работа долгая и самостоятельная: рефакторинг на несколько часов, разбор большого пласта legacy-кода, долгая отладка. Или когда задача параллельна вашей основной и не должна её прерывать. Или когда результат придётся смотреть и обсуждать, а не просто прочитать сводку.

claude --bg --name "legacy-migration" \
  "перенеси модуль отчётов со старого API на новый, по шагам, с тестами"

Такая сессия работает в фоне, получает свой worktree и ждёт, когда вы к ней подключитесь.

Не заводите отдельную сессию для того, что укладывается в один заход и возвращает готовый ответ. Подагент справится дешевле и без ручного присмотра.

Алгоритм выбора

Три вопроса по порядку.

Нужен ли изолированный контекст? Если задача даёт много вывода, который вам не нужен, — да, берите подагента или скилл с context: fork. Если нет — обходитесь скиллом или главной беседой.

Нужны ли особые права? Если нужно физически запретить агенту что-то делать или, наоборот, дать особый режим разрешений — только подагент. У скилла есть allowed-tools, но это про предварительное одобрение инструментов, а не про урезание набора.

Живёт ли работа дольше одного ответа? Если результат — сводка, хватит подагента. Если предстоит длинная работа с промежуточными решениями и вашим участием — отдельная сессия.

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

Частые ошибки

• Заводить подагента ради процедуры без изоляции. Если задача не производит шумного вывода и не требует ограничения прав, скилл проще, дешевле и не теряет контекст беседы.
• Держать длинные процедуры в CLAUDE.md. Этот файл грузится в каждую сессию целиком. Тело скилла подгружается только при использовании — длинные инструкции им и место.
• Ставить context: fork скиллу без задачи. Скилл с одними рекомендациями превращается в подагента без поручения и возвращается ни с чем.
• Открывать отдельную сессию для задачи в один заход. Сессия требует внимания и присмотра. Если ожидается готовая сводка — это работа для подагента.

Наиболее частые вопросы

• Скилл или подагент, если я просто хочу зафиксировать порядок действий? — Скилл. Подагент нужен, когда требуется изоляция контекста или ограничение прав.
• Можно ли использовать скиллы и подагентов вместе? — Да, в обе стороны: скилл с context: fork выбирает исполнителя, подагент подключает скиллы полем skills.
• Когда правило должно жить в CLAUDE.md, а не в скилле? — Когда это короткий постоянный факт о проекте. Выросшую до процедуры инструкцию выносят в скилл.
• Чем отличается allowed-tools скилла от tools подагента? — Первое даёт предварительное одобрение инструментов на время вызова, второе задаёт сам набор доступных агенту инструментов.
• Что выбрать для многочасового рефакторинга? — Отдельную фоновую сессию: работа длинная, требует промежуточных решений и вашего участия.

Итоги

Поздравляем — вы завершили одну из самых насыщенных глав курса. Вы прошли от первого делегирования встроенному Explore до собственных подагентов с настроенными правами, форков, параллельных запусков и изоляции через worktree. А теперь у вас есть и то, чего не даёт знание отдельных механизмов, — критерии выбора между ними. Изоляция, права, длительность: три вопроса, которые ставят задачу на своё место.

Это тот навык, который отличает уверенную работу с инструментом от коллекционирования его возможностей. Дальше мы перейдём к хукам — механизму, который позволяет гарантировать выполнение проверок, а не просить о них. Если подагенты дают вам разделение труда, то хуки дадут гарантии: например, что линтер отработает после каждой правки независимо от того, вспомнил о нём агент или нет.