Так, все так само

Ви можете описати свого агента в будь-якому файлі у вашому репозиторії. Наприклад файл зветься «Instructions.md», а всередині файлі щось типу: «Клод, подивися на логи ось тут, а також використай grafana mcp, щоб подивитися на ось цей дашборд, потім прочитай такий-то файл, а потім ....».

Тут виникає питання: Як клод дізнається коли використати ці інструкції? Вам потрібно буде кожного разу додати цей файл в контекст руками, і казати виконувати ці інструкції.

Синтаксис склів це спрощує. Обовʼязхково вказати name, description, ну і саме тіло скіла.

Получається коден скіл може створбвати паралельні процеси і стати агентом?

Паралельні процеси можна запускати і без скілів, напряму в Claude Code. Просто скажіть клоду щось типу: Launch subagent to research this part of the system. Subagent should present a comprehensive review in result.

Таким чином, ви, через головного агента, запускаєте під-агента.
Для чого це? Швидкість (якщо можна запустити агентів в паралелі) + незабите контекстне вікно головного агента.

Скіл — це просто інструкції для виконання клодом, тому там також можна сказати щоб запустити агентів в паралелі. Ось так: gist.github.com/...​d0ee0#main-agent-workflow

цього достатньо щоь описати агента в клод?

SKILL.md достатньо, щоб описати якийсь конкретний скіл, для виконання якоїсь конктретної задачі.

агент це один з скілів?

Агент — це Claude code. Він вміє виконувати доволі комплексні завдання, ранити тести, шукати щось в інтернеті, працювати з файловою системою.

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

Моя ментальна модель така:
Claude code — це ерудована і дуже працьовита людина, яка може виконувати різні завдання, якщо їй все гарно пояснити. Для кращих результатів потрібно дати Клоду можливість перевіряти результати своєї праці (feedback loop).
Skill — це Claude code з проф-підготовкою в якійсь конкретній області. Він чітко знає коли починати роботу, що саме робити, які інструменти використовувати, і що очікують в результаті.

То опис вашого агента виконується в тому SKILL.md файлі?

Саме так — ось це головний файл gist.github.com/...​724a656507f8966bdb05d0ee0.

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

І ще питання, ці агенти трейсяться, наприклад подивитись виклики LLM? Ну і взагалі, що розуміти що відбувається під капотом.

Так, можна (і деколи дуже корисно, щоб зрозуміти його поведінку).
На моєму скріншоті (в пункті Переваги такої архітектури) Клод каже що можна натиснути ctrl-o, щоб подивитися повний хід виконання, із запитами, відповідями, reasoning і тд

Я думав скіли завантажуються через Claude API і раняться на Claude VM.

Ні — скіли живуть поруч з агентом, їх можна додати як і в звичайний додаток Claude Desktop так і використовувати в Claude Code.
Тобто який процес:
1. Ви встановлюєте на машині Claude Code — agentic coding assistant. Claude Code вміє робити якісь базові речі: читати/писати файли, шукати в інтернеті, робити запити на external api через curl і тд. Ви також можете розширити його вміння встановиши різні MCP — наприклад Grafana MCP.
2. Якщо у вас є якась повторювана задача (протестувати UI, траблшутити історичний кластер, перевірити PR і тд) — вам більше не треба описувати всю послідовність дій щоразу в новому контекстному вікні. Ви створюєте SKILL.md, з описом і інструкціями для клода, що він повинен зробити в якійсь ситуації (візьми такі-то логи, перевір те і те, і зроби висновок)

Наприклад в нас, я описав у файлі (gist.github.com/...​724a656507f8966bdb05d0ee0), що скіл Клод має заюзати цей скіл, якщо в нього запитають про history collection pipeline. І він буде виконувати ці інструкції.

Гарне питання!
У нас зараз з цим менше проблем, бо ранимо агента на локальних машинах, а не в клауді. Для Grafana mcp кожен інженер має свій токен, а логи еластіка та внутрішній API доступні через закриті внутрішні ендпоінти.

А ви як це вирішуєте ?

Чому? Для моніторінгу у нас є логи, метрики, алерти і тд, а цей пост про те, що Агент може це все взяти, синтезувати, повʼязати між собою — і визначати корінну проблему. Це ж якраз про Observability.

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