Підприємець і розробник Остін Марчезе, який працює з Anthropic Claude та навчає інших будувати власні AI‑системи, пропонує доволі конкретний шаблон: як перетворити Claude Code на самонавчальну платформу, починаючи з правильної структури знань. Центральний елемент цього підходу — LLM knowledge base у стилі Андрія Карпатого, організована в проєкті Claude Code з чітко розділеними «raw» та «wiki» шарами, описана в системному файлі claw.md і підсилена базовими утилітарними скілами.

База системи: спочатку — проєкт, потім усе інше
Перший крок у рамках його п’ятиетапного BUILD‑фреймворку називається очевидно — BASE. Ідея проста, але для багатьох нетипова: замість одразу «кидатися в промпти» потрібно створити стійку рамку, у якій система зможе покроково ставати розумнішою.
Марчезе формулює це так: спочатку треба створити проєкт. Саме там зберігатимуться всі дані, які з часом будуть покращуватися. Цей проєкт складається з двох основних частин: власне knowledge base, де зберігається інформація, і набору skills, які дозволяють працювати з Claude Code у рази швидше за рахунок стандартизованих задач.
У фокусі цього етапу — перша частина, знаньова база. Автор спирається на підхід, який зробив віральним Андрій Карпатий: LLM knowledge base з чітким розмежуванням між «сирими» даними та стиснутим, структурованим шаром для моделі.
Структура raw/wiki: Karpathy‑подібна карта для моделі
Serце проєкту — двошарова структура папок, знайома тим, хто стежив за експериментами Карпатого. Суть підходу Марчезе передає компактно: є папка raw, яка містить усі сирі ресурси, що інгестуються в систему, і є папка wiki, яка посилається на файли в raw і допомагає AI розуміти, де саме шукати потрібну інформацію.
У raw потрапляють необроблені джерела: наприклад, це може бути запис розмови чи транскрипт дзвінка. Ці файли не оптимізовані для прямого використання моделлю, але є повним фактичним шаром даних.
Wiki виступає надбудовою: там зберігаються файли, які не дублюють повний вміст raw, а радше вказують, які саме ресурси є релевантними для конкретного запиту чи домену. Марчезе пропонує мислити про wiki як про зміст у книжці, який дозволяє моделі знайти потрібну главу без читання всього тому від корки до корки.
Ця аналогія важлива для розуміння, навіщо взагалі потрібен такий поділ. Claude (як і будь‑яка LLM) може опрацьовувати великі обсяги тексту, але вартість і якість відповідей сильно залежать від того, наскільки влучно користувач спрямовує її до правильних фрагментів. Wiki‑шар, який посилається на raw, — це спосіб дати моделі карту, а не змушувати її кожного разу блукати по всьому корупусу.
Марчезе навіть показує промпт, який допомагає розгорнути таку структуру з нуля чи інтегрувати її в уже існуючий проєкт Claude Code. Але ключ для нього не в самому коді, а в дисципліні: будь‑який новий ресурс повинен потрапити спочатку в raw, а потім бути «підхопленим» wiki‑шаром.
claw.md як «пам’ять» про рамку для Claude
Щоб Claude стабільно дотримувався цієї архітектури, одного дерева папок замало. Марчезе пропонує закріпити правила гри в системному файлі claw.md, який лежить у проєкті Claude Code.
Цей файл він описує як постійне нагадування Claude про те, як усе влаштовано. У claw.md фіксується, що є папка raw, є папка wiki, як вони пов’язані, які принципи інгесту й оновлення даних, який сенс мають ті чи інші файли.
Ідея в тому, щоб не покладатися на те, що модель «здогадається» про структуру, а чітко задекларувати її в єдиному джерелі правди. Claude, працюючи в межах цього проєкту, може щоразу звертатися до claw.md і «освежувати в пам’яті», як влаштована база знань і як із нею слід поводитися.
Окрема користь цього підходу в тому, що claw.md дисциплінує не лише модель, а й самого розробника. Як тільки структура чи правила змінюються — їх потрібно відобразити в одному місці. Це зменшує ризик дрейфу, коли через кілька тижнів проєкт перетворюється на набір папок, сенс яких уже ніхто не пам’ятає.
Навіщо перетворювати повторювані дії на skills
Друга частина базового кроку — це skills для повторюваних задач. Марчезе формулює жорстке, але практичне правило: якщо ви робите одну й ту ж дію з Claude двічі, для неї має існувати skill.
Skill у цій моделі — це спосіб один раз чітко описати, як саме Claude повинен обробляти конкретне завдання, і більше не витрачати час на ручне «виторговування» однакових кроків через промпти. Це означає не лише економію часу, але й зменшення варіативності: кожне повторне виконання задачі дає передбачуваніший результат, на який потім можна будувати автоматизацію й self‑improvement.
Марчезе наголошує, що процес обробки задачі в скілі завжди один і той самий. Це відрізняє skill від разової промпт‑сесії: у першому випадку зафіксовано послідовність дій, формат входу й виходу, вимоги до якості, а не лише загальне формулювання типу «підсумуй цей документ».
Саме skills, на його думку, дозволяють «під’єднатись» до бази знань так, щоб у майбутньому orchestration‑шари могли комбінувати ці атомарні утиліти в більш складні процеси.
Перший обов’язковий skill: add new resource
У наборі утилітарних скілів Марчезе виділяє один, який ставить на перше місце з кожною людиною, з якою працює: add new resource. Це, по суті, «ворота» для будь‑якого нового контенту.
Цей skill описує, як саме потрібно додавати новий файл до системи. Ланцюжок виглядає так: береться сирий файл, він інгестується в папку RAW, після чого Claude аналізує його і оновлює або створює відповідні wiki‑записи, які мають на нього посилатися.
Таким чином, add new resource одночасно вирішує дві задачі. По‑перше, гарантує, що жоден новий ресурс не «зависне» десь поза структурою знань. По‑друге, автоматично підтримує в актуальному стані wiki‑шар, не змушуючи користувача вручну створювати й оновлювати короткі огляди чи індекси.
Марчезе підкреслює функціональність цього підходу: Claude не просто зберігає файл у raw, а проводить над ним аналітику, виявляє, де він доречний у контексті всієї бази знань, і відповідно оновлює wiki. Для self‑improving системи це критично: саме тут модель отримує можливість поступово краще структуровувати світ користувача.
Утилітарні skills як будівельні блоки для orchestration
На цьому етапі система ще не «самоудосконалюється» у повному сенсі, але вже має фундамент для складніших сценаріїв. Марчезе прямо говорить, що такі утилітарні skills, як add new resource, знадобляться пізніше, коли мова зайде про orchestration‑скіли.
Orchestration‑скіли він розглядає як вищий рівень: це навички, які викликають кілька утилітарних skills, об’єднуючи їх у більший вивід. Простіше кажучи, замість того щоб окремо запускати «додай новий ресурс», потім ще один skill для аналізу, ще один — для оновлення оглядів, orchestration може виконати цей сценарій під одним викликом.
Але щоб orchestration працював надійно, базові skills повинні бути стабільними, добре протестованими і чітко описаними. Саме тому Марчезе приділяє стільки уваги першому кроку BASE: без якісної knowledge base і базових утиліт подальша автоматизація перетворюється на хаос.
У підсумку картина така: LLM knowledge base за мотивами Карпатого дає структурований простір із raw/wiki‑шарами, claw.md цементує правила цієї архітектури для Claude, а базові skills, на кшталт add new resource, роблять потік оновлень відтворюваним. На цьому фундаменті вже можна будувати складніші петлі самооптимізації — але це наступні етапи, які виходять за межі стартової конфігурації знаньової бази.
Джерело
YouTube — How to Build A Self-Improving System with Claude Code


