Claude Code від Anthropic — це не просто «чат з ШІ в терміналі», а повноцінне середовище для роботи з кодом, яке можна налаштовувати під кожен окремий проєкт. У новому проміжному–просунутому гайді автор каналу Tech With Tim показує свій професійний сетап: як організовані конфігурації, як працюють скіли та сабагенти, і чому саме ці механізми відрізняють «іграшкове» використання Claude від справді виробничого.
Тут немає пояснень про встановлення чи перший запуск — сам автор прямо радить спершу подивитися окреме вступне відео, якщо ви ще не знайомі з базовим інтерфейсом Claude Code. Цей матеріал зосереджений на тому, як влаштована архітектура конфігурацій і як за її допомогою будувати проєктно‑орієнтовані, спеціалізовані AI‑воркфлови.
Прихована папка .claude: де живе «пам’ять» кожного проєкту
Ключ до того, щоб сприймати Claude Code не як один глобальний чат, а як набір окремих «мозків» для різних репозиторіїв, — це його файлове розташування конфігурацій. Коли інструмент працює в певній директорії, він автоматично створює там приховану папку .claude. Саме в ній зберігаються всі проєктно‑специфічні налаштування: від базових параметрів до кастомних скілів.
У прикладі з реального робочого проєкту, коли користувач переходить у директорію з кодом і виводить вміст із прапорцем для прихованих файлів, стає видно .claude. Усередині — зокрема файл settings.local.json. Це не просто технічна деталь: саме ця структура визначає, що Claude Code «пам’ятає» про конкретний проєкт і як поводиться в його межах.
Такий підхід дає кілька важливих наслідків для розробників:
По‑перше, конфігурація стає природною частиною репозиторію. Її можна версіонувати, переносити між машинами, ділитися з командою. Якщо в .claude зберігаються скіли, інструменти та інші налаштування, то клонуючи репозиторій, колеги отримують не лише код, а й готовий AI‑контекст для роботи з ним.
По‑друге, це дозволяє уникнути конфліктів між різними проєктами. Налаштування, які мають сенс для одного стеку чи домену, не «протікають» в інші каталоги. Claude Code поводиться по‑різному залежно від того, де саме ви його запускаєте, і це закладено в саму архітектуру.
По‑третє, така модель відкриває шлях до справді глибокої кастомізації: кожен проєкт може мати власний набір скілів, сабагентів та MCP‑інструментів, які відповідають саме його процесам розробки, а не абстрактному «середньому» сценарію.
Скоупи конфігурації: проєкт, користувач, глобальний рівень
Папка .claude — це лише один із рівнів, на яких Claude Code може зберігати налаштування. Інструмент підтримує кілька скоупів конфігурації: проєктний, користувацький і глобальний. Це особливо помітно на прикладі MCP‑серверів, але логіка поширюється і на інші елементи, які розглядаються в гайді.
Коли додається MCP‑сервер, за замовчуванням він прив’язується до поточного проєкту. Це означає, що конфігурація потрапляє саме в .claude всередині цієї директорії, і інші проєкти її не бачать. Для багатьох сценаріїв це правильна поведінка: наприклад, якщо MCP‑інтеграція стосується внутрішнього сервісу, який використовується лише в одному продукті.
Однак Claude Code дозволяє змінити цей скоуп. Для MCP‑серверів передбачені варіанти:
- проєктний рівень, коли інструмент доступний усім, хто працює з цим репозиторієм;
- користувацький (user) рівень, який фактично стає глобальним для конкретного розробника й робить сервер доступним у всіх його проєктах;
- локальний варіант за замовчуванням, коли конфігурація прив’язана до поточної директорії.
У випадку з GitHub MCP автор гайду прямо вказує: для такого інструмента логічно обрати глобальну доступність, додавши до команди параметр, що задає user‑скоуп. Це дозволяє одному й тому ж GitHub‑серверу працювати з будь‑яким проєктом, не дублюючи конфігурацію в кожній .claude‑папці.
Така багаторівнева система скоупів робить Claude Code схожим на сучасні IDE з профілями налаштувань, але з важливою відмінністю: тут конфігурація безпосередньо впливає на те, як ШІ сприймає контекст, які інструменти він вважає доступними і як будує свою поведінку.
Кастомні скіли та сабагенти: перехід від «чату» до керованих робочих процесів
У центрі просунутого використання Claude Code стоять два поняття: скіли та сабагенти. Саме вони, за задумом автора гайду, перетворюють інструмент із «розумного автодоповнення» на платформу для автоматизації професійних воркфловів.
Скіли в Claude Code — це, по суті, повторювані дії або шаблонні завдання, які можна формалізувати й зберегти як окремі інструкції. Вони можуть бути специфічними для проєкту, враховувати його структуру, стилістичні вимоги, особливості деплойменту чи тестування. Коли такі скіли зберігаються в .claude, Claude Code починає сприймати їх як частину «правил гри» саме для цього репозиторію.
Сабагенти — ще один рівень абстракції. Це спеціалізовані «під‑агенти» всередині Claude Code, які можуть бути налаштовані на конкретні ролі: наприклад, один відповідає за рефакторинг, інший — за написання тестів, третій — за інтеграцію з зовнішніми сервісами. Вони працюють поверх тієї ж конфігураційної архітектури, але дозволяють розділити поведінку ШІ на окремі, більш вузькі компетенції.
У відео скіли та сабагенти подаються не як другорядні «фішки», а як базові механізми для побудови професійного середовища. Просте спілкування з Claude у форматі чату дає лише частину можливостей. Коли ж конфігурація проєкту включає набір скілів і сабагентів, Claude Code починає працювати як оркестратор завдань, а не просто як генератор тексту.
Це особливо важливо в командних і довготривалих проєктах. Якщо в .claude закладено, наприклад, скіл для створення нових модулів за внутрішнім шаблоном, сабагент для рев’ю коду з урахуванням командних гайдлайнів і ще один — для роботи з документацією, то новий розробник, відкривши репозиторій, одразу отримує доступ до цих «вбудованих практик». AI‑поведінка стає частиною проєктної культури.
Контекст, MCP та «зайві» інструменти: чому важливо вимикати те, чим ви не користуєтеся
Просунуте налаштування Claude Code неможливе без розуміння того, як інструмент працює з контекстом. У гайді окремо розбирається команда /context, яка показує поточне використання токенів, системний промпт, підключені інструменти, скіли, повідомлення й вільний простір у вікні контексту.
На цьому фоні особливо помітною стає роль MCP‑інструментів. Claude Code може підключати одразу багато MCP‑серверів, кожен із власним набором інструментів. У результаті список активних MCP‑тулів у контексті може виявитися дуже довгим — особливо якщо користувач експериментує з інтеграціями на кшталт Zapier чи інших сервісів.
Саме тут звучить одна з найпрактичніших порад: невикористовувані MCP‑інструменти варто вимикати в межах конкретної сесії. Причин кілька.
По‑перше, кожен активний інструмент збільшує обсяг контексту. Claude має «знати» про їхнє існування, щоб у разі потреби викликати. Це означає додаткові токени, які могли б бути витрачені на власне код чи обговорення задачі.
По‑друге, надлишок інструментів ускладнює вибір для моделі. Коли в контексті десятки можливих дій, Claude Code змушений щоразу оцінювати, який тул доречний. Це може як сповільнювати відповіді, так і підвищувати ризик того, що буде обрано не той інструмент, який очікує користувач.
По‑третє, у великих проєктах із довгими сесіями контекстне вікно — ресурс обмежений. Навіть якщо ліміт у мільйон токенів здається великим, він не безкінечний. Коли в /context видно, що значну частину займають інструменти, якими ви фактично не користуєтеся, це прямий сигнал до оптимізації.
Автор гайду наводить власний приклад: у нього в контексті активні численні Zapier‑інструменти, які в конкретній сесії не потрібні. Вони лише «роздувають» контекст і потенційно плутають Claude Code. Вимкнення таких MCP‑тулів — простий спосіб зробити сесію дешевшою, швидшою й передбачуванішою.
Ця логіка напряму пов’язана з проєктною архітектурою конфігурацій. Якщо для певного репозиторію потрібен лише обмежений набір MCP‑інтеграцій, їх варто явно закріпити в його .claude і не тягнути за собою глобальний «зоопарк» інструментів. А для універсальних речей на кшталт GitHub MCP — навпаки, доречно обрати користувацький скоуп, але все одно стежити, які саме тулзи активні в конкретній сесії.
Професійний сетап як сума дрібниць: від моделей до компактного контексту
Хоча основний фокус гайду — на скілах, сабагентах і конфігураційній архітектурі, загальна картина професійного сетапу Claude Code складається з низки дрібних, але важливих рішень.
Одне з них — усвідомлений вибір моделі. Через команду /model можна перемикатися між Opus, Sonnet і Haiku. Для користувачів плану за 20 доларів на місяць автор прямо не радить використовувати Opus за замовчуванням: це дорожча й часто надлишкова модель. Sonnet пропонується як стандартний вибір для більшості задач, Opus — для справді складних, а Haiku — для простих або довготривалих процесів, де важлива економія ресурсів.
Ще один елемент — інструменти самодіагностики. Команда /insights генерує локальний HTML‑звіт про те, як користувач працює з Claude Code: які помилки робить, що вдається добре, де інструмент використовується ефективно, а де — ні. Це не лише цікава статистика, а й спосіб зрозуміти, як краще будувати скіли й сабагентів, щоб вони відповідали реальним патернам роботи.
Команда /cost дозволяє відстежувати витрати на API, хоча в разі фіксованої підписки вона показує нуль. А /compact дає можливість «стиснути» історію: очистити поточний діалог, залишивши в контексті лише короткий підсумок. Це ще один інструмент управління контекстом, який особливо корисний у довгих сесіях, коли важливо зберегти загальну лінію розмови, але не платити за кожну стару репліку.
Усі ці деталі працюють разом із проєктною конфігурацією. Якщо в .claude для конкретного репозиторію збережено набір скілів, сабагентів і MCP‑інструментів, то правильний вибір моделі, регулярний перегляд /context і вчасне використання /compact перетворюють Claude Code на кероване середовище, а не на «чорну скриньку».
Висновок: Claude Code як конфігурований шар над вашим кодом
Головна ідея просунутого гайду по Claude Code — у тому, що справжня сила інструмента розкривається не тоді, коли ви просто «спілкуєтеся з ШІ», а тоді, коли будуєте навколо нього конфігуровану інфраструктуру.
Прихована папка .claude в кожному проєкті стає місцем, де живуть його правила, скіли, сабагенти й інструменти. Система скоупів дозволяє розділяти локальні й глобальні налаштування, а керування MCP‑тулзами — уникати контекстного «сміття» й зайвих витрат. Скіли та сабагенти, у свою чергу, дають змогу формалізувати робочі процеси й перетворити їх на повторювані, автоматизовані сценарії.
У підсумку Claude Code постає не як ще один AI‑чат, а як конфігурований шар над вашим кодом і інфраструктурою. І саме проєктний рівень кастомізації — через .claude, скіли, сабагенти й уважне ставлення до контексту — робить цей шар по‑справжньому професійним.
Джерело
The Ultimate Claude Code Guide | MCP, Skills & More — Tech With Tim