У WorkOS розробники досвіду Nick Nisi та Zach Proser з applied AI‑команди проводять практичний воркшоп «Skills at Scale», присвячений тому, як будувати керовані агентні робочі процеси поверх великих мовних моделей. У центрі підходу — так звані «skills»: невеликі, портативні одиниці поведінки, які дозволяють LLM працювати не як імпровізуючий співрозмовник, а як інструмент із чіткими правилами, форматами та детермінованим контекстом.
Ця стаття розбирає, як влаштовані skills, як модель вирішує, коли їх застосовувати, і чому вбудовані скрипти всередині SKILL.md стають ключем до стабільних, малотокенних сценаріїв використання.
Від «чистого аркуша» до портативної одиниці поведінки
Робота з LLM у звичайному чаті має фундаментальне обмеження: кожна нова розмова починається з нуля. Модель не пам’ятає попередні сесії, не знає ваших конвенцій, стеку, внутрішніх правил. Щоразу доводиться пояснювати, як ви працюєте, які інструменти використовуєте, що вважаєте прийнятною якістю коду чи документації. Це забирає час, збільшує витрати токенів і, головне, не гарантує повторюваного результату.
Файли на кшталт claude.md або інших «memory files» частково розв’язують проблему: їх можна покласти в репозиторій або глобальну директорію, щоб модель щоразу отримувала базовий опис проєкту й стилю роботи. Але в такого підходу є кілька очевидних мінусів. Контекст прив’язаний до конкретного репозиторію, його потрібно синхронізувати між членами команди, а вбудованого механізму виконання скриптів немає. Додати детерміновані дані — наприклад, список останніх git‑комітів — можна лише обхідними шляхами.
Skills пропонують наступний крок еволюції. Замість розмитої «пам’яті» вони вводять чітко окреслені, портативні одиниці роботи, які можна переносити між проєктами, ділити на дрібні спеціалізовані блоки та комбінувати між собою.
Технічно skill — це не просто один файл, а папка, у якій є SKILL.md і, за потреби, додаткові скрипти, референси та ресурси. Така структура перетворює навички на самодостатні модулі поведінки: усе, що потрібно моделі для виконання певного типу задачі, живе в одному місці й може бути перенесене в інший репозиторій або середовище без переписування інструкцій.
SKILL.md: фронт-матер як механізм маршрутизації
Серце будь-якого skill — файл SKILL.md. На перший погляд це звичайний markdown, але з важливою особливістю: у верхній частині розміщується фронт-матер у стилі YAML із ключовими полями, насамперед name і description.
Саме ці два поля використовує LLM під час виконання для маршрутизації: модель читає назву та опис навички й вирішує, чи релевантна вона поточному запиту. Якщо опис чітко формулює, для чого призначений skill, модель може автономно «підхопити» його, коли користувач просить зробити щось, що відповідає цій спеціалізації.
Це принципово відрізняється від класичних «системних промптів», які завжди додаються до контексту незалежно від задачі. Skill не роздуває контекст постійно; він підтягується лише тоді, коли його опис збігається з наміром користувача. У результаті:
LLM отримує менше зайвої інформації й може зосередитися на релевантних інструкціях.
Команда розробників отримує передбачувану поведінку: один і той самий тип запиту маршрутизується до одного й того самого skill.
Розробка навичок стає модульною: можна створювати окремі skills для рев’ю коду, генерації звітів, онбордингу, форматування документації — і дозволити моделі самій обирати потрібний модуль за описом.
Фронт-матер у SKILL.md таким чином виконує роль «API‑контракту» між людиною, яка проєктує навичку, і LLM, яка її викликає. Від якості цього контракту залежить, чи буде модель коректно маршрутизувати запити й чи не почне застосовувати навичку там, де вона не доречна.
30 рядків, які змінюють поведінку моделі
Одна з найбільш контрінтуїтивних рис skills — наскільки вони можуть бути маленькими й водночас ефективними. Мінімальний варіант — це статичний SKILL.md без жодних скриптів, приблизно на 30 рядків markdown, заточених під конкретний сценарій.
У такому файлі можна:
описати, для чого призначений skill;
зафіксувати кілька ключових конвенцій проєкту;
задати формат вихідних даних, якого має дотримуватися модель;
ввести кілька жорстких обмежень, які не можна порушувати.
Навіть настільки компактний опис суттєво змінює характер відповіді. Якщо звернутися до LLM із загальним проханням «оцінити репозиторій», модель зазвичай видасть розмитий, універсальний фідбек: кілька банальних порад, трохи поверхневого аналізу структури, можливо, згадку про тести чи документацію.
Якщо ж той самий запит проходить через skill, де в 30 рядках описано, як саме команда оцінює репозиторії, які стандарти вважає критичними, як оформлює коміти, що вважає «дрейфом» README, відповідь стає гіперспецифічною. Модель починає перевіряти саме ті аспекти, які важливі для цього проєкту, і повертати результат у потрібному форматі.
Ключовий момент: сила skills не в обсязі тексту, а в чітко закодованих обмеженнях і конвенціях. Надмірно розлогі інструкції, перетворені на «роман» посеред markdown, часто дають гірший результат, ніж кілька добре сформульованих правил. Наприклад, вимога ніколи не бути розпливчастим або завжди наводити посилання на конкретний рядок коду з git‑комітом може радикально підвищити корисність відповіді без збільшення розміру контексту.
Таким чином, skills дозволяють перенести принцип DRY у світ агентів: замість того, щоб щоразу повторювати одні й ті самі вимоги в чаті, команда один раз кодує їх у SKILL.md і далі просто викликає навичку або дозволяє моделі самій її обирати.
Повторюваність замість імпровізації: навіщо кодувати формат і обмеження
Одна з головних проблем роботи з LLM у «вільному» режимі — непередбачуваність. Навіть якщо двічі поставити однакове запитання, модель може відповісти по-різному: змінити структуру, рівень деталізації, стиль, іноді пропустити важливий крок. Це прийнятно для брейнштормінгу, але неприйнятно для операційних процесів, де потрібні стандартизовані артефакти — звіти, чеклісти, технічні описи.
Skills вирішують це за рахунок явного кодування обмежень і форматів. У SKILL.md можна не лише описати, що саме має зробити модель, а й як саме має виглядати результат. Наприклад, можна вимагати:
чітко визначену структуру розділів;
конкретні поля з фіксованими назвами;
посилання на код у форматі «файл:рядок (коміт)»;
відсутність загальних фраз без прив’язки до артефактів репозиторію.
У такій конфігурації skill стає не просто підказкою, а фактично шаблоном вихідного артефакту. Коли LLM виконує навичку, вона не «вигадує» формат на ходу, а заповнює заздалегідь визначену структуру. Це різко підвищує повторюваність: два запити одного типу з високою ймовірністю дадуть відповіді, які можна порівнювати, агрегувати, передавати між командами.
Це особливо помітно на прикладі воркшопного skill’у WorkOS під назвою «repo roast». Його завдання — аналізувати git‑репозиторії й жартівливо, але по суті, критикувати їхній стан. Без спеціалізованої навички LLM обмежилася б загальними зауваженнями. Але коли в SKILL.md закодовано конкретні критерії оцінки, очікуваний тон, формат звіту й навіть допустимий рівень «жорсткості» жартів, результат стає одночасно корисним і послідовним між різними запусками.
У ширшому сенсі skills перетворюють LLM із генератора тексту на механізм виконання процедур, де кожна процедура описана в окремому модулі. Це відкриває шлях до побудови складних агентних систем, у яких різні навички комбінуються, але кожна з них гарантує стабільний формат виходу.
Скрипти всередині SKILL.md: детермінізм у недетермінованій розмові
Навіть добре спроєктований skill не вирішує ще одну фундаментальну проблему: LLM не має прямого доступу до поточного стану вашого середовища — репозиторію, системи контролю версій, локальних інструментів. Якщо попросити модель «подивитися останні коміти й скласти звіт», їй доведеться або покладатися на те, що ви самі вставите список комітів у промпт, або використовувати зовнішні інструменти, які не завжди інтегровані в робочий процес.
У skills, які підтримує Claude, цю прогалину закриває механізм інтерполяції скриптів. Усередині SKILL.md можна використовувати синтаксис !command“ для виконання локальної команди й підстановки її виводу безпосередньо в промпт, який бачить модель.
Це означає, що навичка може, наприклад:
запустити скрипт, який виведе список останніх git‑комітів у потрібному форматі;
зібрати метадані про структуру репозиторію;
витягнути специфічні файли або фрагменти коду;
згенерувати будь-який інший детермінований вхід, який потім буде проаналізований LLM.
У результаті в недетерміновану розмову з моделлю вбудовується детермінований шар даних. Кожен запуск навички з однаковими параметрами й у тому самому середовищі дає однаковий набір вхідних артефактів, навіть якщо сама модель генерує текст із певною варіативністю. Це критично для сценаріїв, де важлива відтворюваність: рев’ю змін, аудит безпеки, формування звітів за фіксований період.
Важливо й те, що такий підхід суттєво знижує витрати токенів. Замість того, щоб змушувати LLM «відкривати» репозиторій через послідовність запитів, користувач один раз запускає локальний скрипт, який повертає стислий, релевантний зріз даних. У SKILL.md цей скрипт викликається автоматично, а модель отримує вже готовий, компактний вхід. Менше зайвого контексту — менше токенів, менше шансів, що модель «заблукає» в неструктурованих даних.
Таким чином, інтерполяція скриптів у skills перетворює LLM на частину більшої системи, де локальні інструменти відповідають за збір і нормалізацію даних, а модель — за інтерпретацію й генерацію вихідних артефактів.
Портативність і композиція: як будувати бібліотеку навичок
Ще одна сильна сторона skills — їхня портативність. Оскільки навичка — це папка з SKILL.md і супутніми файлами, її можна перенести в інший репозиторій або середовище без змін. Це контрастує з підходом, де всі інструкції зашиті в один глобальний файл пам’яті або розкидані по різних проєктах.
Портативність відкриває можливість композиції. Замість одного монолітного «мегаскіла», який намагається охопити всі сценарії, команда може створити низку дрібних, вузькоспеціалізованих навичок:
одна відповідає за аналіз структури репозиторію;
інша — за перевірку стилю комітів;
третя — за виявлення дрейфу між README та фактичним кодом;
четверта — за формування звіту в потрібному форматі.
Кожен із цих skills має власний SKILL.md із чітким описом і, за потреби, власними скриптами. LLM, орієнтуючись на назву й опис, може обирати, які навички застосувати до конкретного запиту. У складніших сценаріях над цим може стояти ще один «оркеструвальний» рівень, але навіть без нього базова маршрутизація за описом уже дає відчутний виграш.
Важливо, що кожен skill має дуже малий «футпринт» у контекстному вікні. На відміну від глобального claude.md, який додається до кожної сесії й поступово розростається, невелика навичка підтягується лише тоді, коли потрібна. Це дає змогу масштабувати бібліотеку skills без страху, що кожна нова інструкція ще більше роздує контекст.
У підсумку формується новий рівень абстракції над LLM: не просто «чат із моделлю», а набір чітко визначених, переносних процедур, які можна комбінувати, перевикористовувати й поступово вдосконалювати, не ламаючи решту системи.
Висновок: LLM як платформа для процедур, а не лише для тексту
Підхід WorkOS до skills демонструє, як можна вийти за межі класичної парадигми «чат із ШІ» й перетворити LLM на керований, повторюваний інструмент. Ключові елементи цієї трансформації — прості, але в сукупності дають якісно новий результат.
Навичка — це папка з SKILL.md і, за потреби, скриптами та ресурсами, яка утворює портативну одиницю поведінки.
Назва й опис у фронт-матері SKILL.md стають механізмом маршрутизації: модель сама вирішує, коли застосувати навичку.
Навіть невеликий статичний markdown на ~30 рядків, заточений під конкретний сценарій, може радикально змінити якість і специфічність відповіді.
Skills дозволяють кодувати обмеження й формати так, щоб вихідні артефакти були повторюваними й придатними для операційного використання, а не лише для разових відповідей.
Інтерполяція скриптів через синтаксис !command“ дає змогу вбудовувати детерміновані дані — на кшталт списку git‑комітів — у недетерміновану розмову з LLM, знижуючи витрати токенів і підвищуючи відтворюваність.
У сукупності це формує нову модель роботи з агентами: замість того, щоб кожного разу «навчати» модель у чаті, команди один раз кодують свої процеси в skills і далі працюють із ними як із бібліотекою процедур. LLM у такій архітектурі стає не кінцевим продуктом, а ядром платформи, яке виконує чітко визначені навички, підкріплені локальними скриптами й детермінованими даними.