Як взаємодіють між собою компоненти Claude Code: Skills, Subagents, MCP, Hooks, Plugins

Що таке Claude Code з архітектурної точки зору

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

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

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

CLAUDE.md: постійний контекст проекту

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

• Фреймворк: Playwright з TypeScript
• Тести UI виконуються за допомогою npm run test:e2e, тести API — за допомогою npm run test:api
• Облікові дані ніколи не зберігаються у вигляді жорсткого коду
• Кожен новий кінець API потребує негативних тестів

Це дозволяє інженерам не пояснювати одні й ті самі конвенції знову та знову. Уявіть цей файл як відповідь на запитання "як працює цей проект?"

Файл має містити стабільні знання, які Claude потребує знову та знову: конвенції репозиторію, вимоги до тестування, принципи архітектури, команди для збірки, правила найменування, вимоги до безпеки та звички команди. Він не повинен перетворюватися на об’ємний посібник із кроковими інструкціями для кожного можливого завдання. Зручною межею є те, що CLAUDE.md вказує, що Claude має знати про проект, тоді як Skill описує, як виконувати певний тип роботи. Розділення їх полегшує технічне обслуговування та забезпечує більш чіткий контекст.

Skills: повторно використовувані навички

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

Наприклад, навичка тестування API може послідовно пройти через наступні етапи:

1. Визначити контракт API.
2. Перевірити вже існуючі тести.
3. Створити позитивні сценарії.
4. Створити негативні сценарії.
5. Створити межові випадки.
6. Виконати тести.
7. Проаналізувати невдачі.
8. Скласти звіт.

Якщо надійти з запитом на кшталт «додати покриття регресійних тестів для API оплат», цей навик не починає одразу писати код тестів. Він застосовує стандартну методологію тестування, тож кожен API тестується за однаковими організаційними стандартами.

CLAUDE.md проти навиків

Різниця полягає у контексті та процедурі. CLAUDE.md описує проект: тести API виконуються за допомогою Playwright, кожен ендпоїнт потребує негативних тестів, облікові дані отримуються з змінних середовища. Навик тестування API описує процедуру: перевірка контракту, створення позитивних, негативних та межових тестів, їх виконання та класифікація помилок. Один описує, що агент повинен знати, а інший — як йому виконувати роботу.

Підагенти: делегування спеціалізованих завдань

Підагенти — це спеціалізовані працівники, які виконують конкретне завдання в межах свого контексту та надсилають результати головному агенту. Головний агент може делегувати завдання підагенту для тестування інтерфейсу, підагенту для тестування API та підагенту з питань безпеки. Кожен з них незалежно досліджує свою сферу, а головний агент об’єднує їхні результати в остаточний вихідний продукт.

Чому не один великий агент?

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

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

Навичка проти підагента

Навичка описує як слід виконувати роботу, а підагент — хто виконує його спеціалізовану частину. Навичка тестування API визначає методологію організації. Підагент тестування API отримує певний API та аналізує його за допомогою відповідних інструкцій та інструментів.

Підагенти та вікно контексту

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

MCP та інструменти

Що таке MCP

MCP — це Model Context Protocol. Це механізм інтеграції, через який агент взаємодіє з зовнішніми системами та джерелами даних. З одного боку знаходиться Claude Code, а з іншого — GitHub, Jira, бази даних, API, браузери та системи моніторингу. Це дозволяє агенту виходити за межі локального середовища програмування та взаємодіяти з системами, які використовуються протягом усього життєвого циклу розробки.

Інженерія програмного забезпечення рідко обмежується роботою в редакторі. Розробнику може знадобитися Jira для формулювання вимог, GitHub для зберігання вихідного коду та подання запитів на з’єднання, бази даних для перевірки, системи моніторингу для виявлення помилок у продакшені та API для керування поведінкою додатку. Завдяки MCP робочий процес може читати тикети в Jira, переглядати відповідні репозиторії, визначати API, генерувати тести, їх запускати та створювати запити на з’єднання. Агент для програмування стає частиною ширшого інженерного процесу.

MCP проти інструментів

Це не одне й те саме. MCP — це протокол або шар інтеграції, а інструмент — це конкретна функція, яку агент може викликати. Сервер Jira MCP може надавати доступ до get_issue(), search_issues() та create_comment(). Ці функції є інструментами, а MCP — це спосіб, яким вони стають доступними. Коротко кажучи, MCP — це механізм підключення агента, а інструмент — це те, що він може робити.

Які інструменти надаються агенту

Інструменти дозволяють агенту виконувати дії. Без них ШІ переважно аналізує та формулює текст. З ними він може читати файли для розуміння реалізації, шукати у репозиторії відповідний код, редагувати файли для зміни поведінки, виконувати команди для тестування, читати результати для діагностики проблем, знову редагувати їх для їх виправлення та перевіряти результати знову. Інструменти перетворюють генератор відповідей на активного учасника інженерної роботи.

Види інструментів

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

• Інструменти спостереження читають, шукають та аналізують інформацію.
• Інструменти дії записують, редагують та виконують дії.
• Інструменти інтеграції дозволяють підключатися до зовнішніх платформ.
• Інструменти делегування звертаються до спеціалізованих агентів.

Разом вони дозволяють системі спостерігати за своїм середовищем, приймати рішення, діяти та перевіряти результати.

Хуки, команди та плагіни

Хуки

Хуки забезпечують детерміністичну, орієнтовану на події автоматизацію. Навичка може наказати Claude виконувати тести на регресію під час тестування API. Хук працює інакше: щоразу, коли відбувається певна подія, автоматично виконується перевірка. Наприклад, після зміни коду хук може запустити форматувальник, потім перевірку на наявність помилок, а потім цільові тести, і повернути результати перевірки. Це корисно, коли певні інженерні процедури мають виконуватися щоразу.

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

