Як навчити Cowork своїй роботі: кастомний скіл для записів і задач

Олексій Павленко, Head of AI у компанії Clast, поділився практичним підходом до того, як навчити AI-інструменти працювати не просто як чат, а як частину робочої системи. У фокусі виступу були Claude Code, Obsidian, skills, структура папок, naming, metadata та побудова контекстного шару, без якого AI швидко починає помилятися, вигадувати або давати нестабільний результат.

Головна ідея виступу проста: AI стає справді корисним не тоді, коли йому дають “розумний промпт”, а тоді, коли навколо нього побудовано систему знань, правил і контексту. Без цього кожна нова сесія починається з нуля, кожен результат виглядає по-різному, а передати процес іншій людині майже неможливо.

Чому AI не працює без вашої логіки

Одна з найтиповіших проблем у роботі з AI — це очікування, що інструмент сам зрозуміє, як саме працює команда, бізнес або конкретна людина. На практиці цього не відбувається. Якщо не описати власну логіку роботи, AI щоразу буде починати з пояснення: хто користувач, над чим він працює, які формати йому потрібні, які правила застосовувати.

Олексій Павленко виділяє кілька симптомів такої проблеми. Кожна сесія починається з повторного пояснення контексту. AI щоразу видає текст у новому форматі. Після мітингу все одно потрібно витрачати час на оформлення задач і follow-up. Навіть “розумні” промпти, у яких намагалися передбачити все, ламаються на нестандартних кейсах. А сам робочий процес дуже важко передати іншій людині, тому що він тримається не на системі, а на ручних поясненнях.

Саме тому робота з AI має бути ітеративним процесом. Спочатку потрібно описати, як людина або команда працює. Потім — створити структуру, у якій AI може цю логіку бачити. І лише після цього можна очікувати стабільних результатів.

Приклад робочого процесу: мітинги, транскрипти і follow-up

Як практичний сценарій Олексій Павленко розглядає обробку мітингів. Це знайома проблема для більшості команд: зустрічей багато, не завжди є час зробити якісне summary, зафіксувати рішення, сформувати action items і перенести домовленості в задачі.

Сучасні інструменти — Zoom, Google Meet, BlueDot та інші — уже вміють створювати транскрипти. Але сам транскрипт ще не вирішує проблему. Його потрібно покласти в правильне місце, обробити, виділити summary, decisions, action items, відкриті питання, пов’язати з людьми, проєктами й попередніми домовленостями.

У запропонованій архітектурі транскрипт після мітингу потрапляє в окрему папку в Obsidian. Далі Claude Code запускає відповідний skill, який обробляє нотатки: формує summary, виділяє рішення, створює наступні кроки, додає інформацію до потрібних областей і таким чином перетворює сирий транскрипт на структурований робочий артефакт.

Чому Obsidian стає основою системи знань

Obsidian у цьому підході використовується не просто як нотатник, а як локальна база знань. Технічно це звичайна папка з Markdown-файлами, але саме в цьому і є сила: файли локальні, портативні, не прив’язані до конкретного сервісу і можуть бути версіоновані.

Obsidian дозволяє працювати зі структурою папок, зв’язками між файлами, metadata, graph view, пошуком і плагінами. Це зручно для побудови власного “vault” — робочого простору, у якому зберігаються мітинги, люди, проєкти, рішення, задачі та інші сутності.

У прикладі, який розглядався у виступі, структура може включати:

Inbox — сирі транскрипти мітингів;
Meetings — оброблені зустрічі;
People — люди, які брали участь у зустрічах або згадувалися;
Projects — проєкти;
Decisions — прийняті рішення;
Actions — наступні кроки й задачі.

Ця структура може бути будь-якою, але важливо, щоб вона відповідала реальній логіці роботи конкретної людини або команди.

Які плагіни потрібні для Obsidian

Для такого workflow Олексій Павленко виділяє кілька базових плагінів.

Перший — Templater. Він потрібен для створення файлів за шаблонами. Якщо AI обробляє мітинг або створює задачу, важливо, щоб усі такі файли мали однаковий формат. Це зменшує хаос і дозволяє іншим skills стабільно працювати з цими артефактами.

Другий — Dataview. Він дозволяє робити запити до структури vault, схожі на SQL-запити. Завдяки цьому можна витягувати інформацію за проєктами, людьми, статусами, датами чи іншими metadata.

Третій — Smart Connections. Це векторний пошук, який допомагає знаходити пов’язані документи не лише за точним збігом слів, а й за змістом. Якщо у vault багато мітингів, людей і проєктів, це дозволяє швидко зрозуміти, про що говорили з конкретною людиною, які були домовленості й які відкриті питання залишилися.

Також корисним може бути QuickAdd для швидкого створення файлів, шаблонів і hotkeys.

Що таке Claude Code Work і чим він відрізняється від звичайного чату

Claude Code Work у цьому підході не розглядається як аналог ChatGPT із пам’яттю. Це локальний агент на комп’ютері, який працює з файлами користувача й може виконувати конкретні операції.

Звичайний чат добре підходить для режиму “питання — відповідь”. Але Claude Code Work потрібен для іншого: виконання задач, роботи з vault, запуску skills, обробки файлів і багатокрокових workflow.

