Есть класс задач, которые не хочется выполнять прямо в рабочем разговоре: «разберись, как устроен модуль оплаты», «найди все места, где мы обращаемся к внешнему 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 происходит следующее:
- Создаётся новый изолированный контекст.
- Подагент получает содержимое скилла как промпт — с уже подставленным
$ARGUMENTS. - Поле
agentопределяет окружение выполнения: модель, инструменты, разрешения. - Подагент подводит итог и возвращает его в основной разговор.
Ключевой момент, который стоит усвоить прочно: подагент не имеет доступа к истории вашего разговора. Он видит ровно то, что написано в скилле. Всё, что вы обсуждали десять сообщений назад, для него не существует — если это важно, передайте это аргументами или пропишите в теле скилла. Обратно приходит только итог, а не десятки файлов, которые он прочитал по дороге.
Поле 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, различаете фоновый и синхронный режимы и, главное, умеете отличить скилл, который стоит форкнуть, от справочника, который форк только сломает.
Подагент здесь появился как механизм — минимально, ровно чтобы объяснить изоляцию. В следующей главе он станет самостоятельной темой: вы научитесь описывать собственные типы агентов, задавать им инструменты и разбираться, когда делегирование действительно окупается. Пока же попробуйте форкнуть один свой исследовательский скилл и сравните, что осталось в контексте.