Claude Code Mastery

Повний інтерактивний курс українською. Від нуля до повної майстерності Claude Code — ваш персональний розробник у терміналі.

уроків

модулі

15+

вправ

квізів

1.1 Що таке Claude Code?

Модуль 1 · Основи

Цілі уроку

Зрозуміти, що таке coding assistant і чим він відрізняється від чат-бота
Розібратись у системі Tool Use — як Claude взаємодіє зі світом
Дізнатися про ключові переваги Claude Code над аналогами
Відчути впевненість та готовність до подальшого навчання

Уявіть собі персонального розробника

Закрийте очі і уявіть: у вас є особистий розробник, який живе у вашому терміналі. Він не спить, не п'є каву, не ходить на мітинги. Він завжди готовий допомогти — написати код, виправити баг, проаналізувати проєкт, підготувати PR. Це і є Claude Code.

Але давайте точніше. Claude Code — це не просто чат, куди ви кидаєте питання. Це агентний AI-інструмент, що працює прямо у вашому терміналі та має доступ до вашої файлової системи, може запускати команди, редагувати файли та інтегруватися з Git, GitHub та іншими інструментами.

Метафора: Мозок без рук

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

Ця система називається Tool Use — і саме вона робить Claude Code таким потужним.

Як працює Tool Use?

Коли ви даєте Claude Code завдання, він не просто генерує текст. Він планує, які інструменти йому потрібні, і використовує їх по черзі:

Read — прочитати файл, щоб зрозуміти контекст
Grep/Glob — знайти потрібний код по всьому проєкту
Edit/Write — внести зміни або створити новий файл
Bash — запустити будь-яку команду в терміналі (тести, збірку, git)

Приклад типового ланцюжка

Ви: "Виправи баг у функції авторизації"

Claude Code думає:

Grep: шукає "auth" або "login" у кодовій базі
Read: читає знайдені файли
Думає: аналізує проблему
Edit: вносить виправлення
Bash: запускає тести щоб перевірити
Повідомляє вам результат

Все це — один промпт, один результат. Вам не потрібно вручну шукати файли чи копіювати код.

Чому це важливо?

Без Tool Use Claude був би просто чат-ботом — розумним, але безпомічним. Він міг би порадити, що робити, але не міг би зробити це сам. Tool Use перетворює пораду на дію. Це різниця між лікарем, який каже "вам потрібна операція" і хірургом, який бере скальпель і оперує.

Тепер, коли ви розумієте внутрішній механізм Claude Code, давайте подивимося, як він виглядає на фоні конкурентів.

Чим Claude Code відрізняється від інших?

На ринку багато AI coding assistants — Cursor, GitHub Copilot, Windsurf. Уявіть, що ви обираєте транспорт для подорожі. Автобус довезе, але за своїм маршрутом. Таксі — зручніше, але дорого. А особистий автомобіль з GPS — повна свобода та контроль. Claude Code — це ваш особистий автомобіль серед AI-асистентів.

Характеристика	Claude Code	Типовий IDE assistant
Де працює	Термінал (будь-яка ОС)	Прив'язаний до конкретного IDE
Пошук по коду	Прямий пошук (grep/glob)	Індексація через зовнішній сервіс
Безпека	Ваш код НЕ покидає вашу машину*	Часто надсилає код у хмару для індексації
Розширюваність	MCP сервери, хуки, кастомні команди	Обмежений плагінами IDE
Git інтеграція	Натуральна (прямо в терміналі)	Через UI-обгортку
Агентність	Повна: планує, виконує, перевіряє	Переважно автодоповнення

* Тільки ваші промпти та контекст надсилаються до Anthropic API. Повний код не індексується зовнішнім сервісом.

Ключова перевага: прямий пошук

Більшість IDE-асистентів спочатку індексують ваш код — створюють базу даних ембедінгів, яку потім шукають. Це означає:

Затримка між зміною коду і оновленням індексу
Ваш код обробляється зовнішнім сервісом
Результати пошуку залежать від якості індексації

Claude Code використовує grep та glob напряму — як досвідчений розробник, який шукає у терміналі. Миттєво, точно, безпечно.

Що можна робити з Claude Code?

Повсякденні задачі

Писати нові функції, компоненти, модулі
Виправляти баги з розумінням контексту всього проєкту
Рефакторити код з дотриманням наявних патернів
Писати та запускати тести
Створювати PR з описами та commit-повідомленнями
Аналізувати та документувати кодову базу

Просунуті можливості

Автоматизація код-рев'ю через GitHub Actions
Браузерне тестування через MCP + Playwright
Захист від помилок через систему хуків
Кастомні команди для повторюваних задач
SDK для інтеграції в будь-який пайплайн

Реальні приклади можливостей

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

Демо 1: Оптимізація продуктивності — Chalk.js

Claude Code проаналізував бібліотеку Chalk — 5-й за завантаженнями npm-пакет (429 млн завантажень/тиждень). Використовуючи бенчмарки, профайлінг, todo-списки, Claude знайшов вузькі місця та виправив їх.

Результат: прискорення у 3.9 рази ⏱ Години роботи → один промпт

Демо 2: Аналіз даних — Jupyter Notebooks

Claude Code виконав churn-аналіз CSV-даних відеостримінгової платформи через Jupyter notebooks. Запускав код, переглядав результати, будував графіки, ітеративно покращував аналіз на основі знахідок.

Демо 3: Браузерна автоматизація — Playwright MCP

Через MCP сервер Playwright Claude відкривав браузер, робив скріншоти UI, оновлював стилі, ітеративно покращував дизайн — все автоматично.

Демо 4: GitHub Actions — код-рев'ю

Claude Code працює всередині GitHub Actions, отримує інструменти для коментарів, комітів та створення PR. Автоматичний код-рев'ю на кожен pull request.

Демо 5: Інфраструктурний аналіз — виявлення PII

Terraform-конфігурація з DynamoDB таблицею та S3 бакетом, що ділиться із зовнішнім партнером. Розробник додав email користувача у вивід Lambda-функції. Claude Code автоматично виявив ризик витоку персональних даних (PII), проаналізувавши потік інфраструктури та визначивши зовнішній шерінг даних.

Часті запитання

Чи потрібно знати термінал?

Базові знання допоможуть, але не обов'язкові. Claude Code сам виконує команди. Вам потрібно лише вміти відкрити термінал і набрати claude. Все інше — природною мовою.

Які мови програмування підтримуються?

Будь-які! Claude Code працює з файлами і терміналом, тому підтримує все: TypeScript, Python, Rust, Go, Java, C#, Ruby, PHP — та навіть конфігураційні файли, Dockerfile, Terraform тощо.

Це безкоштовно?

Claude Code потребує підписку Claude Pro ($20/міс), Team ($30/міс) або Max ($100-200/міс). Також можна підключити власний API ключ від Anthropic, AWS Bedrock або Google Vertex.

Перевірка знань: Урок 1.1

1. Що таке Tool Use в контексті Claude Code?

Система автодоповнення коду

Система, що дає Claude "руки та очі" — можливість читати файли, виконувати команди тощо

Плагін для VS Code

2. Як Claude Code шукає код у проєкті?

Створює базу ембедінгів на зовнішньому сервісі

Надсилає весь код у хмару для аналізу

Використовує grep та glob напряму у терміналі

3. Де працює Claude Code?

У терміналі, на будь-якій ОС

Тільки у VS Code

Тільки у браузері

1.2 Встановлення та перший запуск

Модуль 1 · Основи

Цілі уроку

Встановити Claude Code на вашу ОС
Пройти автентифікацію
Зробити перший запуск і познайомитися з інтерфейсом
Дізнатися про альтернативні способи підключення (Bedrock, Vertex)

Перш ніж архітектор почне будувати — йому потрібні інструменти. Найкращий у світі план залишиться лише кресленням, якщо немає молотка, рівня та рулетки. Встановлення Claude Code — це облаштування вашої майстерні. Спершу ставимо верстак (Node.js), потім кладемо на нього головний інструмент (Claude Code), і нарешті — вмикаємо світло (автентифікація). Через п'ять хвилин ви будете готові до роботи.

Встановлення: три ОС, одна команда

Claude Code встановлюється через npm — пакетний менеджер Node.js. Це як магазин інструментів: одна команда — і потрібний інструмент у вас на верстаку. Якщо у вас ще немає Node.js, спочатку встановіть його.

Крок 1: Перевірте Node.js

node --version

Потрібна версія 18+. Якщо немає — скачайте з nodejs.org.

Крок 2: Встановлення Claude Code

macOS / Linux

npm install -g @anthropic-ai/claude-code

Якщо отримаєте помилку дозволів:

sudo npm install -g @anthropic-ai/claude-code

Windows

Claude Code на Windows працює через WSL2 (Windows Subsystem for Linux):

# 1. Встановіть WSL2 (якщо ще не маєте) wsl --install # 2. Відкрийте WSL термінал і встановіть: npm install -g @anthropic-ai/claude-code

Також можна використовувати Git Bash або PowerShell, але WSL2 рекомендований для повної сумісності.

Крок 3: Перший запуск

Тепер відкрийте термінал. Так, термінал — ваш командний центр. Він може виглядати як кадр з фільму про хакерів, але насправді це ваш найпотужніший союзник. Саме тут живе Claude Code.

cd /шлях/до/вашого/проєкту claude

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

Що ви побачите після запуску

╭──────────────────────────────────────╮ │ Claude Code │ │ v1.x.x │ │ │ │ /шлях/до/вашого/проєкту │ │ │ │ Type your message... │ ╰──────────────────────────────────────╯

Це ваш робочий простір. Просто пишіть завдання природною мовою!

Альтернативні провайдери

Прямий доступ через Anthropic — найпростіший шлях. Але якщо ваша компанія вже інвестувала в хмарну інфраструктуру AWS або Google Cloud, є сенс використати її. Це як вибрати, через яку двері зайти в один і той самий будинок — результат однаковий, але маршрут може бути зручнішим для вашої ситуації.

AWS Bedrock

# Встановіть змінні середовища: export CLAUDE_CODE_USE_BEDROCK=1 export AWS_REGION=us-east-1 export AWS_ACCESS_KEY_ID=ваш_ключ export AWS_SECRET_ACCESS_KEY=ваш_секрет claude

Google Vertex AI

