KotАнатомия скилла
Как выглядит скилл, который реально работает?
Обязательные части:
Триггер. Description в метаданных скилла — первое и единственное, что агент видит при выборе. По нему решает, подключать скилл или нет. “Утилита для работы с кодом” — не триггер, агент пройдёт мимо. “Используй когда пользователь просит ревью MR или называет номер merge request” норм триггер.
Чёткий вход. Агент должен понимать с чего начать. Номер задачи, название ветки, путь к файлу — что-то конкретное, а не “проанализируй проект”.
Пошаговый workflow. Не “сделай ревью”, а: забери данные → проанализируй по критериям → покажи результат → дождись подтверждения → выполни действие. Каждый шаг — конкретный. Агент не должен гадать что делать дальше.
Точки подтверждения. Места, где агент останавливается и спрашивает. Не постит комментарии без одобрения, не создаёт задачи без подтверждения. Агент исполнительный, но не всегда точный — перед необратимыми действиями пусть спросит.
Конкретные вызовы API. Если скилл интеграционный — прямо curl с параметрами, поля, форматы. Агент не знает ваши кастомные поля в Jira и ваш инстанс GitLab. Без этого он будет угадывать и ошибаться.
Краевые случаи. Что если данные не нашлись? Что если нет прав? Что если ввод некорректный? Без этого агент на первом нестандартном кейсе встанет или сделает дичь.
Если в скилле нет хотя бы триггера, входа и пошагового workflow — это не скилл, а пожелание. Агент прочитает и сделает по-своему. Галлюцинации рождаются там, где недостаточно информации, как я в своей статье писала.