Перший місяць я користувався Claude Code у сирому вигляді. Я писав інструкції, тиснув Enter, читав вихідний код і виправляв його. Я думав, що цього достатньо. Але насправді це було схоже на їзду по трасі одразу після отримання прав лише на автомат — я навіть не використовував і половини його можливостей. Був момент, коли зміна лише семи налаштувань зробила поведінку на одне й те саме запитання просто невпізнанною.
Приємно познайомитися, я Hermes. Я практик, який щодня використовує AI у роботі, особливо Claude Code. Прочитавши цю статтю, ви заберете з собою ці сім налаштувань у формі, яку можна одразу спробувати, з реальними значеннями конфігурацій.
Цей контент — безкоштовний фрагмент моєї платної публікації на Note «Повний посібник із Claude Code». Для зацікавлених я залишу посилання в кінці.
Чому «сире» використання дає лише половину продуктивності
Якщо нічого не налаштувати, Claude Code починає кожну розмову зі стану, коли він нічого не знає про проєкт. Він не знає структури каталогів, конвенцій написання коду чи того, що потрібно перевірити перед коммітом. Тож навіть якщо ставити те саме питання, одного дня він може вгадати команду правильно, а іншого — створити файл не в тому місці.
Це не вада — це так задумано. В офіційній документації прямо зазначено, що «кожна сесія починається з чистого аркуша». Іншими словами, відповідальність за розкриття потенціалу лежить на користувачеві. Наведені нижче сім налаштувань — це конкретні кроки, щоб заповнити цей «чистий аркуш».
Сім налаштувань із наочними прикладами
1. CLAUDE.md — пам'ять проєкту
Якщо розмістити файл CLAUDE.md у корені проєкту, Claude Code читатиме його на початку кожної сесії. Без цього Claude доведеться щоразу здогадуватися з нуля.
Вміст варто писати з думкою: «Напишу це, щоб більше не виправляти ту саму помилку». Описуйте конкретні, перевірювані деталі, а не абстрактні філософії.
Опис проєкту: API для управління запасами (Node.js + PostgreSQL) Запускайте тести командою npm test / Завжди запускайте npm run lint перед коммітом Обробники API розташовані в src/api/handlers/
Замість «підтримуй код у чистоті» пишіть «відступ у 2 пробіли». Замість «тестуй належним чином» пишіть «запусти npm test». Ця різниця сама по собі значно змінює відсоток виконання інструкцій Claude. Оскільки вважається, що ефективність падає, якщо файл перевищує 200 рядків, хитрість полягає в тому, щоб перенести детальні процедури до налаштування 7 (Skills), про яке йтиметься далі.
2. hooks — механічне закріплення рішень
CLAUDE.md — це «прохання», а не «вимога». Це поширене непорозуміння: для Claude цілком нормально випадково пропустити інструкції. Правила, які ви точно хочете, щоб виконувалися, варто механічно блокувати за допомогою hooks.
Запишіть таке налаштування у .claude/settings.json:
Вкажіть hooks.PreToolUse із matcher: "Bash" Команда для виконання: ~/.claude/hooks/check-test.sh
Ось реальний приклад. До того, як я додав це налаштування, я часто стикався з таким: я просив Claude «виправити баг», і він одразу робив комміт після виправлення, не запускаючи тести, а я лише потім помічав, що тести зламані.
Налаштувавши hook на подію PreToolUse, скрипт перехоплює керування безпосередньо перед тим, як Claude виконує команду. Якщо цей скрипт повертає «код виходу 2», сама операція блокується.
Скрипт просто запускає npm test, якщо виявляє git commit Якщо тести не проходять, він виводить «Тести не пройдено» і повертає код виходу 2 Код виходу 2 — це сигнал для хука заблокувати виклик інструмента
З моменту, коли я додав цю одну деталь, комміт із червоними тестами став фізично неможливим. Сила hooks у тому, що перехід від «прохання» до «примусу» можна підтвердити, фактично запускаючи команди.
3. Субагенти — не забруднюйте основну розмову дослідженнями
Якщо змушувати його читати великі файли логів або досліджувати всю кодову базу, ця інформація накопичується в контексті розмови. Коли контекст забруднюється, точність виконання інструкцій у другій половині падає.
Щоб уникнути цього, використовуйте субагентів: дослідження та перевірка відбуваються в окремому вікні контексту, а в основний потік повертається лише підсумок. Наприклад, якщо ви попросите «дослідити реалізацію автентифікації в цьому репозиторії та розказати ключові моменти», процес дослідження (читання багатьох файлів і логів) відбувається в окремому вікні, а в основну розмову повертається лише висновок.
✗ Продовжувати дозволяти йому читати великі файли логів безпосередньо в основній розмові
◯ Виносити завдання через «доручи іншому агенту дослідити це і принести лише підсумок»
Завдання, які передбачають «багато читання заради отримання інформації», як-от результати тестів або пошук документів, особливо варто виносити на субагентів.
4. Plan Mode — змусьте його скласти план перед тим, як братися за справу
Під час складних змін Claude може раптово почати писати код у неправильному напрямку, змушуючи вас потім усе переробляти. Plan Mode — це режим, у якому він лише досліджує та планує, не вносячи жодних змін.
Перемкнутися в цей режим можна за допомогою Shift+Tab. У Plan Mode Claude читатиме файли та запускатиме дослідницькі команди, але не редагуватиме вихідний код. Коли план готовий, він презентується вам, і лише тоді ви вирішуєте, схвалити його чи ні.
Якщо щоразу казати «спершу запропонуй» набридло, можна зробити цей режим типовим у налаштуваннях проєкту.
Вкажіть permissions.defaultMode у settings.json як "plan"
Чим складніша зміна, тим більша переробка, якщо перший крок був неправильним. Plan Mode — це страховка від такої переробки.
5. Режими дозволів — визначте, де зупинитися
У Claude Code є кілька режимів, які щоразу запитують підтвердження перед редагуванням файлу чи виконанням команди, а також режими, які певною мірою діють автоматично. За замовчуванням він запитує підтвердження на все, окрім читання.
У щоденній роботі зручний баланс, коли редагування файлів відбувається автоматично, а решта потребує підтвердження. Цей баланс можна зробити типовим, записавши таке у файл налаштувань:
Вкажіть permissions.defaultMode у settings.json як "acceptEdits"
✗ Використовувати режим, який вимикає всі перевірки, лише тому, що «підтвердження — це нудно»
◯ Автоматизувати лише редагування файлів, залишаючи підтвердження для деструктивних операцій (наприклад, force push або деплой на продакшен)
За моїм досвідом, люди, які бездумно ставлять «повністю автоматично», потім дивуються несподіваним змінам. Згодом, коли звикнете й зрозумієте, де варто зупинитися, налаштування можна поступово послаблювати.
6. Керування контекстом — частіше прибирайте в кімнаті
Якщо тримати одну розмову нескінченно, у контексті залишається нерелевантна історія, витрачаючи токени та знижуючи точність відповідей.
Введіть /clear, щоб повністю очистити розмову, коли переходите до непов'язаної задачі. І все. Для розмов, до яких ви хочете повернутися пізніше, використовуйте /rename, щоб дати їм назву перед очищенням, — так ви зможете повернутися до них, не загубившись.
✗ Використовувати одну й ту саму розмову з ранку до вечора, з учорашніми непов'язаними темами, що досі висять
◯ Використовувати /clear на межах задач, а за потреби — спершу /rename
Якщо налаштування 3 (субагенти) — це «ізоляція досліджень у межах однієї задачі», то налаштування 6 — це «ізоляція між задачами». Лише роблячи обидва, ви зможете тримати контекст справді чистим.
7. Skills — тримайте процедури поза розмовою
Якщо постійно додавати процедури в CLAUDE.md, файл розростається, збільшуючи обсяг читання на початку кожної сесії. Більше того, процедури, які ви зазвичай не використовуєте, читатимуться навіть під час непов'язаних задач.
Ось тут у нагоді стають Skills. Якщо розмістити файл SKILL.md у .claude/skills/, він читатиметься лише тоді, коли виникне потреба. Якщо CLAUDE.md — це «пам'ять, яку потрібно читати щоразу», то Skill — це «інструкція, яку відкривають лише за потреби».
Наприклад, якщо у вас є довгі процедури, які використовуються нечасто, як-от кроки рев'ю PR або кроки міграції бази даних, перенесіть їх із CLAUDE.md на бік Skills. Щоденні розмови залишаються легкими, а розплачуєтеся за вагу лише тоді, коли це необхідно.
Підсумок — що буде без цих 7?
Ось ключові моменти.
Без CLAUDE.md Claude щоразу діє навмання. Без hooks узгоджені правила залишаються лише «проханнями» і можуть порушуватися. Без субагентів і /clear контекст забруднюється, і точність падає. Без Plan Mode ви берете на себе ризик переробки складних змін. Якщо налаштувати режими дозволів необережно, ви втрачаєте можливість зупинити несподівані операції. Без Skills CLAUDE.md стає дедалі важчим.
І навпаки, це також історія про «програєш, якщо не налаштуєш ці 7». Якщо ви читаєте це і досі не налаштували навіть CLAUDE.md або жодного разу не використали /clear — це ваша зона зростання.
Не обов'язково робити все одразу. Почніть із того, щоб використати лише CLAUDE.md і Plan Mode у сьогоднішній роботі. Навіть це дозволить вам одразу відчути різницю порівняно із «сирим» станом.
Я систематизував глибші налаштування та типові підводні камені з практики у своїй платній публікації на Note «Повний посібник із Claude Code». Для тих, кому цікаво, що після цих 7, — переходьте сюди.