Ключова різниця в тому, що Claude Code Work працює не лише з контекстом поточного чату, а з локальним файловим середовищем. Він може відкривати файли, змінювати їх, створювати нові, запускати skills і виконувати послідовність дій.

Саме тому до нього потрібно ставитися не як до чату, а як до робочого агента, якому потрібні правила, обмеження і контракти.

Skill — це не промпт, а контракт

Одна з найважливіших тез виступу: skill — це не просто промпт. Це контракт.

У skill має бути чітко описано:

коли він активується;
з якими вхідними даними працює;
що має зробити;
чого не має права робити;
який формат результату повинен створити;
які обмеження має враховувати.

Наприклад, skill для обробки мітингу отримує на вхід нотатки або транскрипт. У файлі мають бути дата, учасники й сам текст зустрічі. На виході skill має створити summary, decisions, action items, відкриті питання і наступні кроки.

Також мають бути обмеження: не вигадувати дедлайни, не додавати рішень, яких не було в обговоренні, зберігати мову входу у мові виходу, не створювати зайві сутності без потреби.

Саме обмеження є критично важливими. Олексій Павленко наголошує, що в роботі з Claude Code Work потрібно змінити mindset: важливо описувати не тільки те, що AI має зробити, а й те, чого він не має права робити. Оскільки агент фізично може відкривати файли, редагувати їх або видаляти частини, негативні правила стають не менш важливими, ніж позитивні інструкції.

Персональні й глобальні skills

Skills можуть бути персональними або глобальними.

Персональний skill працює в межах конкретного vault. Він знає структуру папок, naming, правила конкретної людини або команди. Такий skill активний у конкретних сесіях і підлаштований під конкретний робочий процес.

Глобальний skill доступний у будь-якій сесії Claude Code Work. Він не залежить від конкретної папки й підходить для універсальних задач. Якщо компанія використовує Team або Enterprise-підписку, такі skills можуть встановлюватися для всієї організації.

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

Memory і skills: різні шари системи

Олексій Павленко також розділяє memory і skills.

Memory — це вподобання і знання про користувача. Вони завантажуються автоматично, постійно перебувають у контексті й описують, як саме працює конкретна людина.

Skills — це інструкції для конкретних типів задач. Вони активуються за потреби, часто через тригерні слова або явний запуск, і описують, як виконати конкретний workflow.

Якщо memory відповідає на питання “хто користувач і як він працює”, то skill відповідає на питання “що робити з конкретною задачею”.

Чому naming — це не косметика, а архітектура

Велика частина виступу була присвячена naming. На перший погляд це дрібниця, але в системі знань naming перетворюється на один із головних архітектурних елементів.

У Obsidian назва файлу може одночасно виконувати роль:

primary key;
foreign key;
label у graph view;
точки пошуку;
навігаційного індексу.

Якщо в назві файлу є scope, type, topic і date, то AI, плагіни й людина можуть швидко зрозуміти, що це за файл, до чого він належить і як його знайти.

Це особливо важливо при великій кількості мітингів. Якщо всі файли названі хаотично, vault швидко перетворюється на смітник. Якщо naming стабільний, сама назва файлу вже стає частиною системної архітектури.

Frontmatter як “API” для AI і плагінів

Ще один важливий елемент — frontmatter. Це YAML-блок на початку Markdown-файлу, де зберігаються metadata.

Наприклад, у frontmatter можна записати:

дату;
учасників;
проєкт;
тип файлу;
статус;
джерело;
відповідального;
пов’язані сутності.

Для Obsidian, Dataview, Smart Connections і AI це працює як публічний API до файлу. Завдяки frontmatter система може не просто читати текст, а розуміти структуру даних.

Але frontmatter має бути валідним. Якщо YAML зламаний або написаний хаотично, skill може помилитися, Dataview не зможе правильно зробити запит, а AI буде змушений вгадувати.

Як AI знаходить потрібну інформацію у vault

Пошук у такій системі працює каскадно.

Спочатку використовується назва файлу. Якщо користувач запитує про конкретний мітинг або людину, система може швидко знайти файли за naming-патерном.

Далі використовується frontmatter. Через Dataview або прямий парсинг metadata можна відфільтрувати мітинги за датою, людьми, проєктами чи статусами.

Третій рівень — Smart Connections, тобто семантичний пошук. Він шукає не лише буквальні збіги, а й змістовно схожі фрагменти.

Це важливо, тому що без таких рівнів AI довелося б завантажувати весь vault у контекст. Якщо там тисячі файлів, це повільно, дорого й неефективно. Структура, naming і metadata дозволяють AI брати тільки потрібну частину знань.

Що відкриває правильно побудований vault

Коли мітинги, люди, проєкти, рішення й action items структуровані, з’являються набагато сильніші сценарії роботи.

AI може відповідати на питання:

про що була розмова з конкретною людиною за останній тиждень;
про що домовилися на останньому мітингу;
які action items залишилися відкритими;
що потрібно підготувати до наступної зустрічі;
які рішення прийняті по конкретному проєкту;
які задачі повторюються найчастіше.