# Встановіть змінні середовища: export CLAUDE_CODE_USE_VERTEX=1 export CLOUD_ML_REGION=us-east5 export ANTHROPIC_VERTEX_PROJECT_ID=ваш_проєкт claude

Хмарні провайдери

Якщо ви використовуєте AWS Bedrock або Google Cloud Vertex, потрібна додаткова конфігурація:

AWS Bedrock: https://code.claude.com/docs/en/amazon-bedrock
Google Cloud Vertex: https://code.claude.com/docs/en/google-vertex-ai

Повна інструкція з встановлення: https://code.claude.com/docs/en/quickstart

Корисні аргументи запуску

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

Команда	Опис
`claude`	Інтерактивний режим (REPL)
`claude "завдання"`	Одноразове завдання (без REPL)
`claude -p "завдання"`	Print mode — тільки текстовий вивід, без змін
`claude --resume`	Відновити попередню сесію
`claude --model sonnet`	Обрати модель (sonnet, opus, haiku)

⏱ Економія: 5 хв на перший запуск vs ручне налаштування IDE-плагіна

Чому це важливо?

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

Тепер, коли ваша майстерня облаштована, час перевірити, чи все працює як слід.

Перевірка: чи все працює?

Вправа: Встановлення та перший діалог

Виконайте наступні кроки:

Встановіть Claude Code (якщо ще не встановлений)
Перейдіть до будь-якого проєкту: cd ваш_проєкт
Запустіть: claude
Напишіть: "Проаналізуй структуру цього проєкту і створи короткий опис"

Який результат ви отримали? Claude повинен прочитати файли проєкту і дати опис структури.

Якщо все працює правильно, Claude Code:

Використає Glob щоб знайти файли проєкту
Використає Read щоб прочитати ключові файли (package.json, README, тощо)
Згенерує структурований опис: мова програмування, фреймворки, структура папок, основний функціонал

Якщо виникла помилка автентифікації — перевірте підписку. Якщо "command not found" — переконайтеся що Node.js і npm встановлені.

1.3 Контекст — ваша суперсила

Модуль 1 · Основи

Цілі уроку

Зрозуміти, чому контекст — це найважливіше для якісної роботи AI
Навчитися створювати та налаштовувати CLAUDE.md
Опанувати три рівні пам'яті (Project, Local, Machine)
Дізнатися про @ mentions та Memory mode

Уявіть, що ви запрошуєте нового розробника до команди. У перший день він нічого не знає: ні структуру проєкту, ні правила іменування, ні архітектурні рішення. Він задає десятки запитань, робить типові помилки і потребує постійного нагляду. Але через місяць він знає проєкт як свої п'ять пальців. Різниця? Контекст. І саме контекст — те, що відрізняє посереднього AI-асистента від видатного.

Контекст = пальне для двигуна Claude

Метафора: Двигун без пального

Уявіть потужний болід Формули-1. Без пального він просто стоїть. Контекст — це пальне для Claude.

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

Як надати Claude правильний контекст? Є кілька способів, і найважливіший — файл CLAUDE.md.

CLAUDE.md — ваш "README для AI"

CLAUDE.md — це файл, який Claude Code автоматично читає при запуску. Це як інструкція для нового розробника: "Ось наш проєкт, ось наші правила, ось як ми працюємо."

Створення CLAUDE.md

# Запустіть Claude Code і попросіть: claude # Або використайте вбудовану команду: /init

Команда /init проаналізує ваш проєкт і створить базовий CLAUDE.md автоматично. Але найкращий CLAUDE.md — той, який ви доопрацюєте під ваші потреби.

Що писати в CLAUDE.md?

# Проєкт: My App ## Архітектура - Frontend: React + TypeScript - Backend: FastAPI + Python - Database: PostgreSQL + Redis ## Стек та конвенції - Тести: pytest (backend), vitest (frontend) - Стиль: ESLint + Prettier, Black (Python) - Гілки: feature/* → develop → main ## Критичні правила - НІКОЛИ не змінюй міграції бази даних - Завжди використовуй TypeScript strict mode - Кожна нова функція потребує тестів ## Ключові файли - @src/config/database.ts — конфігурація БД - @src/middleware/auth.ts — авторизація - @docs/API.md — специфікація API

Чому це важливо?

Без контексту Claude працює як лікар без медичної картки пацієнта — може допомогти, але втрачає критичну інформацію. CLAUDE.md перетворює Claude з "розумного незнайомця" на "досвідченого колегу, який знає ваш проєкт". Інвестуйте 15 хвилин у написання CLAUDE.md — і кожна наступна взаємодія стане точнішою.

Три рівні CLAUDE.md

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

Рівень	Файл	Хто бачить	Для чого
Project	CLAUDE.md у корені проєкту	Вся команда (коміт у git)	Загальні правила проєкту
Local	.claude/CLAUDE.local.md	Тільки ви (у .gitignore)	Ваші особисті налаштування
Machine	~/.claude/CLAUDE.md	Тільки ви, на всіх проєктах	Глобальні преференції

Приклад Machine-level CLAUDE.md

# Глобальні преференції - Відповідай українською - Використовуй функціональний стиль де можливо - Завжди пропонуй тести для нового коду - Коміт-повідомлення англійською, опис PR — українською

Тепер, коли ви знаєте, де зберігаються налаштування, виникає питання: а чи потрібно кожного разу вручну редагувати файли? Ні! Для цього є зручніший спосіб.

Memory Mode: збереження знань на льоту

Натисніть # у Claude Code, і він перейде в режим Memory. Все, що ви йому скажете, буде збережено в CLAUDE.md для майбутніх сесій. Це як записна книжка досвідченого майстра — кожен новий урок фіксується, щоб не повторювати помилки.

# Приклад використання: # Натисніть # і напишіть: "Запам'ятай: у нашому проєкті функція auth завжди повертає JWT token, ніколи session cookie" # Claude додасть це правило в CLAUDE.md

Коли використовувати Memory?

Claude зробив помилку — навчіть його через #: "Запам'ятай: ми використовуємо snake_case для API endpoints"
Ви виявили патерн — "Запам'ятай: компоненти UI завжди в src/components/{feature}/"
Бізнес-правило — "Запам'ятай: ціни завжди зберігаються в копійках, не гривнях"

Memory Mode чудово працює для загальних правил. Але що, коли вам потрібно направити Claude на конкретний файл прямо зараз, у цю мить?

@ Mentions: точний контекст

Коли вам потрібно вказати Claude на конкретний файл, використовуйте @. Це як показати пальцем на потрібну полицю — замість "знайди десь там" ви кажете "дивись ось сюди":

# Приклад: "Подивись на @src/auth/login.ts і виправи обробку помилок" "Порівняй підхід у @api/v1/users.py та @api/v2/users.py"

@ mentions працюють з автодоповненням — почніть набирати шлях і Claude Code запропонує варіанти.

Найкращі практики контексту

DO — Робіть так

Вказуйте критичні файли через @ у CLAUDE.md
Пишіть конкретні правила, а не загальні поради
Оновлюйте CLAUDE.md коли проєкт змінюється
Використовуйте # Memory для навчання Claude

DON'T — Не робіть так

Не копіюйте весь код у CLAUDE.md — він вже бачить файли
Не пишіть CLAUDE.md на 10 сторінок — стисло і чітко
Не забувайте .gitignore для local файлів
Не ігноруйте CLAUDE.md — це найшвидший спосіб покращити якість

Перевірка знань: Урок 1.3

1. Яка команда створює CLAUDE.md автоматично?

claude --create-md

claude setup

/init (всередині Claude Code)

2. Який рівень CLAUDE.md видно тільки вам, на всіх проєктах?

Project (корінь проєкту)

Machine (~/.claude/CLAUDE.md)

Local (.claude/CLAUDE.local.md)

3. Як зберегти знання для майбутніх сесій на льоту?

Натиснути # і написати правило (Memory Mode)

Написати "save" у чат

Перезапустити Claude Code

1.4 Робота зі змінами

Модуль 1 · Основи

Цілі уроку

Навчитися вставляти скріншоти в Claude Code
Зрозуміти Plan Mode і Think Mode — коли що використовувати
Опанувати Git інтеграцію

Ви вже знаєте, як запустити Claude Code і надати йому контекст. Тепер час перейти до головного — до реальної роботи. Як саме Claude бачить ваші проблеми? Як він приймає рішення? І коли варто дати йому подумати довше, а коли краще попросити спершу скласти план? Давайте розберемося.

Скріншоти: покажіть Claude що ви бачите

Claude Code — мультимодальний. Він розуміє зображення! Зробіть скріншот баг-репорту, дизайну в Figma, або помилки в браузері — і просто вставте його.

Важливо: правильна комбінація клавіш!

Windows/Linux: Ctrl+V — вставити скріншот
macOS: Теж Ctrl+V (НЕ Cmd+V!)

Це частий підводний камінь на Mac — Claude Code використовує Ctrl+V для вставки зображень, навіть на macOS.

# Типовий воркфлоу зі скріншотом: 1. Зробіть скріншот помилки/дизайну 2. Перейдіть у Claude Code 3. Ctrl+V (вставте зображення) 4. Напишіть: "Ось баг на скріншоті. Виправ його." 5. Claude побачить зображення, знайде код і виправить

Plan Mode: Архітектор перед будівельником

Метафора: Архітектор

Уявіть, що ви будуєте будинок. Ви ж не починаєте з цегли — ви спочатку малюєте план! Plan Mode — це ваш архітектор. Він розбирає задачу на кроки, пропонує підхід, і тільки після вашого підтвердження починає будувати.

Як активувати: натисніть Shift+Tab двічі. Ви побачите індикатор [PLAN] в інтерфейсі.

Коли використовувати Plan Mode?

Широкі задачі: "Додай систему авторизації" — багато файлів, багато рішень
Рефакторинг: "Перенеси на TypeScript" — потрібен план послідовності
Архітектурні зміни: "Додай кешування" — потрібно вибрати стратегію
Невпевненість: коли ви не знаєте оптимального підходу

Think Mode: Глибинний дайвер

Метафора: Дайвер

Якщо Plan Mode — це архітектор, який дивиться на будівлю зверху, то Think Mode — це глибинний дайвер, який занурюється в одну конкретну проблему на максимальну глибину.

Як активувати: просто напишіть "think" або "ultra think" у повідомленні. Чим довше слово think, тим глибше аналіз:

