TL;DR
Большинство файлов-инструкций (Agent Skills — текстовые файлы, которые ИИ-агент подгружает, чтобы повторно применять готовую процедуру в разных задачах) работают только там, где их написали — в одном чате, репозитории или задаче. Исследователи проверили 138 тысяч таких файлов по 31 критерию и нашли: почти каждый (92%) содержит хотя бы один дефект, который мешает использовать его где-то ещё.
Самая частая проблема — слабое описание навыка. Агент решает, загружать инструкцию или нет, глядя только на короткое описание (пара строк). Оно должно чётко отвечать на два вопроса: что делает и когда использовать. У больше половины файлов описание либо не объясняет "когда", либо вообще не работает как триггер — и агент просто не находит нужную инструкцию, даже если её содержимое отличное.
Вывод простой: чтобы инструкция реально переживала перенос в другой чат, другому человеку или на другую платформу, её нужно проверить по семи направлениям: чёткое описание-триггер, компактное тело без мусора (истории правок, TODO, install-заметок), без захардкоженных путей/секретов/имён моделей, без переопределения роли агента.
Схема метода
Это не пошаговая техника, а диагностический чек-лист из 7 категорий — можно применять к любой инструкции, которую хочешь переиспользовать:
1. МАРШРУТИЗАЦИЯ → описание чётко говорит ЧТО делает и КОГДА использовать (не слишком коротко, не слишком длинно, без воды)
2. ТЕЛО ИНСТРУКЦИИ → компактно, без очевидных объяснений, без дублирования названия как заголовка
3. ОРГАНИЗАЦИЯ РЕСУРСОВ → не заваливай инлайн-кодом и примерами, выноси в отдельные блоки
4. ЗАПРЕЩЁННЫЙ КОНТЕНТ → убери install-инструкции, changelog, лицензии, TODO/FIXME
5. БЕЗОПАСНОСТЬ ПОВЕДЕНИЯ → без хардкода паролей/ключей, без опасных команд, без путей к твоим локальным файлам
6. ПЕРЕНОСИМОСТЬ → без привязки к конкретной модели, платформе, ОС
7. РОЛЬ И ГРАНИЦЫ → не переопределяй личность/роль ассистента без необходимости
Пример применения
Задача: Ты сделал в Claude Project или Custom GPT инструкцию «Проверка коммерческого предложения перед отправкой клиенту» и хочешь, чтобы её использовала вся команда в разных чатах — не только ты.
Промпт:
Вот инструкция, которую я хочу сделать переиспользуемой командой:
{текст_инструкции}
Проверь её по чек-листу и найди проблемы:
1. Есть ли в начале чёткое описание (1-2 предложения): что она делает и КОГДА её нужно применять? Без этого коллеги не поймут, когда её включать.
2. Не раздута ли она лишними пояснениями, историей правок, заметками "как я это придумал"?
3. Есть ли в тексте мои личные пути к файлам, конкретные названия сервисов/моделей, которые сузят её до моего окружения?
4. Не переопределяет ли инструкция роль ассистента ("теперь ты — юрист X") без явной необходимости — это может конфликтовать с другими задачами в том же чате?
Перепиши инструкцию с исправлениями, сохранив суть.
Результат: Модель разберёт инструкцию по каждому пункту — укажет, например, что описание слишком общее и не говорит "когда" её включать, или что в тексте зашит путь к твоей папке на компьютере. Потом выдаст переписанную компактную версию, готовую к передаче другим людям.
Почему это работает
Когда агент решает, какую инструкцию подгрузить, он не читает весь текст — только короткое описание-заголовок. Если оно расплывчатое, агент физически не может понять, для какой ситуации инструкция подходит, и пропускает её — даже если содержимое хорошее.
При этом LLM отлично считывает явные, конкретные триггеры: "что делает" + "когда использовать" в паре строк работает как ярлык на файле. Модель не гадает — она сопоставляет описание с задачей напрямую.
Метод переносит фокус с "что написать внутри инструкции" на "как её подписать снаружи". Хорошее описание-триггер решает проблему выбора раньше, чем содержимое самой инструкции успевает сыграть роль.
Рычаги управления: - Длина описания — слишком короткое (нет контекста) или слишком длинное (модель не считывает суть) одинаково вредны - Явные триггерные слова ("используй когда...", "нужен для...") — резко повышают шанс, что инструкцию найдут - Удаление истории правок, install-заметок — экономит контекст и не путает модель "рабочими" инструкциями - Удаление конкретных путей/имён моделей — единственный способ сделать инструкцию переносимой между чатами и платформами
Шаблон промпта
Вот моя инструкция/промпт, который я хочу использовать многократно в разных чатах:
{текст_инструкции}
Проверь её как диагност и найди проблемы по этим направлениям:
1. МАРШРУТИЗАЦИЯ: есть ли чёткое описание (что делает + когда применять) в 1-3 предложениях?
2. РАЗДУТОСТЬ: нет ли лишних пояснений, истории правок, заметок для себя?
3. ЖЁСТКАЯ ПРИВЯЗКА: нет ли личных путей к файлам, имён конкретных сервисов/моделей, которые сузят применимость?
4. РОЛЬ: не переопределяет ли инструкция роль ассистента без необходимости, не конфликтует ли с другими задачами?
Для каждого пункта: ✅ если ок, ⚠️ с объяснением если проблема.
Затем перепиши инструкцию с исправлениями.
Подставь свою инструкцию, промпт, шаблон Custom GPT или Claude Project — что угодно, что планируешь использовать больше одного раза.
🚀 Быстрый старт — вставь в чат:
Вот шаблон чек-листа переиспользуемости инструкций. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, для какой платформы или контекста инструкция будет использоваться (Custom GPT, Claude Project, командный документ) — потому что это влияет на то, какие ограничения (переносимость, роль) критичны, а какие нет.
Ограничения
⚠️ Не генерирует контент, только диагностирует: метод не пишет инструкцию с нуля — он находит проблемы в готовой и помогает почистить её.
⚠️ Работает для reusable-артефактов, не для разовых промптов: если ты пишешь промпт для одной задачи в одном чате — чек-лист избыточен. Ценность появляется, когда инструкцию будут использовать другие люди или в других чатах.
⚠️ Прямые доказательства есть только для описания-триггера: исследователи напрямую замерили, что плохое описание снижает шанс найти инструкцию. Для остальных пунктов чек-листа (раздутость, безопасность) влияние показано только косвенно — через прошлые исследования и жалобы пользователей, не через отдельный тест.
Как исследовали
Команда собрала 138 133 файла SKILL.md из 20 556 публичных репозиториев — через поиск по GitHub, клонирование репозиториев и API реестра навыков. Дальше построили таксономию дефектов в три захода: сначала выписали все требования из официальной спецификации, потом вручную разметили 300 файлов на реальные проблемы, которые в спецификации не прописаны (захардкоженные пароли, переопределение роли), и наконец сверили список с 761 реальной жалобой пользователей на GitHub — чтобы убедиться, что каждая категория дефекта реально кому-то мешала.
Самое интересное — тест на "находимость": исследователи построили поисковый индекс по описаниям 20 000 навыков и проверили, находит ли агент нужный файл по запросу. Навыки с чистым описанием находились с вероятностью 88,5%, с дефектным описанием — только 82,6%. Разница не гигантская, но стабильная и показывает: плохое описание в буквальном смысле "прячет" хорошую инструкцию от агента.
Удивительно, что доминируют не экзотические угрозы (инъекции, взломы), а банальная небрежность в оформлении — треть всех навыков вообще не объясняет, когда их применять.
Ресурсы
What Keeps Agent Skills from Being Reusable? Evidence from 138K SKILL.md Files — Chi Zhang, Xinze Chen (CUNY Graduate Center), Yimin Liu (Ohio State University), Ping Ji (Hunter College, CUNY). Ссылки на связанные работы: SkillsBench, SkillReducer, agnix linter, официальная спецификация Agent Skills.