Скіл - це файл з інструкціями, який асистент читає перед задачею. Не код і не програма: звичайний текст, написаний так, як пишуть інструкцію молодшому колезі. Кроки, критерії, еталонні позиції, формат результату. Модель отримує цей текст у контекст - і виконує процес замість того, щоб щоразу вгадувати його з короткого запиту.
Скіл - один з шарів сетапу, поруч з постійними інструкціями і проєктами. Різниця в масштабі: інструкції задають стиль і формати взагалі, скіл описує один конкретний процес від входу до результату.
У юридичному плагіні Claude є набір готових скілів. Три з них показові, бо покривають типові процеси юрвідділу.
Рев'ю договору (review-contract). Вісім кроків: прийняти документ - зібрати контекст (чия сторона, дедлайн, фокусні питання) - завантажити playbook компанії - проаналізувати кожен суттєвий пункт за 12 категоріями, від ліміту відповідальності до форс-мажору - класифікувати відхилення світлофором - згенерувати редлайни за фіксованим форматом (поточна мова, пропозиція, обґрунтування, пріоритет, запасна позиція) - зібрати бізнес-підсумок зі стратегією переговорів у три рівні - запропонувати маршрут погодження.
Скринінг NDA (triage-nda). Швидша задача - швидший процес: десять груп критеріїв чеклістом (структура, обсяг визначення, стандартні винятки, строк, повернення інформації, заборонені положення) - і класифікація. GREEN: підпис за стандартним делегуванням, того ж дня. YELLOW: конкретні пункти юристу, одна ітерація правок, один-два дні. RED: не підписувати - повний перегляд або контрпропозиція своєю формою, три-п'ять днів.
Статус контрагента (vendor-check). Зведення договірних відносин з одним постачальником: пошук по всіх підключених системах - договірна база, CRM, пошта, сховище документів, робочі чати - таблиця знайдених договорів зі строками і автопродовженнями - gap-аналіз (є MSA, нема DPA, а персональні дані обробляються) - звіт з переліком того, що закінчується протягом 90 днів.
Три різні задачі - один скелет. Кожен скіл влаштований однаково:
| Рев'ю договору | Скринінг NDA | Статус контрагента | |
|---|---|---|---|
| Вхід | договір + контекст сторони | NDA | назва контрагента |
| Еталон | playbook позицій компанії | критерії скринінгу | перелік очікуваних договорів |
| Перевірка | 12 категорій пунктів | 10 груп критеріїв | пошук по всіх системах |
| Рішення | світлофор по кожному пункту | світлофор по документу | знайдено / прогалина |
| Вихід | редлайни + стратегія | звіт + маршрут | зведення + строки |
| Людина | погоджує редлайни | підписує або передає юристу | перевіряє за оригіналами |
Скелет читається з таблиці: прийом входу - еталон, з яким порівнюємо, - перевірка за списком - класифікація рішення - звіт з наступними кроками - людина в кінці. Жоден крок не є технічним. Це розбивка робочого процесу, записана текстом.
Найцінніша частина кожного з трьох скілів - не кроки, а еталон: playbook позицій, критерії скринінгу, перелік очікуваних договорів. Кроки універсальні і переносяться між компаніями. Еталон - ні: він і є експертизою конкретної фірми. Скіл без еталона працює за загальними ринковими стандартами і прямо про це попереджає.
Звідси практичний висновок для команди: щоб ці процеси працювали на вас, писати треба не промти, а свої еталони - позиції по пунктах договорів, критерії прийнятного NDA, перелік обов'язкових договорів для постачальника. Це звичайна юридична робота, яку фірма і так робить у голові. Скіл лише вимагає записати її.
Схема та сама, що в готових скілах, і вона збирається з відповідей на п'ять питань. Що приходить на вхід? З чим порівнюємо - де наш еталон? За яким списком перевіряємо? Які можливі рішення і хто їх ухвалює? Як виглядає результат - формат звіту, приклад?
Відповіді записуються текстом як інструкція молодшому колезі і зберігаються там, де їх підхопить асистент: скіл, збережений промт або файл у проєкті. Далі процес росте на помилках: кожен збій - рядок в еталон або крок у список. Через кілька ітерацій це вже сервіс: типові документи, скринінги і зведення виконуються за хвилини, а людина лишається там, де їй місце - на рішеннях.