Основной агент получил правила публикации статьи, затем передал помощнику просьбу «подготовь материал». Помощник вернул хороший текст, но не проверил внутренние ссылки и метаданные. Возможная причина проста: процедура осталась в первом разговоре, а в поручение попало только её название.
При передаче задачи нужно проверить доступность знаний так же внимательно, как доступность файлов. Ссылка на скилл полезна лишь тогда, когда исполнитель может его прочитать и понимает, в какой момент применять. Рассмотрим передачу редакционной процедуры помощнику без дублирования всей документации.
Разделите процедуру и конкретную задачу
В процедуре живут повторяемые действия: проверить заголовки, ссылки, описание и отображение статьи. В поручении — конкретный slug, назначение материала, разрешённые файлы и ожидаемый результат. Если смешать эти уровни, следующий текст придётся запускать с копией длинного старого запроса.
Пусть процедура называется review-article и находится в проектном каталоге инструкций. Само имя ничего не гарантирует. В одном проекте она может означать редакторскую вычитку, в другом — проверку SEO, в третьем такого файла вообще нет. Передавайте разрешимый путь или доступный идентификатор, а не только знакомое вам слово.
Скилл не обязан быть отдельным агентом. Это может быть процедура, которую выполняет человек или основной исполнитель. Отдельный помощник появляется, когда есть самостоятельный результат и полезная граница контекста. Размножать исполнителей по числу инструкций не требуется.
Подготовьте пакет передачи
Для нашего примера достаточно самой статьи, цели вычитки, ссылки на процедуру и формата ответа. Не нужно пересылать весь разговор о развитии блога: помощнику нужны решения, влияющие на его работу, а не история их обсуждения.
Задача: вычитать готовое руководство перед подключением к каталогу.
Материал: database/content/rebuild/how-to/example.html.
Правила: прочитай указанную проектную процедуру review-article.
Контекст: аудитория умеет читать код; статья углубляет рабочий процесс.
Сохраняем: slug, основной вопрос и честное обозначение учебных примеров.
Результат: цитата → проблема → конкретная предлагаемая правка.
Действия: чтение; файл статьи и каталог не изменять.
Если процедура недоступна, сообщи это до оценки по её правилам.Путь example.html здесь условный: перед запуском его нужно заменить на существующий файл. Отдельно укажите, может ли помощник открывать внешние источники. Если требуется проверка продуктового утверждения, одной вычитки формулировок недостаточно.
Уточните, что действительно передаёт инструмент
Не предполагайте, что помощник видит все инструкции основного разговора. Например, документация Claude Code описывает отдельную настройку предварительной загрузки скиллов в субагента. Для собственного окружения нужно сверить фактическую конфигурацию и поведение запуска.
Здесь полезен короткий ответ до большой работы: какие входные материалы прочитаны, какая процедура найдена, каких данных не хватает. Это не церемония согласования каждого шага. Это проверка, что делегирование началось с тех же оснований, на которых вы оцените результат.
Не просите пересказывать всю инструкцию ради доказательства чтения. Лучше задать вопрос о существенной границе: «Будешь ли ты исправлять файл или только возвращать замечания?» Если ответ расходится с поручением, устраните неоднозначность до запуска длинного прохода.
Держите повторяемые правила в одном месте
Если чек-лист ссылок существует в скилле, не копируйте его полностью в описания трёх помощников. Иначе одна правка создаст несколько конкурирующих редакций. В описании исполнителя достаточно обозначить применяемую процедуру и собственную зону ответственности.
При этом критическое ограничение конкретного запуска можно повторить в поручении. Например, «не публиковать» или «работать только с указанным файлом» должно быть видно сразу. Это не вторая копия всей процедуры, а граница выданного задания.
Версию правил фиксируйте способом, принятым в проекте: ревизией репозитория, датой редакции во внутреннем отчёте или ссылкой на конкретный документ. Не добавляйте служебную отметку проверки в публичную статью. Она нужна для воспроизводимости работы, а не читателю в каждом тексте.
Не скрывайте конфликт инструкций
Предположим, процедура предполагает автоматическое исправление опечаток, а поручение требует только отчёт. Помощник должен следовать действующим правилам приоритета своего окружения и не расширять разрешённые действия молча. В отчёте достаточно отметить, что правки предложены, но не применены.
Другой конфликт касается фактов: старый скилл рекомендует повторно заполнить каталог сидером, а текущая задача требует сохранить ручные изменения. Исполнитель не должен выбирать более удобный путь. Он возвращает конкретное расхождение владельцу задачи, который обновляет процедуру или уточняет способ безопасного применения.
Принимайте результат по исходному поручению
Для вычитки полезный ответ содержит точные цитаты, объяснение проблемы и различие между существенным дефектом и стилевым предпочтением. Сообщение «статья хорошая» не показывает, были ли проверены обещания, примеры и границы ответственности. Список из десятков общих советов тоже не заменяет чтение текста.
После принятия замечаний основной исполнитель вносит согласованные изменения и проверяет итог. Если помощник лишь предложил заменить ссылку, это ещё не означает, что ссылка проверена и файл обновлён. Сохраняйте различие между рекомендацией, выполненным действием и подтверждённым результатом. Именно оно позволяет человеку удерживать ответственность при нескольких участниках задачи.
