sub-agents

Навык sub-agents описывает контролируемую передачу отдельной задачи внешнему CLI-агенту. Он применяется, когда пользователь называет определённого агента, ссылается на существующее определение или явно делегирует работу. В центре workflow находится скрипт run_subagent.py: он получает выбранное определение, передаёт ему prompt и рабочий каталог, запускает указанный backend и возвращает структурированный JSON-результат. Это не общий совет «запустить ещё одну модель», а конкретный маршрут для репозитория, в котором уже есть описания агентов и доступные CLI. Перед выполнением навык требует сначала перечислить доступные определения командой с флагом --list. В ответе ожидаются имена, краткие описания и каталог definitions. Если определений нет, workflow не пытается угадать имя: нужно добавить файл определения в .agents и заполнить его frontmatter. Если вариантов несколько, пользователь выбирает нужный; автоматическое решение по одному только похожему названию не является частью описанного процесса. Такой шаг отделяет наличие агента от возможности его технического запуска. Параметры выполнения берутся из запроса и контекста. --agent задаёт имя определения, --prompt содержит только рабочую инструкцию без повторения выбора агента, а --cwd указывает абсолютный рабочий каталог. Backend можно переопределить через --cli, но только когда это явно требуется; --timeout передаётся в миллисекундах, если пользователь задал ограничение, иначе используется значение по умолчанию скрипта. Навык перечисляет поддерживаемые варианты CLI: codex, claude, cursor-agent, glm, kimi, grok, gemini и opencode. Наличие названия в списке не означает, что соответствующий бинарник, авторизация или модель настроены на конкретной машине. Перед первым запуском источник отдельно требует учесть разрешения и время ожидания: внешние CLI могут нуждаться в повышенных разрешениях, а timeout инструмента должен соответствовать timeout, переданному скрипту. Для Codex предусмотрена отдельная справка references/codex.md, которую нужно прочитать до первого вызова. Это особенно важно для делегированной команды с доступом к файлам или shell: права не следует расширять молча, а истечение времени не следует интерпретировать как успешное выполнение. Результат читается по полю status. success означает завершённую задачу и позволяет использовать result. partial говорит о timeout при наличии неполного вывода и требует оценить, достаточно ли его или нужен повторный запуск. error означает ошибку; дополнительно проверяются error и exit_code. В частности, exit code 124 указывает на timeout, 127 — на отсутствие CLI, а конфигурационная или credential-ошибка устраняется изменением окружения, а не переписыванием prompt. Такой контракт сохраняет различие между ответом агента и проблемой инфраструктуры. Файл определения живёт в каталоге .agents либо в каталоге, заданном SUB_AGENTS_DIR. В frontmatter указываются backend run-agent, при необходимости model и effort, а также permission: read-only, safe-edit или yolo. Skill не обещает, что любой backend безопасен или доступен, не выбирает агента вместо пользователя при неоднозначности и не заменяет проверку полученного результата. После успешного делегирования остаются обычные проверки файлов, тестов, секретов и соответствия исходной задаче; JSON с exit code равным нулю сам по себе не доказывает корректность изменения.