У Сан-Франциско, на сцені AI Engineer World’s Fair, двоє інженерів з розробницького досвіду WorkOS — Нік Нісі та Зак Про́зер — показують, як зробити роботу з агентами менш хаотичною й набагато більш передбачуваною. Їхній воркшоп «Skills at Scale» присвячений тому, як будувати й використовувати так звані «skills» — невеликі, але потужні модулі поведінки для LLM-агентів, які можна переносити між проєктами та командами.
Формат сесії навмисно далекий від класичної «говорячої голови». Це інтерактивний практикум з живим кодом, спільним репозиторієм, прикладами та навіть невеликим внутрішнім «маркетплейсом» для навичок учасників. На фоні — команда WorkOS у брендованих футболках, яка не лише консультує з безпеки MCP та аутентифікації для агентних стартапів, а й відверто каже: компанія активно наймає.
Інтерактив замість лекції: як побудований воркшоп
«Skills at Scale» задуманий як сесія, де учасники не просто слухають, а постійно взаємодіють: переривають, ставлять питання, клонують репозиторій, запускають скрипти й одразу бачать результат у власних агентних середовищах.
На старті Нік і Зак пропонують відсканувати QR-код і клонувати спільний репозиторій воркшопу. Це не просто супровідний код до доповіді: у репо зібрані всі приклади skills, з якими працюють під час сесії, а також слайди презентації. Така структура дозволяє учасникам не намагатися встигнути за кожним кроком на екрані, а спокійно повертатися до матеріалів пізніше, відтворювати приклади й адаптувати їх під власні задачі.
Формат воркшопу підкреслює одну ключову ідею: робота з агентами — це вже не екзотика, а щоденна практика. Обидва інженери відверто говорять, що майже перестали писати код «самі по собі» — замість цього працюють у тісній зв’язці з LLM, від перших днів Claude Opus до сучасних інструментів. Але саме тому вони добре бачать обмеження поточного підходу: кожна нова сесія з моделлю починається з нуля, контекст доводиться повторювати, інструкції — переписувати, а результат — щоразу відрізняється.
Воркшоп покликаний показати, як «skills» можуть розірвати це замкнене коло й перетворити розмову з агентом на керований, повторюваний процес, який масштабується разом із командою.
Чому «skills», а не просто prompts: вирішення проблеми пам’яті та повторюваності
Базова проблема роботи з LLM добре знайома будь-кому, хто пробував будувати на них реальні робочі процеси. Кожна розмова починається з чистого аркуша: модель не пам’ятає попередніх сесій, не знає ваших конвенцій, не розуміє, як саме «у вас тут прийнято» писати код, структурувати звіти чи аналізувати репозиторії.
Розробники намагаються обійти це через глобальні чи проєктні файли на кшталт claude.md або agents.md, де описують стек, інструменти, правила роботи. Це дає певну «пам’ять», але має суттєві обмеження. Такий файл або жорстко прив’язаний до конкретного репозиторію, або застосовується глобально до всіх проєктів. Він не вміє нативно виконувати скрипти, не інжектує детерміновані дані, а головне — не є по-справжньому переносимим артефактом, який можна легко розшарити між командами й середовищами.
Саме тут у гру входять skills. У логіці воркшопу це «наступний крок» після простих memory-файлів: спосіб упакувати конкретну одиницю роботи — наприклад, аналіз репозиторію, генерацію звіту чи перевірку стилю коду — у компактний, переносимий модуль, який агент може викликати тоді, коли це доречно.
Ключова відмінність skills від звичайних промптів у тому, що вони:
по-перше, існують як окремі артефакти, які можна зберігати, версіонувати, переносити між проєктами й командами;
по-друге, дозволяють чітко кодувати обмеження й конвенції, яких має дотримуватися модель, щоб видавати не «креативні» відповіді, а стабільні, формалізовані результати;
по-третє, можуть викликати скрипти й підмішувати детерміновані дані — наприклад, список git-комітів — у інакше недетерміновану розмову з LLM.
У підсумку skills стають для агентів тим, чим колись були DRY-патерни для класичного коду: способом не повторювати одні й ті самі інструкції, а один раз описати правильну поведінку й багаторазово її перевикористовувати.
Як виглядає skill: від 30 рядків Markdown до папки з кодом
Одна з важливих цілей воркшопу — зняти «магічність» з поняття skill і показати, наскільки це простий за формою, але потужний за наслідками інструмент.
На найпростішому рівні skill може бути всього лише одним статичним Markdown-файлом — умовним SKILL.md — без жодних скриптів. Нік і Зак наголошують: іноді достатньо приблизно 30 рядків тексту, спеціально заточених під конкретний кейс, щоб радикально змінити якість відповідей моделі. Наприклад, замість загальних порад про «покращення коду» агент починає видавати гіперспецифічний фідбек, який враховує саме ваші правила роутінгу, формат комітів, вимоги до README та інші внутрішні стандарти.
Структурно типовий skill складається з кількох шарів.
На початку файлу розміщується front matter у стилі YAML з ключовими полями: ім’ям і описом. Саме ці два поля стають центральними для роботи LLM: модель використовує їх під час виконання, щоб вирішити, чи релевантний цей skill поточному завданню, і чи варто до нього «маршрутизувати» запит. По суті, це механізм роутингу всередині агентної системи, який дозволяє моделі самостійно обирати потрібну навичку, не змушуючи користувача щоразу вручну її викликати.
Далі в Markdown можна описати контекст, очікуваний формат відповіді, приклади, обмеження. Важливий нюанс, на якому акцентують інженери WorkOS: надмірна деталізація часто шкодить. Набагато ефективніше задати кілька чітких, жорстких обмежень — наприклад, ніколи не бути розпливчастим, завжди наводити конкретні рядки коду з посиланням на git-коміт — ніж перетворювати SKILL.md на роман. Перевантажені інструкції стають типовою «точкою відмови» при проєктуванні skills.
Нарешті, skill — це не лише файл, а радше папка. Усередині, окрім SKILL.md, можуть лежати скрипти, додаткові референси, зображення та інші артефакти. LLM може викликати ці скрипти, щоб отримати детерміновані дані, і використовувати їх у відповіді. Так, наприклад, можна згенерувати список останніх комітів, витягнути метадані з репозиторію чи виконати будь-яку іншу операцію, яка виходить за межі «чистого тексту».
Така модульність робить skills не лише компактними в контекстному вікні моделі, а й висококомпозабельними: їх можна збирати з дрібних, вузько сфокусованих блоків, які активуються лише тоді, коли це справді потрібно.
«Repo roast» як навчальний полігон: спільний skill для всіх
Щоб не залишатися на рівні абстракцій, воркшоп будується навколо конкретного прикладу — skill під назвою «repo roast». Це свідомо обраний універсальний сценарій: аналіз і «жартівлива критика» git-репозиторію, зрозуміла будь-кому, хто хоч трохи працював із системами контролю версій.
«Repo roast» виконує одразу кілька ролей.
По-перше, це демонстрація того, як навіть простий skill може радикально відрізнятися від звичайного запиту до агента. Без спеціального контексту LLM, аналізуючи репозиторій, видасть загальні рекомендації: «оновіть залежності», «додайте тести», «покращіть документацію». З «repo roast» у вигляді кількох десятків рядків Markdown, де закодовані конкретні конвенції команди, очікуваний тон (від серйозного до іронічного) і формат відповіді, агент починає видавати точкові зауваження: вказує на дрейф README, порушення семантичних комітів, нетипові патерни роутінгу чи інші внутрішні «червоні лінії».
По-друге, це спосіб показати, як skills можуть бути одночасно корисними й гнучкими. Учасникам пропонують сприймати «repo roast» як базову заготовку, у яку можна вбудувати власні вимоги: від специфічних правил безпеки до корпоративних стандартів оформлення коду. У процесі воркшопу учасники не лише повторюють приклад, а й модифікують його під свої реальні задачі.
По-третє, «repo roast» стає спільною мовою для обговорення. Коли всі працюють із одним і тим самим skill, легше порівнювати підходи до формулювання обмежень, структурування front matter, використання скриптів. Це перетворює воркшоп на колективну лабораторію, де різні варіанти однієї й тієї ж навички можна обговорити, протестувати й показати в дії.
Усе це підкреслює головну ідею: skills — це не абстрактна концепція, а практичний інструмент, який можна застосувати до будь-якої повторюваної задачі, від онбордингу нових розробників до формування внутрішніх звітів.
Репозиторій як центр ваги: приклади, слайди й внутрішній «маркетплейс» skills
Спільний репозиторій воркшопу — не другорядний атрибут, а фактичний центр усієї сесії. У ньому зібрано три ключові компоненти, які разом формують повний цикл навчання.
Перший компонент — це приклади skills, включно з «repo roast». Вони слугують відправною точкою для експериментів: учасники можуть вивчити структуру SKILL.md, подивитися на front matter, обмеження, приклади форматів відповіді, а потім клонувати й адаптувати їх під свої потреби. Наявність готових прикладів знімає бар’єр входу: не потрібно вигадувати все з нуля, достатньо змінити кілька ключових параметрів.
Другий компонент — слайди презентації. Вони лежать у тому ж репозиторії, що й код, тож після воркшопу учасники мають повний набір матеріалів у одному місці. Це важливо для тих, хто хоче повернутися до теорії, звірити свої реалізації з оригінальними прикладами або поділитися напрацюваннями з колегами, які не були присутні на сесії.
Третій, і, можливо, найцікавіший компонент — скрипт share.sh. Це невеликий, але показовий інструмент, який перетворює воркшоп на щось на кшталт внутрішнього «маркетплейсу» skills. Учасникам пропонують запустити цей скрипт, щоб поділитися власними навичками, створеними під час сесії.
share.sh запитує ім’я користувача й збирає конфігурацію його skill, після чого зберігає її в key-value сховищі. Це дозволяє інструкторам пізніше діставати ці навички, демонструвати їх у реальному часі або аналізувати після воркшопу. Фактично, кожен учасник отримує можливість не лише навчитися будувати skills, а й побачити, як їхні ідеї виглядають поруч із рішеннями інших розробників.
Такий підхід вирішує одразу кілька задач. З одного боку, він стимулює творчість: знаючи, що їхній skill можуть показати публічно, учасники більше вкладаються в якість формулювань, структуру й обмеження. З іншого — створює базу реальних, живих прикладів, які відображають різні стилі мислення й практики команд. Для WorkOS це також спосіб краще зрозуміти, як розробники в дикій природі проєктують skills, де вони помиляються й які патерни виявляються найуспішнішими.
WorkOS як роботодавець і платформа: присутність команди й інфраструктура для агентів
Хоча воркшоп фокусується на skills як концепції, контекст WorkOS відчувається постійно. Нік і Зак працюють у команді applied AI як інженери з developer experience, а отже, їхня щоденна робота — це не лише експерименти з LLM, а й побудова інструментів, які роблять ці експерименти придатними для продакшену.
На заході присутні й інші члени команди WorkOS у брендованих футболках. Вони відкрито запрошують учасників підходити з питаннями про безпеку MCP, налаштування аутентифікації для агентних стартапів і, що важливо, про кар’єрні можливості: компанія активно наймає. Така фізична присутність команди на технічному воркшопі підкреслює, що WorkOS позиціонує себе не лише як постачальника API для аутентифікації, а й як гравця на полі інфраструктури для агентних застосунків.
Окремо згадується й інший артефакт, який добре вписується в загальну картину: AI-інсталер, який Нік побудував для автоматичної конфігурації InstallKit. Завдяки цьому інструменту розробникам більше не потрібно вручну налаштовувати InstallKit — інсталер робить це за них. Це ще один приклад того, як WorkOS намагається зменшити тертя на шляху до запуску агентних систем: від безпеки й аутентифікації до інсталяції інструментів і, тепер, до стандартизації поведінки агентів через skills.
Усе це створює для воркшопу додатковий вимір: це не лише навчання окремій техніці, а й демонстрація того, як компанія бачить екосистему агентів загалом — як набір стандартизованих, повторюваних компонентів, які можна масштабувати разом із продуктом і командою.
Висновок: skills як новий базовий шар для агентних робочих процесів
«Skills at Scale» від WorkOS — це спроба відповісти на дуже практичне запитання: як зробити так, щоб агенти перестали бути «чорними скриньками», які щоразу поводяться трохи по-іншому, і стали керованими інструментами, що стабільно виконують знайомі задачі?
Відповідь, яку пропонують Нік Нісі та Зак Про́зер, полягає в перенесенні класичних принципів інженерії — DRY, модульність, детермінізм — у світ LLM. Skills стають тим самим шаром, де кодуються правила гри: як саме має виглядати звіт, за якими конвенціями оцінюється репозиторій, які обмеження накладаються на відповідь агента. Вони компактні, переносимі, придатні до версіонування й спільного використання.
Інтерактивний формат воркшопу, спільний репозиторій з прикладами й слайдами, скрипт share.sh для обміну навичками — усе це робить сесію не просто лекцією, а практичним майданчиком, де розробники вчаться мислити агентами як системою, а не набором випадкових промптів.
На тлі стрімкого розвитку інструментів на кшталт Claude, Cursor чи Copilot, саме такі підходи можуть визначити, чи стануть агенти повноцінними учасниками командної роботи, чи залишаться «розумними чатами», які щоразу доводиться вчити з нуля.