think — базове обмірковування
think hard — глибше
ultra think — максимальна глибина аналізу

Коли використовувати Think Mode?

Складний баг: "ultra think: чому функція повертає null тільки в production?"
Алгоритмічна задача: "think hard: оптимізуй цей SQL запит"
Безпека: "ultra think: знайди вразливості у цьому коді"
Один файл, глибока проблема: потрібна концентрація, не широта

Plan + Think: коли поєднувати?

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

Ситуація	Рекомендація
Нова фіча з багатьма файлами	Plan Mode
Хитрий баг в одному файлі	Think Mode
Міграція бази даних	Plan Mode → Think Mode для кожного кроку
Code review	Think Mode
Нова архітектура + складна логіка	Plan Mode → Think Mode для складних частин

Тепер, коли ви знаєте, як Claude планує і думає, час подивитися на ще один критичний аспект щоденної роботи — контроль версій.

Git інтеграція

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

# Просто попросіть: "Створи коміт з описовим повідомленням для всіх моїх змін" "Створи нову гілку feature/auth-fix і закоміть зміни" "Подивись git diff і поясни, що змінилося"

⏱ Економія: 15 хв на написання коміт-повідомлень та PR-описів щодня

Вправа: Підбери режим

Визначте, який режим підійде краще для кожної ситуації:

"Додай dark mode до всього застосунку" — Plan чи Think?
"Чому цей regex не ловить email з плюсом?" — Plan чи Think?
"Перероби API з REST на GraphQL" — Plan чи Think?
"Оптимізуй цей N+1 запит" — Plan чи Think?

Plan Mode — широка задача, багато файлів, потрібен план
Think Mode — глибока проблема в одному місці
Plan Mode — масштабна архітектурна зміна
Think Mode — одна конкретна оптимізація

1.5 Керування контекстом

Модуль 1 · Основи

Цілі уроку

Опанувати всі клавіатурні скорочення для керування сесією
Зрозуміти, коли використовувати Escape, Double Escape, Compact та Clear
Навчитися ефективно працювати з контекстним вікном

Досвідчений пілот знає кожну кнопку на панелі управління. Він не дивиться на прилади — пальці самі знаходять потрібний перемикач у критичний момент. Так само і з Claude Code: чим краще ви знаєте інструменти керування сесією, тим плавнішою буде ваша робота. Цей урок перетворить вас з пасажира на пілота.

Контекстне вікно: обмежений ресурс

У Claude є обмеження — контекстне вікно. Це кількість інформації, яку він може "тримати в голові" одночасно. Уявіть робочий стіл: на ньому поміщається обмежена кількість документів. Якщо стіл переповнений — пора прибрати.

Claude Code має кілька інструментів для керування цим простором. Кожен — як особливий прилад на панелі управління.

Escape — кнопка паузи

Одинарний Escape

Що робить: зупиняє Claude посеред відповіді.

Метафора: Пульт дистанційного керування — натискаєте паузу, коли бачите, що Claude пішов не туди.

Коли використовувати:

Claude почав писати не той код
Ви зрозуміли, що поставили неправильне питання
Claude робить щось надто довге і непотрібне

Після Escape ви можете уточнити завдання і Claude продовжить з нового місця.

Escape + # Memory — щит від помилок

Зупинити + Навчити

Комбінація: Escape (зупинити) → # (Memory Mode) → "Запам'ятай: не роби X, роби Y"

Метафора: Захисний щит — ви не просто зупиняєте помилку, а й запобігаєте її повторенню.

Приклад:

# Claude почав писати CSS із !important # Ви натискаєте Escape, потім #: "Запам'ятай: ніколи не використовуй !important у CSS. Використовуй специфічність селекторів."

Double Escape — машина часу

Подвійний Escape

Що робить: відкочує останню відповідь Claude та ваше останнє повідомлення.

Метафора: Машина часу — повернутися назад і спробувати інакше.

Коли використовувати:

Claude повністю неправильно зрозумів завдання
Ви хочете переформулювати питання
Результат був поганим і ви хочете інший підхід

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

Compact — компресор

/compact

Що робить: стискає всю розмову в коротке резюме, зберігаючи ключові знання.

Метафора: Компресор — стискаєте 100 сторінок у 5, зберігаючи головне.

Коли використовувати:

Контекстне вікно заповнюється (Claude попередить вас)
Ви працюєте довго над одним завданням
Хочете продовжити сесію, але контексту замало

# Варіанти: /compact # Автоматичне стиснення /compact "Збережи деталі про auth модуль" # Стиснення з фокусом

Clear — чистий аркуш

/clear

Що робить: повністю очищає контекст. Нова сесія з нуля.

Метафора: Чистий аркуш — все починаємо заново.

Коли використовувати:

Ви переходите до абсолютно нового завдання
Контекст "забруднений" попередніми спробами
Claude зациклився на неправильному підході

Важливо: CLAUDE.md завантажується заново після /clear, тому базові знання зберігаються!

Чому це важливо?

Контекстне вікно — це найцінніший ресурс при роботі з Claude Code. Розробники, які не керують контекстом, витрачають до 30% більше токенів і отримують менш точні відповіді. Оволодіння п'ятьма інструментами нижче — це різниця між тим, хто "використовує Claude Code" і тим, хто "майстерно працює з Claude Code".

Зведена таблиця

Давайте зберемо все до купи. Ось ваша панель управління — п'ять кнопок, кожна для своєї ситуації:

Інструмент	Дія	Метафора	Контекст
Escape	Пауза	Пульт ДУ	Зберігається
Escape + #	Пауза + Навчити	Захисний щит	Зберігається + нове правило
Double Escape	Відкат	Машина часу	Останній обмін видаляється
/compact	Стиснення	Компресор	Стискається в резюме
/clear	Очищення	Чистий аркуш	Повністю очищається

Перевірка знань: Урок 1.5

1. Що відбувається при подвійному натисканні Escape?

Claude зупиняється посеред відповіді

Видаляється останній обмін (ваше повідомлення + відповідь Claude)

Очищається весь контекст

2. Коли найкраще використовувати /compact?

Коли ви переходите до нового завдання

Коли Claude зробив помилку

Коли контекстне вікно заповнюється, але ви хочете продовжити роботу

3. Що залишається після /clear?

CLAUDE.md завантажується заново — базові знання зберігаються

Уся попередня розмова

Нічого — навіть CLAUDE.md видаляється

4. Як запобігти повторенню помилки Claude?

Натиснути /clear

Escape → # Memory → описати правило

Перезапустити термінал

2.1 Кастомні команди

Модуль 2 · Автоматизація

Цілі уроку

Зрозуміти, що таке кастомні команди та навіщо вони
Навчитися створювати свої команди
Опанувати синтаксис $arguments для параметризації
Створити практичну команду для свого проєкту

