У WorkOS над прикладними AI‑сценаріями працює окрема команда розробницького досвіду. Інженери Nick Nisi та Zach Proser проводять воркшоп «Skills at Scale», де показують, як перетворити великих мовних моделей на передбачуваних «колег» із чіткими ролями. Центральний елемент цього підходу — так звані skills: невеликі, формалізовані модулі поведінки для агентів.
Окрема практична проблема, яку вони розв’язують, — де саме мають «жити» ці скіли, як зробити їх доступними в різних проєктах і інструментах, і як не перетворити глобальний контекст на смітник. Виявляється, відповідь лежить у досить простій файловій структурі, кількох конвенціях і підтримці з боку популярних AI‑хостів.
Від пам’яті в claude.md до переносимих skills
Класичний спосіб «навчити» агента працювати у вашому стилі — це пам’яткові файли на кшталт claude.md або agents.md. У них описують, які інструменти використовує команда, які є конвенції, які формати відповідей бажані. Ці файли можуть лежати в репозиторії або в глобальній директорії, і хост щоразу підвантажує їх у контекст.
Такий підхід має очевидні обмеження. Якщо файл прив’язаний до конкретного репозиторію, контекст не переноситься в інші проєкти. Якщо зробити його глобальним, він починає впливати на всі сесії, навіть там, де частина правил не доречна. Додайте сюди відсутність вбудованого виконання скриптів — і стає складно поєднувати детерміновані дані (наприклад, список git‑комітів) із недетермінованою розмовою з LLM.
Skills пропонують наступний крок еволюції. Замість одного роздутого файлу пам’яті з’являються невеликі, чітко окреслені одиниці роботи, які можна підключати там, де вони потрібні, і не тягнути за собою зайвий багаж. Важливо, що це не абстрактна концепція, а конкретна файлово‑директорійна модель, яку підтримують кілька популярних AI‑інструментів.
Де живуть skills: структура директорій і область дії
Базова ідея проста: скіл — це папка з файлом SKILL.md (або skill.md) усередині. Але те, куди саме ця папка покладена на диску, визначає, де й як скіл буде доступний.
Для проєктів, прив’язаних до конкретного репозиторію, використовується структура:
.claude/skills/<назва-скіла>/SKILL.md
Ця директорія розміщується в корені репозиторію. У результаті скіл стає локальним для цього коду: коли ви працюєте в цьому репо через Claude, Cursor, Codeium чи інший сумісний хост, агент бачить відповідні скіли й може до них маршрутизувати запити. Вийшли з репозиторію — скіл зникає з поля зору, і це саме те, чого часто хочеться: жорстко прив’язати певні правила й сценарії до конкретного проєкту.
Якщо ж потрібно, щоб скіл був доступний у будь‑якому середовищі, де ви працюєте, його можна зробити глобальним. Для цього використовується директорія в домашній теці користувача:
~/.claude/skills/<назва-скіла>/SKILL.md
Усе, що лежить під ~/.claude/skills, стає глобальним набором скілів. Вони підтягуються в різних проєктах і в різних інструментах, які підтримують цю модель. Це зручно для універсальних речей: особистих шаблонів ідей, стандартів оформлення, повторюваних робочих процедур, які не залежать від конкретного репозиторію.
Таким чином, область дії скіла визначається не якимись прихованими налаштуваннями, а просто шляхом до директорії. Локальні скіли живуть у .claude/skills всередині репозиторію, глобальні — у такій самій структурі в домашній теці. Це робить модель прозорою й передбачуваною: достатньо подивитися на дерево файлів, щоб зрозуміти, які скіли де працюватимуть.
Спільна модель для різних хостів: Claude, Cursor, Codeium, Claude Desktop
Одна з причин, чому ця файлово‑орієнтована модель скілів набирає ваги, — підтримка з боку кількох ключових інструментів. Nick Nisi та Zach Proser працюють із Claude як основним агентом, але підкреслюють, що Claude, Cursor, Codeium і Claude Desktop уже вміють працювати зі скілами в тій чи іншій формі.
Це означає, що один і той самий скіл — папка з SKILL.md і, за потреби, додатковими скриптами чи активами — може бути використаний у різних хостах без дублювання. Розробник може, наприклад, створити скіл для аналізу репозиторію, покласти його в .claude/skills у репо, і потім викликати його як із Claude Desktop, так і з Cursor, працюючи з тим самим кодом.
Спільна модель знімає типову фрустрацію, коли кожен інструмент вимагає власного формату «налаштувань для AI». Тут навпаки: скіл описується один раз, а хости домовляються про те, як його інтерпретувати. Для команд, які використовують мікс інструментів — наприклад, частина розробників сидить у VS Code з Cursor, інші працюють через Claude Desktop, — це критично важливо. Вони можуть ділитися скілами як звичайним кодом, не турбуючись про специфіку кожного клієнта.
Як NPX‑утиліта від Vercel спрощує встановлення скілів
Навіть із простою файловою моделлю залишається практичне питання: як швидко розгорнути скіл так, щоб його побачили різні хости? Особливо якщо кожен із них очікує трохи інший шлях до директорії або має власні конвенції.
Тут у гру вступає інструмент від Vercel — NPX skills tool. Він бере на себе роль «інсталятора» скілів, але робить це максимально прозоро: замість копіювання файлів утиліта створює симлінки в потрібні директорії для різних хостів.
Сценарій виглядає так: ви маєте репозиторій зі скілами або окрему папку з новим скілом. Запускаєте NPX‑команду, і утиліта розкладає симлінки так, щоб Claude, Cursor, Codeium, Claude Desktop та інші сумісні інструменти бачили цей скіл у своїх очікуваних шляхах. Фізично скіл продовжує жити в одному місці, але логічно він «присутній» у кількох середовищах одночасно.
Це важливо з двох причин. По‑перше, зникає ризик розсинхронізації: немає кількох копій одного й того самого SKILL.md, які можуть роз’їхатися. По‑друге, встановлення скілів стає настільки ж простим, як встановлення npm‑пакета: одна команда — і скіл доступний у потрібних інструментах. Для команд, які хочуть стандартизувати набір скілів на всіх робочих машинах, це фактично дає «менеджер пакетів» для AI‑поведінки.
Мінімалістичний глобальний контекст: навіщо тримати claude.md маленьким
Попри те, що skills дозволяють винести багато логіки в окремі модулі, глобальний контекст на кшталт claude.md нікуди не зникає. Але Nick Nisi свідомо тримає свій глобальний файл максимально маленьким.
Його підхід — використовувати глобальний claude.md не як енциклопедію всього, що він робить, а як тонкий шар метаналаштувань. Там зафіксовано, що відповіді мають бути лаконічними, без зайвої балаканини, а також описано особистий «ідеаційний» скіл — спосіб, у який агент має допомагати йому генерувати й структурувати ідеї.
Решта специфічних сценаріїв — аналіз репозиторіїв, робота з рекрутингом, будь‑які доменно‑орієнтовані задачі — виносяться в окремі скіли. Таким чином, глобальний контекст не перетворюється на звалище інструкцій, які потім важко підтримувати й які починають конфліктувати між собою.
Цей мінімалізм має ще один практичний ефект: зменшується навантаження на контекстне вікно моделі. Замість того щоб щоразу підвантажувати великий блок правил, агент отримує лише базові мета‑вказівки, а все інше підтягується тоді, коли LLM вирішує скористатися конкретним скілом. Це робить поведінку більш передбачуваною й дозволяє точніше контролювати, коли й які правила застосовуються.
Ідеація як скіл і Obsidian як довготривала пам’ять
Окремий пласт роботи Nick Nisi — це ідеація: генерація, уточнення й розвиток ідей, які не обмежуються одним проєктом. Для цього він використовує спеціальний скіл, який описує, як саме агент має поводитися під час таких сесій: як структурувати думки, які питання ставити, як фіксувати проміжні результати.
Ключовий момент — те, куди потім потрапляють артефакти цієї роботи. Nick маршрутизує їх в Obsidian vault — особисте сховище нотаток, яке використовується як крос‑проєктна база знань. Це дозволяє не втрачати напрацювання, зроблені в одному контексті, коли він переходить до іншого.
У такій схемі skills виступають не лише як «поведінкові модулі» для агента, а й як інтерфейс між LLM і системою довготривалої пам’яті людини. Скіл визначає, у якому форматі мають бути збережені результати ідеації, які поля обов’язкові, як позначати зв’язки з іншими нотатками. Obsidian, у свою чергу, стає місцем, де ці артефакти можна переглядати, редагувати, пов’язувати між собою й використовувати в нових сесіях.
Це показує, що skills — не лише про код і репозиторії. Вони можуть описувати й когнітивні процеси: як ви хочете думати разом із агентом, як фіксувати інсайти, як повертатися до них через місяці. А завдяки тому, що ідеаційний скіл глобальний, він доступний незалежно від того, над яким проєктом ви працюєте зараз.
Підключення зовнішніх сервісів: Slack, Notion і вбудована пам’ять Claude Desktop
Ще одна важлива грань екосистеми скілів — інтеграція з зовнішніми сервісами. Claude Desktop уміє підключатися до Slack, Notion та інших систем через конектори. Ці підключення можна використовувати всередині скілів, поєднуючи їх із вбудованою пам’яттю Claude про стиль роботи користувача й поточні проєкти.
На практиці це означає, що скіл може не лише оперувати статичним контекстом із SKILL.md, а й витягувати живі дані зі Slack‑каналів, нотаток у Notion чи інших джерел. Наприклад, рекрутинговий скіл, який Nick створював разом із командою рекрутингу WorkOS, агрегує дані про кандидата з кількох систем — Slack, Notion, рекрутингового ПЗ — і зводить їх в уніфікований звіт.
Важливо, що такий скіл не претендує на роль остаточного джерела істини. Він використовується як будівельний блок для створення чорнових звітів, які потім переглядають і допрацьовують люди. Але саме завдяки скілам і конекторам Claude Desktop може виконати важку рутинну роботу: зібрати розрізнені фрагменти інформації, привести їх до спільного формату, підсвітити прогалини.
У поєднанні з вбудованою пам’яттю Claude про те, як команда зазвичай формулює такі звіти, які критерії вважає важливими, які формати надає перевагу, це дає досить потужний інструмент. Скіл описує структуру й правила гри, конектори приносять дані, пам’ять моделі додає знання про стиль і пріоритети — і все це працює в одному агентському середовищі.
Локальні й глобальні скіли як основа масштабування агентів
Якщо подивитися на всю цю картину цілком, стає зрозуміло, чому WorkOS будує воркшоп саме навколо skills. Вони дають спосіб масштабувати агентні робочі процеси без втрати керованості.
Локальні скіли в .claude/skills всередині репозиторію дозволяють зашити в агентів специфіку конкретного коду: які фреймворки використовуються, які є внутрішні стандарти, як виглядають звіти чи рев’ю. Глобальні скіли в домашній директорії описують особисті й командні патерни, що повторюються в різних проєктах: ідеація, форматування відповідей, типові аналітичні задачі.
NPX‑утиліта від Vercel знімає біль встановлення й синхронізації, створюючи симлінки в потрібні місця для різних хостів. Підтримка з боку Claude, Cursor, Codeium і Claude Desktop робить цю модель крос‑інструментальною. А інтеграція з Obsidian, Slack, Notion і вбудованою пам’яттю Claude перетворює skills на міст між LLM і реальними робочими системами.
У результаті агенти перестають бути «чорною скринькою», якій щоразу доводиться пояснювати, як ви працюєте. Натомість з’являється чітко структурований шар поведінкових модулів, які можна версіонувати, ділитися ними, встановлювати через інструменти на кшталт NPX і використовувати в різних хостах. Це не магія, а радше дисципліна: замість того щоб покладатися на пам’ять моделі, ви явно кодуєте свої очікування в скілах і контролюєте, де й коли вони застосовуються.
Висновок
Модель skills, яку демонструють Nick Nisi та Zach Proser, показує, що майбутнє роботи з агентами — це не нескінченні «підказки в один рядок», а структурована інфраструктура. Просте правило розміщення скілів у .claude/skills локально й глобально, підтримка з боку кількох AI‑хостів, інсталятор від Vercel, інтеграція з Obsidian, Slack і Notion — усе це складається в цілісну екосистему.
У ній кожен скіл — це маленький, але чітко визначений шматок поведінки, який можна переносити між проєктами й інструментами. Агенти стають більш передбачуваними, команди — більш узгодженими, а глобальний контекст — чистішим і керованішим. Для розробників, які хочуть не просто «користуватися AI», а будувати на ньому стабільні робочі процеси, це, схоже, один із найпрактичніших шляхів уперед.