Новый subagent или новый skill: что выбрать

У тебя есть кандидат {{candidate}}. Решение «subagent или skill» — самая частая ошибка в дизайне Claude Code систем. Subagent дороже, медленнее и сложнее, чем кажется. Skill дешевле, но не для всего.

1. Что это вообще

Skill ≠ агент. Skill — это рецепт который читает основной агент. Subagent — это другой агент.

2. Decision tree

Q1: задача требует ИЗОЛИРОВАННОГО контекста?
    (родителю не нужно видеть промежуточные шаги, иначе утопит)
    └─ ДА → склоняемся к subagent → к Q3
    └─ НЕТ → к Q2

Q2: задача — это пошаговая ИНСТРУКЦИЯ (рецепт), которую может выполнить
    основной агент, если ему напомнить как?
    └─ ДА → skill
    └─ НЕТ → к Q3

Q3: задача параллелится с другими (есть смысл запустить 3 копии)?
    └─ ДА → subagent
    └─ НЕТ → к Q4

Q4: задача требует ДРУГОГО набора tools (или жёстко урезанного)?
    └─ ДА → subagent
    └─ НЕТ → к Q5

Q5: задача длинная (≥ 10 turns с обильным tool-use)?
    └─ ДА → subagent (не загрязняй главный контекст)
    └─ НЕТ → skill

Если после Q5 всё ещё «не уверен» — начни со skill.
Перейти со skill на subagent дешевле, чем наоборот.

3. Критерии — по одной шкале

Скорер: 3+ строки в правой колонке → subagent. Иначе — skill.

4. Гибрид: skill + subagent

Часто правильный ответ — оба:

• Skill описывает «как делается X» — для тех случаев когда X маленький и в потоке
• Subagent инкапсулирует X — для тех случаев когда X нужен в чистом контексте

Пример:

• qa — может быть skill (быстрая проверка) и subagent (полный прогон с отчётом)
• security review — skill для inline-замечаний, subagent для аудита PR

В таких парах: skill — это «вход», subagent — «полная установка». В описании skill упомяни subagent как fallback для сложных случаев.

5. Признаки что ты ошибся

Сделал subagent а надо было skill:

• Subagent зовётся 5+ раз за сессию с тем же контекстом
• Каждый вызов передаёт почти весь главный контекст
• Subagent возвращает «глянь файл X» — главный агент потом всё равно его читает
• Overhead вызова > времени работы

Сделал skill а надо было subagent:

• Skill раздувает контекст на 10k+ токенов каждый вызов
• Skill требует tools которые опасно давать главному агенту (например, prod-deploy)
• Skill идёт > 10 шагов и засоряет историю
• В середине skill агент «забывает» исходную задачу

6. Cost-aware решение

Грубая прикидка стоимости:

Skill = (loading_cost_once) + N × (zero_overhead_per_call)
Subagent = N × (system_prompt + context_passing + result_return)

Если N (вызовов в сессию) ≥ 3 и контекст не растёт — skill дешевле. Если N ≤ 2, но контекст массивный — subagent дешевле (он не тащит главный контекст).

Прогон 5 типичных сессий с замером — лучший аргумент.

7. Анти-паттерны

• ❌ «Сделаю subagent на всякий случай» — overhead будет всегда, выгода — иногда
• ❌ Skill длиной 800 строк — это уже design doc, не инструкция. Дроби.
• ❌ Subagent без жёсткого описания «когда меня вызывать» — главный агент путается
• ❌ Skill требует state между вызовами — это не skill, это сервис
• ❌ Один subagent на 3 разные задачи — разделяй
• ❌ Skill дублирует то что уже умеет главный агент (просто другими словами)
• ❌ Решение «по интуиции» без прогона decision tree
• ❌ Subagent без своих tools (использует ровно как родитель) — почти всегда должен быть skill

На выходе

• Заполненный decision tree для кандидата
• Таблица критериев с галочками (skill / subagent)
• Решение + 1-2 строки обоснования
• Если выбран гибрид — описание ролей skill и subagent