Запрос «пост не появился в RSS» подходит помощнику по контенту, разработчику и исследователю кода. Добавить в каждое описание слово RSS — значит усилить пересечение. Сначала надо понять, какой результат требуется сейчас: проверить статус записи, найти причину или исправить уже установленный дефект.
Описание помощника удобно проверять как маленькое правило выбора. Оно должно различать задачи, которые действительно встречаются в проекте, включая неполные формулировки. Красивый список компетенций этой проверки не заменяет.
Назовите результат, который возвращает помощник
«Эксперт по контенту, SEO и публикации» сообщает тему, но почти не ограничивает работу. Сравните с формулировкой: «Проверяет готовую статью перед публикацией: метаданные, ссылки и видимость в публичных выдачах. Возвращает список несоответствий; код приложения не исправляет». Во втором случае понятно, что ждать на выходе.
Для другого помощника можно записать: «Исследует причину расхождения между ожидаемым и фактическим поведением. Возвращает подтверждённую цепочку и неизвестные условия; реализацию исправления не начинает». Теперь задача про RSS всё ещё подходит обоим по теме, но выбор зависит от стадии работы.
В Claude Code поле description используется при выборе субагента. Это конкретный механизм инструмента. В другом окружении выбор может делать человек или явная команда запуска. Метод проверки описаний пригоден в обоих случаях, но нельзя обещать одинаковую автоматическую маршрутизацию.
Соберите контрольные запросы
Возьмите реальные формулировки из задач, убрав личные данные и секреты. Не улучшайте их специально для красивого результата. Если человек обычно пишет «карточка поехала», набор должен содержать именно такую неопределённость, а не только идеально размеченные поручения.
Для учебного набора можно использовать следующие ситуации. Это предложенные случаи проверки, а не результаты проведённого теста.
| Запрос | Ожидаемое первое действие |
|---|---|
| Проверь готовую статью перед публикацией | Редакторская проверка конкретной записи |
| Пост опубликован, но его нет в RSS | Уточнить состояние записи и исследовать причину |
| Исправь исключение архивных статей из поиска: причина найдена в общем scope | Проверить указанную причину и передать ограниченную реализацию |
| После правки карточки пропал фокус клавиатуры | Воспроизвести поведение интерфейса и локализовать обработчик |
| Запусти согласованный набор тестов и верни вывод | Выполнить проверку в указанной тестовой среде без правок |
Ожидание записывается до запуска. Иначе легко объявить удачным любой ответ агента. Укажите также допустимый вариант: для неполного запроса правильным результатом может быть один уточняющий вопрос. Принудительный выбор исполнителя при недостатке данных создаёт ложную точность.
Различайте плохое описание и сложную задачу
Если запрос про CSS постоянно уходит исполнителю миграций, граница описаний действительно не работает. Если запрос требует нового поля, формы админки и публичного вывода, это настоящее пересечение. Отрицательное предложение не превратит его в задачу одной зоны.
Второй случай требует владельца общего результата и последовательности частей. Можно сначала согласовать контракт поля, затем разделить реализацию. Не заставляйте описание выбирать одного «самого подходящего» помощника для всей сквозной задачи: так вы лишь скрываете необходимость координации.
Отдельно отмечайте ошибку стадии. Помощник выбран верно, но вместо исследования сразу начал менять код. Тогда проблема может быть в постановке поручения или доступных действиях. Исправление description не заменяет настройку ограничений проверяющего.
Используйте отрицания как пояснение границы
Фраза «не исправляет приложение» полезна рядом с положительным результатом «возвращает замечания к готовой статье». Она предотвращает неверное понимание роли человеком и помогает модели различать соседние задачи. Но слово «НЕ» не является техническим барьером и не гарантирует правильный выбор.
Если называете другого помощника, проверьте, что он существует в текущем окружении. Ссылка на отсутствующего исполнителя превращает понятную границу в тупик. Лучше написать, какой результат нужен дальше, а конкретное имя добавить в настройках проекта.
Проверяет публичное отображение готового изменения:
адаптив, клавиатуру, видимый фокус и читаемость.
Возвращает сценарий, ожидание и наблюдаемое расхождение.
Не меняет файлы и не подтверждает бизнес-логику по внешнему виду.
Если нужен доступ к недоступному стенду — сообщает ограничение.Такое описание не перечисляет весь инструментарий. Команды, адрес стенда и разрешения относятся к конкретному запуску. Слишком длинная визитка быстро превращается в инструкцию, где условие выбора теряется среди деталей.
После правки повторите набор целиком
Сохраните, какой запрос выбрал какого помощника, какой вопрос был задан и начались ли лишние действия. Исправляйте одну явную границу, затем возвращайтесь ко всем случаям. Новая фраза, которая чинит RSS и ломает публикацию, не улучшает набор в целом.
Для неоднозначных формулировок полезны несколько повторов, но результаты нельзя объявлять гарантией. Выбор зависит от контекста разговора и возможностей конкретного инструмента. Проверка помогает обнаружить устойчивое пересечение, а не доказать безошибочность будущих запусков.
Принимать описание стоит тогда, когда человек сам может объяснить ожидаемый выбор, помощник возвращает требуемый тип результата, а неопределённость не маскируется уверенным действием. Если два описания постоянно требуют одинаковых пояснений, проще объединить их или передавать поручение явно. Отдельная роль должна уменьшать сложность работы, а не создавать ещё один список, который приходится обслуживать.
