Вы пишете SKILL.md, запускаете его один раз на собственном примере, наблюдаете, как он производит что-то хорошее, и отправляете его. Это не тест — это демо. А навык, который отлично смотрится в демо-версии и разваливается в запутанном реальном случае, хуже, чем отсутствие навыка вообще...
Вы пишете SKILL.md, запускаете его один раз на собственном примере, наблюдаете, как он производит что-то хорошее, и отправляете его. Это не тест — это демо. А навык, который отлично выглядит в демо-версии и разваливается в беспорядочном реальном случае, хуже, чем отсутствие навыка вообще, потому что теперь вы построили рабочий процесс, который предполагает, что он работает.
Вот реальный режим неудачи: навык, который был отличным один раз и непригодным для использования дважды, хуже, чем простая подсказка. Простая подсказка, которую вы перечитываете каждый раз, чтобы уловить неверный результат. Навык, которому вы доверяете — в этом весь смысл его написания — поэтому плохой результат ускользает.
Судите о дисперсии, не лучший случай
Запустите навык несколько раз на входах, для которых вы его не создавали. Это не тот чистый пример, который вы имели в виду при написании триггера — уродливый, двусмысленный, наполовину конкретизированный запрос, который на самом деле отправляет реальный пользователь. Если качество продукции сильно колеблется между тиражами, у вас нет навыков, у вас есть лотерейный билет с хорошим маркетингом.
Три вещи, необходимые для проверяемого навыка
1. Письменное ожидание правильного результата. Не «это должно быть хорошо» — фактическое описание того, как выглядит правильно, достаточно конкретное, чтобы вы (или кто-то другой) могли сверить с ним реальные выходные данные и получить тот же ответ «да/нет».