Чому скіл не тригериться

Скіл — це не функція, яку викликають. Це опис, за яким модель вирішує сама, чи він зараз доречний. Тому 90 % проблем зі скілами — це проблеми одного поля: description.

Що насправді потрапляє в контекст

Із цього все й випливає:

• Опис — єдине, що модель бачить, коли вирішує. Тіло вона на цей момент не читала. Написати геніальні інструкції всередині й лаконічний опис зовні — це зробити скіл невидимим.
• Довге тіло майже безкоштовне, довгий опис — ні. 80 скілів × 60 токенів = 4800 токенів, які висять у кожній сесії назавжди.
• Прогресивне розкриття робиться через references/. У SKILL.md — рішення й процедура, у референсах — таблиці, приклади, довідкові дані.

Окремо: при компакції тіла викликаних скілів реінжектяться з лімітом ~5k токенів на скіл і ~25k загалом, обрізка згори. Найважливіше має стояти на початку файлу.

Анатомія робочого description

Три обов'язкові частини:

1. Що робить — одне речення, конкретно. Не «допомагає з документами», а «конвертує хоткеї зі скріна чи PDF у двомовну UA+ES шпаргалку для термопринтера».
2. Коли тригерити — дослівні фрази, якими це просять. Українською, англійською, суржиком — як реально пишуть. Плюс /slash-name.
3. Коли НЕ тригерити — і чим це відрізняється від сусіднього скіла. Це найчастіше пропускають, і саме звідси беруться помилкові спрацювання.

description: >
  Слайсить STL/3MF під принтер Primex 1 (320×320×320, PLA Mint дефолт),
  повертає gcode і час друку.
  Trigger: "слайсни", "наріж", "підготуй до друку", "хочу надрукувати",
  "/kiri-slicer", посилання на MakerWorld/Printables/Thingiverse,
  або вкладений файл .stl / .3mf.
  НЕ trigger: правки самого слайсер-сервера (там kiri-update),
  загальний шеринг файлів (kiri-files), моделювання в Blender.

Правило, яке ловить більшість помилок: описувати ситуацію користувача, а не функціональність скіла. Модель матчить запит із ситуацією, а не з фічелістом.

Коли тригер має бути тільки ручний

disable-model-invocation: true тримає скіл повністю поза контекстом, поки його не викличуть як /name.

Чому скіл не спрацьовує: діагностика

Skill sprawl

Типова картина: бібліотека на 40–80 скілів, з яких топ-5 дають більшість викликів, а решта — це податок на контекст у кожній сесії плюс шум, у якому модель обирає не те.

Що з цим робити:

• Тримати активними ~20. Решта — не видаляти, а вимикати.
• Раз на квартал перечитувати список і питати про кожен: «коли я викликав це востаннє?»
• Скіл, який жодного разу не спрацював автоматично — кандидат на disable-model-invocation: true. Він і так викликається руками, нащо платити за опис.
• Два скіли, які постійно плутаються між собою — це один скіл із гілкою всередині.

Як це тестувати

Не «здається, тепер має працювати», а:

1. Виписати 5 реальних формулювань, якими цю задачу просять. Своїми словами, з помилками, як пишеться о другій ночі.
2. Виписати 3 формулювання сусідньої задачі, на які цей скіл спрацьовувати не повинен.
3. Прогнати всі 8 у свіжій сесії й подивитись, що підхопилось.
4. Правити тільки description, тіло не чіпати, поки тригер не стане чистим.

Ключове: свіжа сесія. У поточній модель уже знає, про що мова, і підхопить скіл навіть із поганим описом — тест буде брехливий.

Чекліст перед тим, як зберігати скіл

• В описі є дослівні фрази, якими це просять — не переказ, а цитати
• В описі є «НЕ trigger» із назвою сусіднього скіла
• Опис влазить у 3–5 рядків
• Опис описує ситуацію, а не фічеліст
• Найважливіші інструкції — на початку SKILL.md, не в кінці
• Довідкові таблиці винесені в references/, а не в тіло
• Сайд-ефекти → disable-model-invocation: true
• Прогнано 5 позитивних і 3 негативні формулювання у свіжій сесії