Кожного разу, коли ви повторюєте одну й ту саму дію вдесяте, десь плаче розробник. DRY (Don't Repeat Yourself) — це не лише про код, а й про ваші промпти. Якщо ви щодня пишете один і той самий довгий запит для Claude, значить, настав час автоматизувати це.

Навіщо кастомні команди?

Уявіть, що ви щодня просите Claude зробити code review за одним і тим самим шаблоном. Або кожного разу пишете довгий промпт для створення компонента. Кастомні команди — це збережені промпти, які перетворюються на короткі slash-команди. Це як створити макрос для клавіатури — одне натискання замість десяти.

Метафора: Кнопки швидкого набору

Кастомні команди — як кнопки швидкого набору на телефоні. Замість набирати повний номер (довгий промпт), ви натискаєте одну кнопку (/review, /component, /test) — і Claude знає, що робити.

Де створювати команди?

Команди зберігаються як markdown-файли у спеціальній папці:

# Структура: .claude/commands/ review.md # → /review component.md # → /component test.md # → /test deploy-check.md # → /deploy-check

Правило: ім'я файлу = ім'я команди. Файл audit.md стає командою /audit.

Анатомія команди

Файл команди — це звичайний markdown з промптом для Claude. Давайте створимо команду для аналізу файлу:

Приклад: /analyze

Файл: .claude/commands/analyze.md

Проаналізуй файл $ARGUMENTS і створи звіт: 1. **Призначення**: для чого цей файл? 2. **Залежності**: які модулі він імпортує? 3. **Функції**: перелічи всі функції з коротким описом 4. **Проблеми**: знайди потенційні баги або code smells 5. **Рекомендації**: що можна покращити? Будь конкретним. Вказуй номери рядків.

Використання:

/analyze src/auth/login.ts

Claude замінить $ARGUMENTS на src/auth/login.ts і виконає аналіз.

Чому це важливо?

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

Базовий приклад зрозумілий. Тепер давайте подивимося на більш практичні команди, які ви зможете використовувати щодня.

Більше прикладів

Команда: /review

# Файл: .claude/commands/review.md Проведи code review змін у $ARGUMENTS. Перевір: - [ ] Чи є тести для нового коду? - [ ] Чи дотримані конвенції проєкту? - [ ] Чи немає XSS/injection вразливостей? - [ ] Чи оптимальний SQL/ORM запит? - [ ] Чи коректна обробка помилок? - [ ] Чи є edge cases що не покриті? Оціни за шкалою 1-5 і дай конкретні рекомендації.

Команда: /component

# Файл: .claude/commands/component.md Створи React компонент $ARGUMENTS: 1. TypeScript з інтерфейсом Props 2. Функціональний компонент з hooks 3. CSS Modules для стилів 4. Unit тест з React Testing Library 5. Storybook story Дотримуйся конвенцій з @src/components/Button/Button.tsx як референсу стилю.

⏱ Економія: 5-10 хв на кожне використання команди (замість набирання промпту)

Порада: вкладені папки

Можна організувати команди по папках:

.claude/commands/ review.md # → /review frontend/ component.md # → /frontend:component page.md # → /frontend:page backend/ endpoint.md # → /backend:endpoint migration.md # → /backend:migration

Вправа: Створіть свою команду

Подумайте: яку повторювану задачу ви виконуєте щодня? Напишіть markdown-файл для кастомної команди, яка автоматизує цю задачу.

Ідеї:

/doc — документування функції або модуля
/refactor — рефакторинг з дотриманням патернів
/bug — аналіз та виправлення бага
/security — аудит безпеки файлу

Приклад команди /doc:

# Файл: .claude/commands/doc.md Задокументуй $ARGUMENTS: 1. Додай JSDoc/docstring до кожної функції 2. Створи README.md для модуля якщо його немає 3. Додай приклади використання 4. Опиши input/output типи 5. Вкажи edge cases та обмеження Використовуй стиль документації з @docs/STYLE_GUIDE.md

2.2 MCP сервери

Модуль 2 · Автоматизація

Цілі уроку

Зрозуміти, що таке MCP (Model Context Protocol)
Навчитися встановлювати та налаштовувати MCP сервери
Побачити практичний приклад з Playwright
Зрозуміти систему дозволів

Що, якби Claude Code міг не тільки читати файли, а й керувати браузером, базою даних, хмарою? Що, якби ви могли підключити до нього будь-який зовнішній інструмент — так само просто, як вставити USB-флешку в ноутбук? Саме це і робить MCP.

MCP = USB-порти для мозку Claude

Метафора: USB порти

Ваш комп'ютер має USB-порти, через які ви підключаєте різні пристрої: клавіатуру, мишку, зовнішній диск. MCP сервери — це USB-порти для Claude. Кожен MCP сервер "підключає" нову здатність:

Playwright MCP — підключає браузер (Claude може відкривати сайти, клікати, читати)
GitHub MCP — підключає GitHub API (PR, issues, рев'ю)
Figma MCP — підключає Figma (читання дизайнів)
Database MCP — підключає базу даних (запити, міграції)

І найкраще — ви можете створювати свої власні MCP сервери!

Встановлення MCP серверів

Команда для додавання MCP серверу:

claude mcp add [ім'я] [команда-запуску]

Приклад: Playwright (браузерна автоматизація)

# Встановлення Playwright MCP: claude mcp add playwright -- npx @anthropic-ai/mcp-playwright

Після цього Claude зможе:

Відкривати веб-сторінки
Робити скріншоти сторінок
Клікати по елементах
Заповнювати форми
Перевіряти текст на сторінці

Практичний воркфлоу з Playwright

Цикл: Генерація UI → Скріншот → Покращення

Ви: "Створи сторінку реєстрації у стилі Stripe"
Claude генерує HTML/CSS/JS
Claude відкриває сторінку в браузері через Playwright
Claude робить скріншот і аналізує результат
Claude бачить проблеми і автоматично виправляє
Повторює до ідеального результату

Все це — без вашої участі! Claude сам бачить, що кнопка криво стоїть, і сам виправляє.

⏱ Економія: 30+ хв на ітерації UI дизайну

Чому це важливо?

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

Однак з великою силою приходить велика відповідальність. Якщо Claude може керувати браузером чи базою даних — потрібно контролювати, що саме йому дозволено.

Управління дозволами

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

# .claude/settings.local.json { "permissions": { "allow": [ "mcp__playwright__browser_navigate", "mcp__playwright__browser_snapshot" ], "deny": [ "mcp__playwright__browser_fill_form" ] } }

Увага: безпека MCP

MCP сервери виконують код на вашій машині. Встановлюйте лише перевірені сервери! Перегляньте код або використовуйте офіційні MCP від Anthropic та перевірених постачальників.

Список MCP серверів

# Переглянути встановлені MCP: claude mcp list # Видалити MCP: claude mcp remove playwright

Перевірка знань: Урок 2.2

1. Що таке MCP?

Мова програмування для Claude

Протокол, що додає Claude нові здатності (як USB-порти)

Система контролю версій

2. Що дає Playwright MCP серверу Claude?

Здатність відкривати сайти, клікати, робити скріншоти

Здатність писати тести

Здатність розгортати сайти

3. Де налаштовуються дозволи MCP?

У CLAUDE.md

У package.json

У .claude/settings.local.json

2.3 GitHub інтеграція

Модуль 2 · Автоматизація

Цілі уроку

Підключити Claude до GitHub
Зрозуміти дві дефолтні дії: @Claude mentions та PR review
Налаштувати GitHub Actions з Claude
Поєднати Playwright + GitHub для автоматичного тестування

Досі ми працювали з Claude Code локально — у своєму терміналі, зі своїми файлами. Але розробка — це командна гра, і її серцем є GitHub. Що, якби Claude міг жити прямо на GitHub — ревюїти PR, відповідати на питання в issues, автоматично перевіряти код при кожному пуші? Саме це дає GitHub інтеграція.

Налаштування

Інтеграція з GitHub починається з однієї команди — і це буквально все, що потрібно:

/install-github-app

Це встановить GitHub App для Claude Code у ваш репозиторій. Після встановлення Claude буде доступний прямо на GitHub.

Дві дефолтні дії

1. @Claude mentions в Issues та PR

Просто напишіть @claude у коментарі до issue або PR, і Claude відповість!

# У коментарі на GitHub: @claude Проаналізуй цей PR і знайди потенційні проблеми @claude Запропонуй реалізацію цієї фічі з issue #42

Claude має доступ до всього контексту PR: diff, коментарі, пов'язані файли.

2. Автоматичний Code Review

Claude може автоматично ревюїти кожен PR у вашому репозиторії. Він перевіряє:

Якість коду та дотримання конвенцій
Потенційні баги та edge cases
Безпекові вразливості
Покриття тестами
Документацію

Дві дефолтні дії — це потужний старт. Але справжня гнучкість починається тоді, коли ви налаштовуєте власні автоматизації через GitHub Actions.

Налаштування GitHub Actions

Для більш гнучкої інтеграції, створіть GitHub Action workflow:

# .github/workflows/claude-review.yml name: Claude Code Review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Claude Review uses: anthropics/claude-code-action@v1 with: model: sonnet prompt: | Проведи code review цього PR. Фокус: безпека, продуктивність, тести.

Playwright + GitHub: автоматичне тестування UI

Магічний воркфлоу

Поєднуючи Playwright MCP та GitHub Actions, ви отримуєте:

Розробник створює PR з UI змінами
GitHub Action запускає Claude
Claude відкриває змінені сторінки через Playwright
Claude робить скріншоти і порівнює з дизайном
Claude залишає коментар у PR з результатами

Це як мати безкоштовного QA-інженера, що працює 24/7!

⏱ Економія: 1-2 години code review на кожному PR

Дозволи для MCP у GitHub Actions

Важливо: дозволи

У GitHub Actions MCP інструменти потребують явного дозволу через конфігурацію:

- uses: anthropics/claude-code-action@v1 with: allowed_tools: "mcp__playwright__browser_navigate,mcp__playwright__browser_snapshot"

Не давайте зайвих дозволів у CI/CD — дотримуйтесь принципу найменших привілеїв.

Вправа: Спроєктуйте GitHub Action

Уявіть, що ваш проєкт — це e-commerce сайт. Спроєктуйте GitHub Action workflow, який:

Запускається на кожному PR до гілки main
Перевіряє код через Claude Code Review
Використовує Playwright для перевірки критичних сторінок (головна, кошик, чекаут)
Залишає коментар з результатами

Які кроки та інструменти вам потрібні?

name: E-commerce PR Review on: pull_request: branches: [main] jobs: claude-review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: anthropics/claude-code-action@v1 with: model: sonnet allowed_tools: > mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_click prompt: | 1. Проведи code review змін 2. Запусти dev сервер 3. Відкрий через Playwright: - Головну сторінку - Сторінку кошика - Сторінку чекауту 4. Перевір що все рендериться коректно 5. Залиш детальний коментар з результатами

2.4 Claude Code SDK

Модуль 2 · Автоматизація

Цілі уроку

Зрозуміти, що таке SDK і коли його використовувати
Навчитися основам CLI, TypeScript та Python SDK
Зрозуміти систему дозволів SDK
Побачити практичні приклади інтеграції

Уявіть, що ви навчилися керувати автомобілем вручну. Це чудово для повсякденних поїздок. Але що, якщо вам потрібно запрограмувати автопілот — щоб машина їхала за маршрутом без вашої участі? Саме це робить SDK: перетворює інтерактивну роботу з Claude на програмовану автоматизацію.

Коли REPL недостатньо

Досі ми працювали з Claude Code інтерактивно — набирали команди, отримували відповіді. Але що, якщо ви хочете:

Вбудувати Claude в свій скрипт або пайплайн?
Запускати Claude з cron job?
Створити свій CLI інструмент на базі Claude?
Інтегрувати Claude в CI/CD поза GitHub?

Для цього існує Claude Code SDK.

Три варіанти SDK

1. CLI SDK (найпростіший)

Запускайте Claude як звичайну команду у скриптах:

# Одноразове завдання: claude -p "Проаналізуй package.json і покажи outdated залежності" # Pipe з іншої команди: git diff | claude -p "Опиши ці зміни для release notes" # JSON output: claude -p "Список TODO у проєкті" --output-format json

2. TypeScript SDK

import { Claude } from "@anthropic-ai/claude-code"; const claude = new Claude(); const result = await claude.run({ prompt: "Знайди всі TODO у проєкті", options: { maxTurns: 5, allowedTools: ["Read", "Grep", "Glob"] } }); console.log(result.text);

3. Python SDK

from claude_code import Claude claude = Claude() result = claude.run( prompt="Знайди всі TODO у проєкті", options={ "max_turns": 5, "allowed_tools": ["Read", "Grep", "Glob"] } ) print(result.text)

Система дозволів SDK

Важливо: за замовчуванням — тільки читання!

SDK за замовчуванням працює в read-only режимі. Claude може читати файли і виконувати пошук, але НЕ може:

Створювати або редагувати файли
Виконувати bash команди
Робити git операції

Щоб дозволити запис, потрібно явно вказати інструменти:

// TypeScript: options: { allowedTools: ["Read", "Grep", "Glob", "Edit", "Write", "Bash"] } # Python: options={"allowed_tools": ["Read", "Grep", "Glob", "Edit", "Write", "Bash"]}

Чому це важливо?

SDK перетворює Claude з інтерактивного помічника на будівельний блок для будь-якої автоматизації. Хочете щоночі перевіряти код на вразливості? Автоматично генерувати release notes? Будувати власний CLI-інструмент? SDK робить це можливим. Це різниця між "я працюю з Claude" і "Claude працює на мене, поки я сплю".

Давайте подивимося на конкретні сценарії, де SDK розкриває свою справжню силу.

Практичні сценарії

Сценарій 1: Pre-commit hook

#!/bin/bash # .git/hooks/pre-commit # Перевірити якість коміту RESULT=$(git diff --cached | claude -p "Оціни цей diff за шкалою 1-10. Якщо є критичні проблеми — поверни 'BLOCK'. Якщо все ОК — поверни 'PASS'.") if echo "$RESULT" | grep -q "BLOCK"; then echo "Claude знайшов проблеми. Перевірте коміт." exit 1 fi

Сценарій 2: Автоматичні release notes

#!/bin/bash # Генерація release notes LAST_TAG=$(git describe --tags --abbrev=0) CHANGES=$(git log $LAST_TAG..HEAD --oneline) echo "$CHANGES" | claude -p "Створи release notes у форматі: ## Нові фічі ## Виправлення ## Зміни Групуй за категоріями. Пиши зрозуміло для кінцевих користувачів."

⏱ Економія: 30+ хв на кожний реліз

Перевірка знань: Урок 2.4

1. Яка дефолтна поведінка SDK щодо дозволів?

Тільки читання (read-only)

Повний доступ до всього

Без будь-якого доступу

2. Як отримати JSON-вивід від Claude CLI?

claude --json

claude -p "..." | json

claude -p "..." --output-format json

3. Для чого найкраще підходить SDK?

Для повсякденної роботи з кодом

Для автоматизації: скрипти, хуки, пайплайни

Для навчання програмуванню

3.1 Введення в хуки

Модуль 3 · Хуки

Цілі уроку

Зрозуміти концепцію хуків і навіщо вони потрібні
Розрізняти Pre-tool та Post-tool хуки
Побачити реальні сценарії використання

Уявіть охоронця біля дверей вашого коду. Він перевіряє кожного відвідувача перед входом і записує кожного, хто виходить. Один відвідувач хоче прочитати секретний файл? Не пущу. Інший вніс зміни в код? Записую і запускаю тести. Це і є хуки — ваша невтомна охоронна система, що працює 24/7.

Хуки = охоронна система вашого проєкту

Метафора: Камери спостереження + автоматичні двері

Уявіть розумний будинок. У ньому є:

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

Хуки Claude Code працюють так само:

PreToolUse — автоматичні двері ПЕРЕД дією. Можуть заблокувати небезпечну операцію.
PostToolUse — камери ПІСЛЯ дії. Можуть реагувати на те, що відбулося.

Як це працює?

Кожен раз, коли Claude збирається використати інструмент (прочитати файл, відредагувати код, виконати команду), хуки можуть втрутитися:

Ви: "Виправи баг у auth.ts" Claude думає: Мені потрібно прочитати auth.ts ↓ [PreToolUse хук] — Перевіряю: чи дозволено читати цей файл? ✅ ↓ Claude читає auth.ts ↓ [PostToolUse хук] — Файл прочитано. Логую подію. ↓ Claude думає: Знайшов баг, потрібно відредагувати ↓ [PreToolUse хук] — Перевіряю: чи не .env файл? ✅ ↓ Claude редагує auth.ts ↓ [PostToolUse хук] — Файл змінено! Запускаю тести автоматично. ↓ Тести пройшли ✅ Claude повідомляє результат

Де налаштовувати хуки?

Хуки налаштовуються через файл конфігурації або команду /hooks:

# Інтерактивне налаштування: /hooks # Або через файл: .claude/settings.local.json

Реальні сценарії

Сценарій 1: Захист секретних файлів

Проблема: Claude може випадково прочитати або змінити .env файл з API ключами.

Рішення: PreToolUse хук, що блокує доступ до .env файлів.

Сценарій 2: Автоматичний форматер

Проблема: Claude іноді пише код з відступами, що не відповідають стилю проєкту.

Рішення: PostToolUse хук, що запускає prettier/eslint після кожного Edit.

Сценарій 3: Автоматичні тести

Проблема: Ви хочете, щоб тести запускалися після кожної зміни коду.

Рішення: PostToolUse хук, що запускає тест-раннер після Edit у .ts/.py файлах.

Сценарій 4: Контроль якості

Проблема: Ви хочете, щоб Claude не створював файлів без тестів.

Рішення: PostToolUse хук, що перевіряє наявність тест-файлу для кожного нового .ts файлу.

Чому хуки — це game-changer?

Без хуків ви покладаєтесь на CLAUDE.md та промпти — "не чіпай .env", "завжди форматуй". Але промпти — це рекомендації. Хуки — це правила, які неможливо порушити. Це різниця між табличкою "Не входити" та замком на дверях.

Чому це важливо?

В реальних проєктах одна помилка може коштувати годин (витік секретів, зламаний production, втрата даних). Хуки — це страховка, яка працює автоматично. Ви налаштовуєте їх один раз і більше ніколи не турбуєтесь про типові помилки. Це як ремінь безпеки в автомобілі — ви не помічаєте його, поки він не врятує вас.

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

3.2 Визначення хуків

Модуль 3 · Хуки

Цілі уроку

Зрозуміти структуру визначення хука
Опанувати коди виходу (exit codes) та їх значення
Навчитися працювати зі stdin та stderr
Зрозуміти структуру JSON-даних, що передаються хуку

У попередньому уроці ви побачили, що хуки можуть. Тепер час зрозуміти, як вони влаштовані зсередини. Кожен хук — це маленька програма, що спілкується з Claude Code на чітко визначеній мові: JSON на вході, exit code на виході. Оволодійте цією мовою — і ви зможете створити будь-який хук.

Анатомія хука: 5 кроків

Створення хука — це п'ять простих кроків:

Тип: PreToolUse або PostToolUse?
Matcher: для яких інструментів спрацьовує?
Команда: що виконувати?
Exit code: 0 = дозволити, 2 = заблокувати
stderr: повідомлення для Claude (якщо потрібно)

Структура у settings.local.json

{ "hooks": { "PreToolUse": [ { "matcher": "Edit|Write", "command": "/шлях/до/скрипта.sh" } ], "PostToolUse": [ { "matcher": "Edit", "command": "/шлях/до/іншого-скрипта.sh" } ] } }

Matcher: фільтр інструментів

Matcher визначає, для яких інструментів спрацьовує хук. Подумайте про нього як про фільтр на дверях: ви вирішуєте, яких "гостей" перевіряти. Хуку на Edit не потрібно спрацьовувати, коли Claude просто читає файл. Matcher використовує pipe (|) для розділення кількох інструментів:

Matcher	Спрацьовує на
`Edit`	Тільки Edit
`Edit\|Write`	Edit або Write
`Read\|Grep`	Read або Grep
`Bash`	Виконання bash-команд
`.*`	Будь-який інструмент (regex)

Exit Codes: мова хуків

Exit Code 0 — "Дозволяю!"

Хук виконався успішно. Операція продовжується як звичайно.

Exit Code 2 — "Блокую!"

Хук заблокував операцію. Claude НЕ виконає дію і отримає повідомлення з stderr.

Будь-який інший Exit Code — помилка хука

Щось пішло не так з самим хуком. Операція продовжується за замовчуванням.

Тепер ви знаєте, як хук "відповідає" Claude. Але як хук "дізнається", що саме Claude намагається зробити? Через stdin.

stdin: дані від Claude

Коли хук спрацьовує, він отримує JSON через stdin з інформацією про операцію. Це як записка від Claude: "Ось що я збираюся зробити — вирішуй, чи можна":

{ "tool_name": "Edit", "tool_input": { "file_path": "/home/user/project/src/auth.ts", "old_string": "const secret = 'hardcoded'", "new_string": "const secret = process.env.SECRET" } }

Для Bash інструменту:

{ "tool_name": "Bash", "tool_input": { "command": "rm -rf /tmp/test" } }

stderr: зворотний зв'язок для Claude

Коли хук блокує операцію (exit code 2), він може написати повідомлення в stderr. Claude прочитає це повідомлення і зрозуміє, чому дію заблоковано:

#!/bin/bash # Якщо файл .env — блокуємо echo "ЗАБЛОКОВАНО: Доступ до .env файлів заборонений. Використовуй process.env для секретних значень." >&2 exit 2

Claude побачить це повідомлення і зможе адаптувати свою поведінку — наприклад, замість читання .env використати інший підхід.

Ключовий принцип

stderr — це не просто повідомлення про помилку. Це інструкція для Claude. Чим точніше ви опишете, що не так і що робити замість цього, тим краще Claude адаптується.

3.3 Практична реалізація

Модуль 3 · Хуки

Цілі уроку

Побудувати хук захисту .env файлів крок за кроком
Навчитися конфігурувати хуки у settings.local.json
Зрозуміти важливість перезапуску після змін

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

Крок за кроком: захист .env файлів

Давайте побудуємо повноцінний хук, який заблокує будь-які спроби Claude прочитати або змінити файли з секретами.

Крок 1: Створіть файл хука

mkdir -p .claude/hooks touch .claude/hooks/protect-env.js

Крок 2: Напишіть логіку

#!/usr/bin/env node // .claude/hooks/protect-env.js const fs = require('fs'); // Читаємо дані від Claude через stdin let input = ''; process.stdin.on('data', (chunk) => { input += chunk; }); process.stdin.on('end', () => { try { const data = JSON.parse(input); const toolInput = data.tool_input || {}; // Отримуємо шлях до файлу const filePath = toolInput.file_path || toolInput.path || ''; const command = toolInput.command || ''; // Список захищених файлів const protectedPatterns = [ /\.env$/, /\.env\..+$/, /\.secret$/, /credentials\./, /\.pem$/, /\.key$/ ]; // Перевіряємо шлях файлу const isProtected = protectedPatterns.some(p => p.test(filePath)); // Перевіряємо bash-команди const commandTargetsProtected = protectedPatterns.some(p => p.test(command) ); if (isProtected || commandTargetsProtected) { process.stderr.write( `ЗАБЛОКОВАНО: Файл "${filePath || command}" є секретним.\n` + `Використовуй process.env.VARIABLE замість прямого читання.\n` + `Якщо потрібен приклад конфігурації — дивись .env.example.` ); process.exit(2); // Блокуємо! } process.exit(0); // Дозволяємо } catch (err) { // Помилка парсингу — не блокуємо process.exit(0); } });

Крок 3: Зробіть файл виконуваним

chmod +x .claude/hooks/protect-env.js

Крок 4: Додайте конфігурацію

// .claude/settings.local.json { "hooks": { "PreToolUse": [ { "matcher": "Read|Edit|Write|Grep|Bash", "command": "node /повний/шлях/до/проєкту/.claude/hooks/protect-env.js" } ] } }

Важливо: використовуйте абсолютні шляхи!

У команді хука завжди використовуйте повний абсолютний шлях до скрипту. Відносні шляхи можуть не працювати коректно.

Крок 5: Перезапустіть Claude Code

# Вийдіть з поточної сесії (Ctrl+C або /exit) # Запустіть заново: claude

Критично: перезапуск обов'язковий!

Хуки завантажуються при старті Claude Code. Якщо ви змінили хук або додали новий — Claude Code обов'язково потрібно перезапустити, інакше зміни не набудуть чинності.

Тестуємо хук

Тепер спробуйте попросити Claude прочитати .env файл:

# У Claude Code: "Покажи мені вміст файлу .env" # Claude отримає повідомлення: # ЗАБЛОКОВАНО: Файл ".env" є секретним. # Він автоматично змінить підхід.

⏱ Цей хук захищатиме ваші секрети 24/7 без жодних зусиль

Альтернативний підхід: мінімальний хук

Ось спрощена версія того самого хука — мінімум коду, максимум зрозумілості:

Крок 3: Пишемо Node.js скрипт

Створіть файл hooks/read_hook.js:

#!/usr/bin/env node // Читаємо stdin (JSON від Claude Code) let data = ''; process.stdin.on('data', chunk => data += chunk); process.stdin.on('end', () => { try { const input = JSON.parse(data); // input містить: session_id, tool_name, tool_input const toolInput = input.tool_input || {}; const filePath = toolInput.file_path || toolInput.path || ''; // Перевіряємо чи файл — .env if (filePath.includes('.env')) { // stderr → повідомлення для Claude console.error('🚫 Заблоковано: читання .env файлу заборонено хуком безпеки'); // Exit code 2 = блокувати операцію process.exit(2); } // Exit code 0 = дозволити операцію process.exit(0); } catch (e) { // При помилці парсингу — дозволяємо (fail-open) process.exit(0); } });

Крок 4: Конфігурація в settings.local.json

Файл .claude/settings.local.json:

{ "hooks": { "PreToolUse": [ { "matcher": "read|grep", "hooks": [ { "type": "command", "command": "node /absolute/path/to/hooks/read_hook.js" } ] } ] } }

⚠️ Важливо

Перезапустіть Claude Code після зміни хуків — вони завантажуються при старті
console.error() надсилає feedback Claude через stderr
Хук спрацьовує для обох інструментів: read та grep
Використовуйте tool_input.file_path || tool_input.path для сумісності

Вправа: Розширте хук

Модифікуйте хук protect-env.js, щоб він також захищав:

Файли .secret
Файли з розширенням .p12 (сертифікати)
Будь-які файли в папці secrets/

Які рядки потрібно додати у масив protectedPatterns?

const protectedPatterns = [ /\.env$/, /\.env\..+$/, /\.secret$/, // Вже є! /credentials\./, /\.pem$/, /\.key$/, /\.p12$/, // Додано: сертифікати /\/secrets\//, // Додано: папка secrets/ ];

Всі три випадки покриті: .secret вже був, .p12 додано як новий паттерн, а /secrets/ ловить будь-який файл у цій папці.

3.4 Корисні хуки

Модуль 3 · Хуки

Цілі уроку

Побудувати хук для перевірки TypeScript типів
Побачити хук для запобігання дублюванню коду
Вивчити всі додаткові типи хуків
Навчитися дебажити хуки

Тепер, коли ви вмієте будувати хуки з нуля, давайте наповнимо ваш арсенал готовими рецептами. Кожен хук у цьому уроці вирішує конкретну проблему, з якою стикається кожен розробник. Беріть, адаптуйте під свій проєкт і використовуйте.

Хук 1: TypeScript Type Checker

Цей хук автоматично перевіряє TypeScript типи після кожного редагування .ts файлів:

#!/bin/bash # .claude/hooks/ts-check.sh # PostToolUse хук для Edit на .ts файлах INPUT=$(cat) FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty') # Перевіряємо чи це TypeScript файл if [[ "$FILE_PATH" == *.ts ]] || [[ "$FILE_PATH" == *.tsx ]]; then RESULT=$(npx tsc --noEmit 2>&1) if [ $? -ne 0 ]; then echo "TypeScript помилки знайдено:" >&2 echo "$RESULT" >&2 exit 2 # Повідомляємо Claude про помилки fi fi exit 0

Як це працює?

Після кожного Edit .ts файлу Claude Code автоматично запустить tsc --noEmit. Якщо є помилки типів — Claude отримає їх через stderr і зможе автоматично виправити, навіть без вашого втручання!

Хук 2: Duplicate Code Prevention

Цей хук — фантастичний, але дорогий. Він запускає другий екземпляр Claude для перевірки дублювання!

#!/bin/bash # .claude/hooks/dedup-check.sh # PostToolUse хук для Write (нові файли) INPUT=$(cat) FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty') if [ -z "$FILE_PATH" ]; then exit 0 fi # Запускаємо другий Claude для перевірки RESULT=$(claude -p "Перевір чи файл $FILE_PATH не дублює існуючу функціональність у проєкті. Якщо знайдеш дублювання — поверни DUPLICATE та вкажи які файли дублюються. Якщо все ОК — поверни UNIQUE." 2>&1) if echo "$RESULT" | grep -q "DUPLICATE"; then echo "Можливе дублювання коду:" >&2 echo "$RESULT" >&2 exit 2 fi exit 0

Trade-off: якість vs вартість

Цей хук запускає другий Claude на кожне створення файлу. Це:

+ Ефективно запобігає дублюванню
+ Знаходить неочевидні повторення
- Повільніше (кілька секунд на перевірку)
- Дорожче (подвійне споживання токенів)

Рекомендація: використовуйте для великих проєктів де дублювання коштує дорожче за токени.

Всі типи хуків Claude Code

Крім PreToolUse та PostToolUse, є ще 7 типів. Це як повна панель датчиків у розумному будинку: одні спрацьовують при відкритті дверей, інші — при вимкненні світла, треті — при появі нового мешканця. Кожен тип хука дає вам контроль над іншим моментом у життєвому циклі сесії:

Тип хука	Коли спрацьовує	Може блокувати?
Notification	Коли Claude надсилає сповіщення (потрібен дозвіл на інструмент)	Ні
Stop	Коли Claude завершив відповідь	Ні
SubagentStop	Коли суб-агент (Task в UI) завершив роботу	Ні
PreCompact	Перед операцією compact (ручною або автоматичною)	Ні
UserPromptSubmit	Коли користувач надсилає промпт, перед обробкою Claude	Так (exit 2)
SessionStart	При старті або відновленні сесії	Ні
SessionEnd	При завершенні сесії	Ні

Різні формати stdin для різних хуків

⚠️ Головний gotcha

Формат stdin відрізняється залежно від типу хука! Ось два приклади для порівняння:

PostToolUse stdin (для TodoWrite):

{ "session_id": "9ecf22fa-edf8-4332-ae85-b6d5456eda64", "transcript_path": "<path_to_transcript>", "hook_event_name": "PostToolUse", "tool_name": "TodoWrite", "tool_input": { "todos": [{"content": "write a readme", "status": "pending", "priority": "medium", "id": "1"}] }, "tool_response": { "oldTodos": [], "newTodos": [{"content": "write a readme", "status": "pending", "priority": "medium", "id": "1"}] } }

Stop hook stdin:

{ "session_id": "af9f50b6-f042-4773-b3e2-c3a4814765ce", "transcript_path": "<path_to_transcript>", "hook_event_name": "Stop", "stop_hook_active": false }

Трюк для дебагу: jq-логер

Не знаєте, що приходить у stdin вашого хука? Створіть логер-хук:

{ "PostToolUse": { "matcher": "*", "hooks": [{ "type": "command", "command": "jq . > post-log.json" }] } }

Цей хук записує весь stdin у файл post-log.json. Після одного виконання відкрийте файл — і ви побачите точну структуру даних, яку отримує ваш хук.

Перевірка знань: Урок 3.4

1. Який exit code блокує операцію?

2. Що відбувається, коли PostToolUse хук повертає exit code 2?

Claude отримує повідомлення про проблему через stderr

Операція відкочується

Claude Code закривається

3. Який хук спрацьовує коли ви натискаєте Enter?

PreToolUse

SessionStart

UserPromptSubmit

4. Який недолік хука duplicate prevention?

Він не працює з TypeScript

Він запускає другий Claude, що дорого і повільно

Він блокує всі файли

3.5 Gotchas та безпека

Модуль 3 · Хуки

Цілі уроку

Зрозуміти ризики безпеки хуків
Навчитися правильно шерити хуки в команді
Уникнути найпоширеніших помилок

Хуки — потужний інструмент, але з ними легко вистрілити собі в ногу, якщо не знати про підводні камені. Цей урок — збірка найболючіших помилок, які роблять розробники при роботі з хуками. Прочитайте уважно — кожен пункт тут написаний "кров'ю" реального досвіду.

Gotcha #1: Абсолютні шляхи

Проблема: перехоплення шляхів

Якщо у хуці ви використовуєте відносний шлях до інтерпретатора:

// ПОГАНО: "command": "node hooks/protect-env.js" // Зловмисник може створити файл node у поточній папці // який перехопить виконання!

Правильно:

// ДОБРЕ: "command": "/usr/bin/node /home/user/project/.claude/hooks/protect-env.js"

Завжди використовуйте абсолютні шляхи і до інтерпретатора, і до скрипту. Це запобігає атакам path interception та binary planting.

Gotcha #2: Шерінг хуків у команді

Проблема шерінгу абсолютних шляхів

Абсолютні шляхи містять ваш конкретний шлях на вашій машині. Як ділитися настройками з командою?

Рішення: settings.example.json + $PWD

Паттерн для командної роботи

Створіть settings.example.json де шляхи містять плейсхолдер $PWD:
{ "hooks": { "PreToolUse": [{ "matcher": "read|grep", "hooks": [{ "type": "command", "command": "node $PWD/hooks/read_hook.js" }] }] } }
Створіть скрипт init-claude.js який замінює $PWD на реальний шлях:
const fs = require('fs'); const path = require('path'); const example = fs.readFileSync('.claude/settings.example.json', 'utf8'); const resolved = example.replace(/\$PWD/g, process.cwd()); fs.writeFileSync('.claude/settings.local.json', resolved); console.log('✅ settings.local.json створено з абсолютними шляхами');
Додайте в package.json: "setup": "npm install && node init-claude.js"
Додайте .claude/settings.local.json в .gitignore
Комітьте тільки settings.example.json

Тепер кожен член команди запускає npm run setup і отримує правильні абсолютні шляхи!

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

Gotcha #3: Різний stdin для різних хуків

Формат stdin залежить від типу хука!

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

Тип хука	Що приходить у stdin
PreToolUse / PostToolUse	`{"tool_name": "...", "tool_input": {...}}`
UserPromptSubmit	`{"prompt": "текст повідомлення"}`
Notification	`{"message": "..."}`
SessionStart / SessionEnd	`{"session_id": "..."}`
Stop	`{"reason": "...", "result": "..."}`

Не припускайте, що всі хуки отримують однаковий формат! Завжди перевіряйте наявність полів.

Gotcha #4: Не забувайте перезапуск

Claude Code кешує хуки при старті

Якщо ви змінили хук і нічого не відбулося — перевірте чи перезапустили Claude Code. Це найпоширеніша помилка при дебазі хуків!

Checklist безпеки хуків

Перед тим як комітити хук

✓ Абсолютні шляхи до інтерпретатора
✓ Абсолютні шляхи до скрипту
✓ settings.local.json у .gitignore
✓ settings.example.json + setup скрипт
✓ Перевірка наявності полів у stdin (defensive parsing)
✓ Graceful fallback (exit 0) при помилках парсингу
✓ Логування для дебагу

Вправа: Знайдіть проблеми безпеки

Знайдіть проблеми безпеки в цій конфігурації хуків:

{ "hooks": { "PreToolUse": [ { "matcher": ".*", "command": "python hooks/check.py" } ], "PostToolUse": [ { "matcher": "Edit", "command": "bash -c 'cd $PROJECT && node test.js'" } ] } }

Скільки проблем ви бачите?

Мінімум 4 проблеми:

Відносний шлях до python: python замість /usr/bin/python3 — можливий binary planting
Відносний шлях до скрипту: hooks/check.py замість абсолютного шляху
Відносний шлях до bash: bash замість /bin/bash
Змінна $PROJECT без лапок: якщо шлях має пробіли — поламається. Потрібно "$PROJECT"
Бонус: node test.js — node також без абсолютного шляху

4.1 Ефективні стратегії роботи

Модуль 4 · Майстерність

Цілі уроку

Навчитися стратегічно керувати контекстним вікном
Правильно комбінувати Plan + Think режими
Використовувати Memory для накопичення знань
Розуміти вартість токенів і оптимізувати витрати

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

Стратегія контекстного вікна

Метафора: Рюкзак альпініста

Контекстне вікно — як рюкзак альпініста. Він вміщує обмежену кількість речей. Якщо набити його непотрібним — не вистачить місця для важливого. Якщо покласти замало — не зможете досягти вершини.

Ваша задача — тримати в рюкзаку тільки те, що потрібно зараз.

Фаза 1: Свіжий старт (0-20% контексту)

CLAUDE.md завантажується автоматично
Це найкращий час для складних завдань
Використовуйте Plan Mode для великих задач

Фаза 2: Продуктивна зона (20-60% контексту)

Claude добре знає контекст вашого завдання
Ідеальний час для ітерацій та уточнень
Think Mode для глибоких проблем

Фаза 3: Попередження (60-80% контексту)

Час подумати про /compact
Не починайте нових великих задач
Завершуйте поточну роботу

Фаза 4: Критична зона (80%+ контексту)

/compact обов'язково
Або /clear якщо задача завершена
Claude попередить вас сам

Коли що використовувати: матриця рішень

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

Ситуація	Інструмент	Чому
Нова масштабна фіча	/clear → Plan Mode	Чистий старт + огляд зверху
Баг в одному файлі	Think Mode	Глибина важливіша за широту
Code review	Think Mode + @ файлів	Фокус на конкретних змінах
Контекст вичерпується	/compact з фокусом	Зберегти знання, звільнити місце
Claude зациклився	Double Escape → переформулювати	Відкат + новий підхід
Нове завдання (не пов'язане)	/clear	Старий контекст буде заважати
Помилка повторюється	Escape → # Memory	Навчити + запобігти назавжди

Контекстне вікно — ресурс для однієї сесії. Але є інструмент, який працює між сесіями, накопичуючи знання місяцями.

Мистецтво Memory

Досвідчені користувачі Claude Code активно використовують # Memory для накопичення знань проєкту. З часом ваш CLAUDE.md стає все точнішим — і Claude працює все краще. Це як колективна пам'ять команди, що ніколи не забуває.

Стратегія: "Навчи при помилці"

Кожного разу, коли Claude робить помилку:

Escape (зупинити)
# (Memory Mode)
Описати правило: "Ніколи не роби X. Замість цього роби Y."
Продовжити роботу

Через кілька тижнів ваш CLAUDE.md буде знати всі нюанси проєкту, і помилки зникнуть.

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

Оптимізація витрат токенів

Поради для економії

Конкретні промпти — "Виправи помилку на рядку 42" vs "Знайди і виправи всі помилки"
@ mentions — Claude не витрачає токени на пошук файлів, якщо ви вказуєте їх
/compact вчасно — не чекайте повного вікна
Одна задача за раз — не змішуйте різні завдання в одній сесії
CLAUDE.md — добрий CLAUDE.md = менше уточнень = менше токенів

Перевірка знань: Урок 4.1

1. Коли найкращий час для масштабних задач?

Коли контекстне вікно на 80%

Після /compact

На чистому старті (після /clear)

2. Яка стратегія найефективніша для навчання Claude вашому проєкту?

Щодня перечитувати CLAUDE.md

Escape → # Memory при кожній помилці

Ніколи не використовувати /clear

3. Що допомагає найбільше для економії токенів?

Конкретні промпти з @ mentions до потрібних файлів

Використання тільки Think Mode

Ніколи не використовувати Plan Mode

4. Що робити коли Claude зациклився на неправильному підході?

Повторити те саме завдання

Double Escape → переформулювати завдання

Перезапустити комп'ютер

4.2 Просунуті воркфлоу

Модуль 4 · Майстерність

Цілі уроку

Поєднати MCP + хуки + команди в єдиний пайплайн
Побудувати автоматизацію code review
Створити тестовий воркфлоу з хуками
Побачити приклад інфраструктурного рев'ю

Ви вже знаєте кастомні команди, MCP, хуки та SDK. Кожен з них — потужний інструмент сам по собі. Але справжня магія починається, коли ви збираєте їх в єдиний механізм. Уявіть конвеєр на заводі, де кожна ланка виконує свою функцію, а разом вони виробляють готовий продукт без людського втручання.

Сила комбінації

Окремо кожен інструмент вирішує одну задачу. Але поєднані разом, вони створюють щось більше за суму частин.

Метафора: Оркестр

Один музикант може зіграти мелодію. Але оркестр створює симфонію. Ваші кастомні команди — це ноти, MCP сервери — інструменти, хуки — диригент, а CLAUDE.md — партитура.

Воркфлоу 1: Автоматизований Code Review Pipeline

Компоненти:

Кастомна команда: /review — промпт для рев'ю
MCP Playwright: перевірка UI змін
PostToolUse хук: автоматичний запуск тестів
GitHub Action: інтеграція в CI

# Повний pipeline в дії: # 1. Розробник створює PR # 2. GitHub Action запускає Claude з командою /review # 3. Claude аналізує diff # 4. Playwright відкриває змінені сторінки # 5. PostToolUse хук запускає тести # 6. Claude збирає результати і пише коментар до PR: "## Code Review Results ### Якість коду: 8/10 - Добре: чисті абстракції, правильне іменування - Покращити: додати error boundaries до нових компонентів ### UI перевірка: ✅ - Головна сторінка: рендериться коректно - Кошик: нова кнопка на місці - Mobile responsive: ОК ### Тести: ✅ 47/47 passed ### Безпека: 1 попередження - Line 42: XSS ризик у user input rendering"

⏱ Економія: 2-3 години рев'ю на кожному PR

Code review — потужний приклад. Але автоматизувати можна не лише рев'ю, а й сам процес написання коду. Ось як виглядає автоматизований TDD.

Воркфлоу 2: Test-Driven Development з хуками

Автоматичний TDD цикл

# Конфігурація хуків: { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "command": "/usr/bin/node /project/.claude/hooks/auto-test.js" } ] } } # Хук auto-test.js: # 1. Перевіряє чи змінився .ts/.py файл # 2. Шукає відповідний тест-файл # 3. Якщо тест-файлу немає — повідомляє Claude через stderr # 4. Якщо є — запускає тести # 5. Повертає результат Claude

Результат: Claude автоматично запускає тести після кожної зміни коду. Якщо тести падають — він бачить помилки і виправляє їх. Якщо тест-файлу немає — він створює його.

TDD-воркфлоу чудово працює для коду. Але сучасні проєкти — це не тільки код, це ще й інфраструктура. І тут Claude Code теж може допомогти.

Воркфлоу 3: Інфраструктурний рев'ю

Приклад: Terraform PII Detection

Уявіть, що ваш проєкт використовує Terraform для інфраструктури. Ви можете створити хук, який перевіряє чи Terraform конфігурація випадково не зберігає персональні дані (PII) у незашифрованому вигляді:

# Кастомна команда /infra-review: Проаналізуй Terraform конфігурацію $ARGUMENTS: 1. Знайди всі ресурси що зберігають дані 2. Перевір шифрування at-rest та in-transit 3. Знайди PII (email, phone, address) що зберігається у plaintext 4. Перевір IAM policy — чи не надто широкі дозволи? 5. Знайди hardcoded секрети Для кожної проблеми: серйозність (Critical/High/Medium/Low), файл, рядок, рекомендація виправлення.

⏱ Економія: 4+ години аудиту інфраструктури

Побудуйте свій пайплайн

Вправа: Спроєктуйте end-to-end automation

Уявіть ваш реальний проєкт. Спроєктуйте повний пайплайн автоматизації, що включає:

Мінімум 2 кастомні команди
Мінімум 1 MCP сервер
Мінімум 2 хуки (1 PreToolUse + 1 PostToolUse)
GitHub Action workflow

Опишіть: які компоненти, як вони взаємодіють, що автоматизують.

Приклад: E-commerce проєкт (Next.js + PostgreSQL)

Команда /api-endpoint: створити новий API endpoint з валідацією, тестами та документацією
Команда /migration: створити SQL міграцію з rollback та seed data
Playwright MCP: перевірка UI після кожної зміни
PreToolUse хук: блокувати зміни в production міграціях (тільки нові)
PostToolUse хук: запускати type checker + unit тести після Edit
GitHub Action: /api-endpoint рев'ю + Playwright скріншоти на кожному PR

Взаємодія: PR → Action → Claude /api-endpoint review → Playwright screenshots → Хук тести → Коментар у PR

4.3 Командна робота з Claude Code

Модуль 4 · Майстерність

Цілі уроку

Організувати CLAUDE.md для командної роботи
Створити бібліотеку кастомних команд для всієї команди
Налаштувати спільні хуки
Спланувати онбординг нових членів команди

Досі ми говорили про індивідуальну продуктивність. Але справжня сила Claude Code розкривається, коли ним користується вся команда. Уявіть: кожен розробник працює з одним і тим самим контекстом, одними й тими самими командами, одними й тими самими правилами безпеки. Результат — не просто швидша робота, а стандартизована якість на рівні всієї команди.

Shared CLAUDE.md: одне джерело правди

Коли вся команда працює з Claude Code, CLAUDE.md в корені проєкту стає спільним документом — як і будь-який конфігураційний файл.

Структура командного CLAUDE.md

# Проєкт: [Назва] Версія: 2.1 | Оновлено: 2026-03-14 ## Архітектура [Короткий опис стеку та структури] ## Конвенції коду - Стиль іменування: camelCase (JS), snake_case (Python) - Коміти: Conventional Commits (feat:, fix:, chore:) - Гілки: feature/*, bugfix/*, release/* - PR: обов'язково рев'ю + passing CI ## Критичні правила 1. НІКОЛИ не змінюй файли у /migrations без міграційного скрипту 2. ЗАВЖДИ додавай тести для нового коду 3. НЕ використовуй any у TypeScript 4. Секрети ТІЛЬКИ через env variables ## Кастомні команди - /review — code review за нашим стандартом - /component — новий React компонент - /endpoint — новий API endpoint - /test — написати тести для файлу ## Ключові файли @src/config/database.ts — конфігурація БД @src/middleware/auth.ts — авторизація @docs/API.md — специфікація API

Порада: версіонування CLAUDE.md

Додайте дату оновлення і версію. Коли хтось змінює CLAUDE.md — це ревюїться як звичайний код через PR. Кожен член команди бачить зміни і може прокоментувати.

CLAUDE.md — це фундамент. Але одних правил недостатньо. Команді потрібні інструменти, щоб ці правила легко застосовувати.

Бібліотека команд для команди

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

.claude/commands/ # Загальні review.md # Code review за стандартом команди doc.md # Документування модуля # Frontend frontend/ component.md # Новий React компонент page.md # Нова сторінка hook.md # Кастомний React hook # Backend backend/ endpoint.md # Новий API endpoint migration.md # Міграція бази даних service.md # Новий сервіс # DevOps devops/ deploy-check.md # Перевірка перед деплоєм infra-review.md # Рев'ю інфраструктури

Спільні хуки

Команди та CLAUDE.md — це конвенції. Хуки — це гарантії. Ось набір хуків, з яких варто почати будь-якій команді. Подумайте про них як про правила техніки безпеки на будмайданчику: каска обов'язкова для всіх, без винятків.

Рекомендований набір хуків для команди

Хук	Тип	Для чого
protect-secrets	PreToolUse	Блокування доступу до .env, .key
type-check	PostToolUse	TypeScript перевірка після Edit
lint-on-save	PostToolUse	ESLint/Prettier після Edit
test-runner	PostToolUse	Тести для зміненого модуля
migration-guard	PreToolUse	Блокувати Edit існуючих міграцій

CLAUDE.md, команди, хуки — все налаштовано. Залишається головне питання: як швидко ввести нову людину в цю екосистему?

Онбординг нового члена команди

Чекліст онбордингу з Claude Code

Встановлення: npm install -g @anthropic-ai/claude-code
Клонування репо: Проєкт вже має CLAUDE.md та .claude/commands/
Налаштування хуків: bash setup-hooks.sh
Перший запуск: claude → "Розкажи мені про цей проєкт"
Тестове завдання: Використати /component для створення першого компонента
Персональні налаштування: Створити .claude/CLAUDE.local.md з преференціями

Час онбордингу з Claude Code: 30 хвилин замість звичайних 2-3 днів!

⏱ Економія: 2-3 дні онбордингу кожного нового розробника

Вправа: План онбордингу

Уявіть, що до вашої команди приходить новий junior-розробник. Він ніколи не використовував Claude Code. Складіть план першого дня:

Які розділи CLAUDE.md йому найважливіше прочитати?
Які 3 кастомні команди показати першими?
Яке тестове завдання дати?

1. Розділи CLAUDE.md:

"Архітектура" — щоб зрозуміти стек
"Конвенції коду" — щоб писати за стандартом
"Критичні правила" — щоб нічого не зламати

2. Перші 3 команди:

/review — щоб навчитися стандарту якості
/component або /endpoint — щоб створити перший код
/doc — щоб навчитися документувати

3. Тестове завдання:

"Використай /component для створення простого Button компонента. Потім використай /review щоб проревюїти свій же код. Нарешті, використай /doc щоб задокументувати."

Це навчить трьом ключовим воркфлоу за одне завдання.

4.4 Підсумки та наступні кроки

Модуль 4 · Майстерність

Цілі уроку

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

Ви пройшли довгий шлях. Від першого запитання "що таке Claude Code?" до побудови складних пайплайнів з хуками, MCP та GitHub Actions. Давайте зупинимося, озирнемось назад і закріпимо головне. Бо справжнє знання — це не те, що ви прочитали, а те, що залишилось після того, як ви забули деталі.

Ваша подорож: від нуля до майстерності

Модуль 1: Основи

Ви дізналися, що Claude Code — це агентний AI-інструмент у терміналі з системою Tool Use. Ви навчилися встановлювати, налаштовувати контекст через CLAUDE.md, використовувати Plan та Think режими, та керувати контекстним вікном.

Ключова метафора: Claude Code = персональний розробник у терміналі. Контекст = пальне для його двигуна.

Модуль 2: Автоматизація

Ви опанували кастомні команди (збережені промпти як slash-команди), MCP сервери (USB-порти для нових здатностей), GitHub інтеграцію (@claude + Actions) та SDK для скриптів і пайплайнів.

Ключова метафора: MCP = USB-порти. Команди = кнопки швидкого набору.

Модуль 3: Хуки

Ви побудували систему захисту та автоматизації: PreToolUse хуки блокують небезпечні операції, PostToolUse запускають перевірки. Ви навчилися працювати з exit codes, stdin/stderr, та безпечно шерити хуки в команді.

Ключова метафора: Хуки = камери спостереження + автоматичні двері.

Модуль 4: Майстерність

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

Ключова метафора: Оркестр — кожен інструмент окремо добрий, але разом вони створюють симфонію.

Чотири модулі, вісімнадцять уроків, десятки прикладів. Як це все запам'ятати? Не потрібно запам'ятовувати все. Запам'ятайте лише ці десять принципів — вони містять суть усього курсу.

10 принципів майстерності Claude Code

Запам'ятайте ці принципи

Контекст — це все. Якісний CLAUDE.md = якісний результат.
Plan для широти, Think для глибини. Не плутайте.
Навчайте при помилці. Escape → # → правило.
Автоматизуйте повторення. Якщо робите щось двічі — створіть команду.
Розширюйте через MCP. Браузер, бази даних, API — підключайте все.
Захищайте через хуки. Промпти — рекомендації. Хуки — закони.
Керуйте контекстом. /compact вчасно, /clear коли треба.
Працюйте як команда. Спільні CLAUDE.md, команди, хуки.
Ітеруйте швидко. Plan → Code → Test → Fix — все в одній сесії.
Довіряйте, але перевіряйте. Claude потужний, але не безпомильний.

Десять принципів — це ваш компас. А тепер давайте додамо до нього карту: ресурси, які допоможуть вам продовжувати рости як майстру Claude Code.

Ресурси для подальшого навчання

Корисні посилання

Документація Claude Code: docs.anthropic.com/claude-code
MCP специфікація: modelcontextprotocol.io
GitHub Claude Action: github.com/anthropics/claude-code-action
Claude Code SDK: npmjs.com/package/@anthropic-ai/claude-code
Спільнота: discord.gg/anthropic

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

Фінальний квіз

Фінальна перевірка знань: Весь курс

1. Як Claude Code шукає код у проєкті (на відміну від більшості IDE assistants)?

Через хмарну індексацію ембедінгів

Через прямий grep/glob у терміналі

Через API GitHub Copilot

2. Яка різниця між Plan Mode і Think Mode?

Plan Mode для одного файлу, Think Mode для багатьох

Plan Mode дешевший, Think Mode дорожчий

Plan Mode для широких задач (архітектура), Think Mode для глибоких (один складний баг)

3. Що робить exit code 2 у хуці?

Блокує операцію та надсилає повідомлення Claude через stderr

Дозволяє операцію

Перезапускає Claude Code

4. Де зберігаються кастомні команди?

У CLAUDE.md

У .claude/commands/ як .md файли

У package.json

5. Яка найкраща стратегія для навчання Claude вашому проєкту з часом?

Перечитувати документацію

Завжди використовувати Plan Mode

Escape → # Memory при кожній помилці + якісний CLAUDE.md

Вітаємо!

Курс Claude Code Mastery завершено!

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

Тепер застосовуйте ці знання у реальних проєктах.

Пам'ятайте: найкращий спосіб навчитися — це практика. Створіть CLAUDE.md для свого проєкту, напишіть перші кастомні команди, поставте хуки — і Claude Code стане вашим найвірнішим напарником у розробці.