Чому хуки важливі в продакшені

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

Команди

Команди — це явно ініційовані робочі процеси, такі як /review, /test та /debug. Введення /review навмисно запускає заздалегідь визначений робочий процес перегляду коду. Команда означає: «Я явно хочу запустити цей робочий процес».

Команди є ініційованими користувачем, тоді як хуки — ініційованими подією. Введення /test є явною командою. Зміна вихідного коду та автоматичне виконання тестів у відповідь є автоматизацією, заснованою на подіях. Отже, команда активується людиною, а хук — подією.

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

Плагіни

Плагіни пакетують та розповсюджують розширення. Уявіть собі організацію з тестування, яка створила інструменти для тестування API, тестування безпеки, підагентів для API та безпеки, механізми перевірки та інтеграції MCP. Замість того, щоб кожен розробник створював це середовище заново, усі ці елементи постачаються разом як один плагін.

Саме тому плагіни мають велике значення для корпорацій. Вони піднімають практику проєктування з рівня особистої продуктивності до рівня організаційних можливостей. Якщо немає спільного пакетування, кожен інженер змушений налаштовувати середовище ШІ по-різному. Стандартний плагін може об’єднувати стандарти інженерії, методи тестування, спеціалізовані агенти, правила автоматизації та інтеграції, тож кожен проєкт отримує ідентичні можливості. З точки зору архітектури плагіни належать до шару управління та стандартизації.

Як взаємодіють компоненти

Одна стисла схема призначає кожному компоненту певну функцію:

• CLAUDE.md знає проект.
• Навички знають, як працювати.
• Підагенти виконують делеговану спеціалізовану роботу.
• Інструменти виконують дії.
• MCP підключається до зовнішніх систем.
• Hooks автоматизують події життєвого циклу.
• Команди запускають робочі процеси за потреби.
• Плагіни пакують та розповсюджують можливості.

Claude Code знаходиться посередині та координує їх. Вони вирішують різні архітектурні проблеми та не є взаємозамінними функціями.

Один робочий процес від початку до кінця

Візьмемо вимогу «додати покриття регресійних тестів для нового API оплат». Ймовірний перебіг виглядає так:

1. Вимога. Claude Code отримує запит.
2. Контекст проекту. Файл CLAUDE.md містить стандарти тестування, команди, правила роботи з репозиторіями та вимоги до безпеки.
3. Вибір навичок. Навичка тестування API забезпечує методологію організації.
4. Делегування. Спеціалізовані підагенти аналізують функціональність API, проблеми безпеки та наслідки регресії.
5. Інтеграції. Системи, підключені через MCP, надають доступ до відповідних зовнішніх платформ.
6. Інструменти. Claude Code читає код, шукає файли, створює тести та виконує команди.
7. Валідація. Функції-гачки виконують перевірку форматування, форматування коду, цільові тести чи інші перевірки.
8. Перевірка. Claude оцінює результати та вирішує, чи потрібна додаткова робота.
9. Кінцевий результат. Агент повертає тести, їхні результати, документацію та узагальнення того, що було виконано.

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

Цикл агента

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

На практиці процес наближається до послідовності: контекст, дія, перевірка, корекція, знову перевірка, а потім завершення. Саме ця ітерація відрізняє надійного агента від системи для створення коду одноразово.

Проектування середовища для тестування ШІ

Міцна архітектура SDET у Claude Code може поєднувати:

• CLAUDE.md разом із фреймворками тестування, архітектурою, стандартами тестування, правилами безпеки та критеріями завершення роботи.
• Навички тестування API, інтерфейсу користувача, регресійного тестування та аналізу несправностей.
• Підагентів для роботи з інтерфейсом користувача, API, безпекою та регресійним тестуванням.
• Інструменти для пошуку у репозиторіях, редагування файлів, виконання команд та запуску тестів.
• З’єднання MCP з GitHub, Jira, базами даних, API та системами моніторингу.
• Хуки, які виконують форматування, перевірку коду, тести та верифікацію після змін.
• Команди на кшталт /api-test, /regression, /security-review та /debug.
• Плагін, який об’єднує все це в єдине ціле, щоб кілька інженерних команд могли його повторно використовувати.

Оркестратор координує ці елементи відповідно до вимог.

Вибір правильного механізму

П’ять запитань допомагають визначити оптимальний елемент для виконання завдання.

• Чи йдеться про знання, які можна повторно використовувати для виконання завдання? Використовуйте Навичку.
• Чи потрібен спеціалізований, автономний працівник? Використовуйте Підагента.
• Чи має агент виконувати певну операцію? Використовуйте Інструмент.
• Чи залежить дія від зовнішньої платформи чи джерела даних? Розгляньте варіант MCP.
• Чи потрібно щось автоматично запускатися щоразу, коли відбувається подія життєвого циклу? Використовуйте Хук.

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

Основний урок

Успішна розробка агентів не залежить переважно від більшого чи розумнішого LLM. Для функціонування системи потрібно координувати кілька функціоналів:

• Контекст — щоб агент розумів проект.
• Навички — для забезпечення послідовної експертизи.
• Делегування — оскільки складні завдання можуть потребувати спеціалізованих працівників.
• Інструменти — щоб агент міг діяти.
• Інтеграція — для доступу до зовнішніх інженерних систем.
• Автоматизація — щоб обов’язкові процеси виконувалися надійно.

Перевірка — щоб з’ясувати, чи дії справді спрацювали.

Пакування — щоб можливості можна було повторно використовувати в різних командах.

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