$ sudo teach IT

Есть класс задач, которые не хочется выполнять прямо в рабочем разговоре: «разберись, как устроен модуль оплаты», «найди все места, где мы обращаемся к внешнему API», «собери обзор по этой части кодовой базы». Такая задача требует прочитать десятки файлов и прогнать серию поисков. Всё это осядет в вашем контексте — а вам от неё нужен только вывод на пятнадцать строк.

После этого урока вы сможете вынести такой скилл в отдельный изолированный контекст одной строкой во frontmatter, получать в разговор только итог и осознанно выбирать, ждать результат сразу или отпустить работу в фон.

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

Вы уже пишете скиллы: знаете, что тело SKILL.md попадает в разговор при вызове и остаётся там на последующих ходах, умеете подставлять аргументы и подмешивать вывод команд. Из главы 4 вы помните главное правило: контекст — конечный ресурс, и всё, что в него попало, вы оплачиваете на каждом ходе.

Теперь добавим поля context, agent и background. Они меняют не то, что делает скилл, а то, где он выполняется.

Здесь впервые появляется слово «подагент». Пока достаточно минимального определения: это отдельный исполнитель со своим чистым контекстом, который получает задачу, делает её и возвращает результат. Подробно подагенты — их типы, файлы в .claude/agents/, стратегии делегирования — разбираются в следующей главе.

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

  • Почему объёмный скилл, выполненный в разговоре, дорого обходится контексту
  • Как context: fork изолирует выполнение и что именно возвращается назад
  • Что задаёт поле agent и почему Explore и Plan экономнее остальных
  • Как работает фоновый режим и когда нужен background: false
  • Какие скиллы форкать нельзя и почему

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

  • Подагент — отдельный исполнитель со своим чистым контекстом: получает задачу, выполняет её и возвращает итог в основной разговор.
  • Форкнутый контекст — новый изолированный контекст, созданный под выполнение скилла. Не содержит истории вашего разговора.
  • context: fork — поле frontmatter, запускающее скилл в форкнутом контексте подагента.
  • agent — тип подагента при context: fork: Explore, Plan, general-purpose или свой из .claude/agents/.
  • background — режим ожидания форкнутого скилла: true (по умолчанию) — работа идёт в фоне, false — результат ждут в том же ходе.

Что происходит без изоляции

Возьмём обычный исследовательский скилл.

---
name: deep-research
description: Research a topic thoroughly
---

Research $ARGUMENTS thoroughly:

1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

Вызов /deep-research payment flow выполняется прямо в вашем разговоре. Тело скилла добавляется в контекст одним сообщением и остаётся там дальше. Но дороже другое: вся промежуточная работа — результаты Glob, вывод Grep, содержимое двадцати прочитанных файлов — тоже становится частью разговора. Вы получите нужную сводку, но заплатите за неё окном, в котором до этого спокойно велась ваша основная задача.

Как работает context: fork

Добавляем одну строку — и поведение меняется принципиально.

---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---

Research $ARGUMENTS thoroughly:

1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

Это пример из документации, и он показателен: тело осталось прежним, добавились два поля. При вызове /deep-research payment flow происходит следующее:

  1. Создаётся новый изолированный контекст.
  2. Подагент получает содержимое скилла как промпт — с уже подставленным $ARGUMENTS.
  3. Поле agent определяет окружение выполнения: модель, инструменты, разрешения.
  4. Подагент подводит итог и возвращает его в основной разговор.

Ключевой момент, который стоит усвоить прочно: подагент не имеет доступа к истории вашего разговора. Он видит ровно то, что написано в скилле. Всё, что вы обсуждали десять сообщений назад, для него не существует — если это важно, передайте это аргументами или пропишите в теле скилла. Обратно приходит только итог, а не десятки файлов, которые он прочитал по дороге.

Поле agent: кто выполняет работу

Если поле не указано, используется general-purpose. Встроенные варианты — Explore, Plan, general-purpose; можно указать и свой тип из .claude/agents/.

Есть важная деталь. При context: fork в контекст подагента дополнительно загружается CLAUDE.md — но не всегда: агенты Explore и Plan пропускают и CLAUDE.md, и git status, чтобы контекст был меньше. Для исследовательской задачи это ровно то, что нужно: Explore стартует налегке. А если скилл пишет код и должен соблюдать конвенции проекта, general-purpose с подгруженным CLAUDE.md подходит лучше.