Фактично Obsidian vault перетворюється на внутрішню базу даних компанії або конкретної людини, а Claude Code Work стає агентом, який вміє цю базу обробляти.

Чому без методології інструменти не допоможуть

Окрема важлива думка: самі інструменти не створюють систему. Можна купити найкращі підписки, підключити всі модні AI-сервіси, встановити Obsidian і Claude Code Work, але якщо немає naming, metadata, структури й контрактів для skills — усе швидко перетвориться на хаос.

Obsidian без naming — це просто смітник файлів. Claude Code Work без skills — це звичайний чат із файлами. Skills без контракту — це просто промпти, які легко ламаються. Контракти без metadata змушують AI вгадувати. А без документації через два тижні ніхто не буде розуміти, як цим користуватися.

Тому головна цінність не в інструменті, а в тому, як він вписаний у робочий процес.

Які анти-патерни треба уникати

Олексій Павленко виділяє кілька типових помилок.

Перша — skill пише “куди завгодно”. Якщо не вказати, куди саме створювати файли, які папки використовувати й який output потрібен, результат буде хаотичним.

Друга — немає output format. У такому випадку AI створює нотатки щоразу по-різному, і наступні skills не можуть стабільно з ними працювати.

Третя — у файлах з’являється sensitive information, яку skill не вміє фільтрувати.

Четверта — skill залежить від контексту конкретного чату. Це погано, тому що в іншій сесії або на іншому комп’ютері він може не спрацювати.

П’ята — один skill робить п’ять різних речей. Це порушує принцип single responsibility. Один skill має відповідати за одну область або один тип задачі.

Шоста — немає обмежень. Якщо skill не знає, чого уникати, він може вигадувати, дублювати інформацію або змінювати зайве.

Skills потрібно тестувати й версіонувати

Оскільки skill — це контракт, його потрібно тестувати як API.

Потрібно мати тестові вхідні дані, перевіряти, чи skill не ламає стару логіку, чи не дублює інформацію, чи не створює неправильні артефакти.

Також важливо версіонувати skills. Має бути зрозуміло:

яка версія skill використовується;
що в ній змінилося;
який функціонал додано;
які нотатки вже оброблені;
коли потрібно відкотитися назад.

Для цього підходить класичний git-підхід: зміни фіксуються, історія зберігається, завжди можна повернутися до попередньої версії.

Як зрозуміти, що skill готовий

Готовий skill має відповідати кільком критеріям.

По-перше, input format має бути задокументований. Має бути зрозуміло, які файли він приймає і в якому форматі.

По-друге, output format теж має бути задокументований. Результат повинен бути стабільним і передбачуваним.

По-третє, мають бути приклади “до” і “після”.

По-четверте, skill потрібно протестувати хоча б на кількох реальних нотатках.

По-п’яте, інша людина на іншому комп’ютері має мати змогу запустити цей skill і отримати той самий результат. Якщо skill працює тільки “на моєму комп’ютері”, це ще не система.

Обмеження Claude Code Work

Попри силу такого підходу, у нього є обмеження.

Claude Code Work працює локально. Якщо комп’ютер вимкнений або ноутбук закритий, skills не виконуються. Scheduler може запускати skills за розкладом, але тільки поки система активна.

Також немає повноцінних event triggers, які автоматично реагують на всі події. Якщо потрібна справжня 24/7 автоматизація, потрібно додавати окремий фоновий шар, наприклад через n8n або подібні інструменти.

Ще одне обмеження — вартість контексту. Claude Code Work на сильних моделях може споживати багато токенів, тому важливо добре фільтрувати дані, не завантажувати весь vault і давати агенту тільки потрібний контекст.

Як виглядає повна архітектура

У повнішому варіанті архітектура виглядає так: scheduler або cron запускає процес, збирає дані, кладе їх в Obsidian, відкриває vault у Claude Code Work, запускає потрібний skill, skill обробляє мітинг і створює кілька артефактів. Після цього сесія завершується.

Стартовий набір може включати skill для обробки мітингів. Далі можна додавати skills для людей, проєктів, рішень, action items, рев’ю тижня, підготовки до зустрічей. У нормальній архітектурі наступні skills можуть використовувати результати попередніх skills і будувати більш складні сценарії.

Висновок

Підхід, який показує Олексій Павленко, демонструє важливий зсув у роботі з AI. Йдеться вже не про окремі промпти, а про побудову робочої системи, у якій AI має контекст, правила, структуру, пам’ять і чіткі контракти.

Claude Code Work, Obsidian і skills можуть перетворити хаотичні транскрипти, нотатки й документи на живу базу знань, яка допомагає готувати summary, фіксувати рішення, створювати action items, згадувати попередні домовленості й передавати процес іншим людям.

Але це працює тільки тоді, коли є методологія. Потрібні naming, metadata, структура папок, frontmatter, contracts, тестування й версіонування. Без цього навіть найкращі AI-інструменти швидко стають ще одним шаром хаосу.

Головна думка проста: AI не замінює вашу логіку. Він підсилює її. Але спочатку цю логіку потрібно описати, структурувати й навчити систему працювати саме за нею.