Skip to content
← Усі розділи

Розділ 04

Скіли та агенти

DWP незалежний від агента, але він очікує два повторювані будівельні блоки — скіли й агенти — та свідомий спосіб зорієнтуватися в репозиторії, перш ніж почнеться будь-яка робота.

Скіли проти агентів

Ці два поняття легко сплутати, але вони слугують різним цілям:

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

Корисне правило: скіл — це як виконати повторюване завдання; агент — це хто відповідає за клас роботи.

Живий набір: репозиторій вирощує власні скіли

Онбординг перетворює репозиторій на harness агента; він не заморожує його. Набір призначений зростати, у міру того як робочі процеси репозиторію стають зрозумілими. DWP надає суб-скіл author — що викликається через /skill-create та /agent-create — який міркує про наявну структуру .agents/ та домовленості репозиторію, а потім пише новий скіл, агент чи тонкий делегатор команди, що їм відповідає. Репозиторій сам створює власний набір, а не успадковує загальний.

Суб-скіл author свідомо ставиться до доречності. Він створює скіл для повторюваної процедури, яку люди виконують вручну, агент — для повторюваної ролі з окремими потребами в моделі чи інструментах, а команду — лише як тонку точку входу, що скеровує до скіла чи агента. Він пропускає все загальне, що не відповідає реальному робочому процесу, і тримає каталог .agents/docs/ синхронізованим із тим, що додає. Той самий суб-скіл забезпечує обовʼязкове завдання Skills & Agents Discovery, яке узгоджує каталог із тим, що насправді є на диску — а /dwp-verify підтверджує це узгодження обʼєктивно, не проходячи, якщо каталог і файли розходяться.

Addon обслуговування

Окрім авторства, DWP постачає опціональні addon обслуговування — ніколи не обовʼязкові для того, щоб репозиторій був AI-first. Addon dependency-upgrade — канонічний приклад: він міркує про реальний менеджер пакетів репозиторію (npm, pnpm чи yarn із ncu; pip, poetry чи uv; Cargo; Go modules; Bundler; Composer), а не припускає його, потім оновлює невеликими партіями, запускає реальний валідаційний gate репозиторію після кожної партії, відкочує будь-яку партію, що не пройшла, і підсумовує без автоматичного коміту. Addon приймаються явно під час онбордингу; відмова від одного лишає репозиторій повністю відповідним.

Онбординг репозиторію на основі міркувань

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

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

Каталог .agents/ та символьне посилання .claude → .agents

DWP збирає все, що визначає поведінку агента — скіли, команди, визначення агентів, внутрішню документацію та налаштування — в одному канонічному каталозі, .agents/. Назва сигналізує, що вміст поділяється між агентами, а не привʼязаний до якогось одного інструмента.

Для зворотної сумісності з інструментами, які історично читали з .claude/, цей шлях є символьним посиланням на .agents/:

ls -la .claude
# .claude -> .agents

Кожен шлях .claude/... прозоро розвʼязується у свій еквівалент .agents/..., тож старіша інструментальна оснастка продовжує працювати, а новий вміст посилається на канонічне розташування .agents/. Скіли й агенти редагуються через реальні файли в .agents/, ніколи через символьне посилання.