Поле model при context: fork тоже работает — оно задаёт модель форкнутого исполнителя, а не вашей основной сессии.

Фон и background: false

Поле background действует только вместе с context: fork. По умолчанию оно true: форк уходит в фон, вы продолжаете работать, результат приходит в разговор, когда исполнитель закончит. Поле требует Claude Code v2.1.218 и новее.

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

---
name: audit-deps
description: Audit dependencies for outdated versions
context: fork
agent: general-purpose
background: false
---

Есть ситуации, когда Claude Code ждёт результат сам, даже без background: false: неинтерактивный режим (-p или Agent SDK); переменная CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1; вызов форкнутого скилла, пока предыдущий его запуск ещё идёт; запуск по расписанию.

Два последствия фонового режима надо держать в голове. Первое: фоновый форк работает с более узким набором инструментов, чем обычный ход. Если шаги скилла зависят от инструмента вне этого набора, ставьте background: false. Второе: правки, сделанные фоновым форкнутым скиллом, применяются вне чекпоинтов сессии — /rewind их не откатит. Откатывать придётся через git.

Когда форкать не надо

Документация даёт прямое предупреждение: context: fork имеет смысл только для скиллов с явной задачей.

Представьте скилл-справочник: «в этом проекте используем такие-то соглашения по именованию, такой-то стиль коммитов». В обычном режиме это работает — рекомендации ложатся в разговор и влияют на дальнейшую работу. Форкните его — и подагент получит набор рекомендаций без выполнимого промпта. Он не поймёт, что делать, и вернётся без осмысленного результата.

Отсюда простое правило выбора: справочный скилл — inline, скилл-процедура с чёткой задачей — можно fork. Проверка: если тело скилла можно прочесть как поручение исполнителю, который ничего о вас не знает, — форк уместен.

Пара мелочей напоследок. Встроенный /code-review работает как форкнутый подагент. И ещё: форкнутый скилл прерывает «стакание» скиллов в одном сообщении — несколько скиллов подряд в одной строке с форком не сложатся.

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

  • background: false без context: fork. Поле действует только в паре с форком. Само по себе оно не даст ничего: скилл выполнится обычным образом, а строка во frontmatter останется бесполезной.
  • Форк скилла-справочника. Набор рекомендаций без задачи оставляет подагента без выполнимого промпта, и он возвращается ни с чем. Форкайте только процедуры с явной постановкой задачи.
  • Расчёт на контекст разговора. «Проанализируй тот файл, что мы обсуждали» в форкнутом скилле не сработает: истории разговора у подагента нет. Передавайте всё нужное аргументами или прямо в теле.
  • Попытка откатить фоновую правку через /rewind. Изменения фонового форка лежат вне чекпоинтов сессии. Планируйте откат через git.

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

  • Что именно возвращается в разговор? — Только итог, подведённый подагентом. Промежуточные чтения файлов и выводы команд остаются в изолированном контексте.
  • Видит ли подагент мою историю разговора? — Нет. Он получает содержимое скилла как промпт и ничего кроме.
  • Какое значение background по умолчанию? — true, то есть фон. Явно писать его нужно только чтобы получить false.
  • Загружается ли CLAUDE.md в форке? — Да, дополнительно загружается — кроме случаев с агентами Explore и Plan: они пропускают и CLAUDE.md, и git status.
  • Что будет, если не указать agent? — Возьмётся general-purpose.

Итоги

Вы освоили приём, который заметно меняет экономику работы: объёмная задача уходит в отдельный контекст, а к вам возвращается только результат. Теперь вы понимаете, что context: fork создаёт изолированного исполнителя без доступа к вашей истории, знаете роль поля agent и особенность Explore и Plan, различаете фоновый и синхронный режимы и, главное, умеете отличить скилл, который стоит форкнуть, от справочника, который форк только сломает.

Подагент здесь появился как механизм — минимально, ровно чтобы объяснить изоляцию. В следующей главе он станет самостоятельной темой: вы научитесь описывать собственные типы агентов, задавать им инструменты и разбираться, когда делегирование действительно окупается. Пока же попробуйте форкнуть один свой исследовательский скилл и сравните, что осталось в контексте.

На следующий урок