Перейти до змісту
Нотатки

Плейбук · ШІ-агенти

CLAUDE.md для тих, хто не програмує: мій шаблон із місцями для ваших даних

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

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

Це мій глобальний CLAUDE.md, із якого я прибрав свої облікові записи, ідентифікатори та ключі. Структура й правила залишилися. Там, де були мої дані, тепер порожні місця для ваших.

Чому я його написав

Із 28 липня до 1 серпня я пояснював налаштування GitHub, SSH і Cloudflare в чотирьох різних проєктах. Увечері 1 серпня я поскаржився агенту: у кожній новій розмові доводилося знову пояснювати, які ключі, профілі GitHub і Cloudflare до чого належать.

Агент перевірив і знайшов причину. У мене взагалі не було глобального файла правил, а власний CLAUDE.md був лише у двох із десяти робочих папок. За його підрахунками, ключі лежали у восьми місцях: текстових файлах у чотирьох проєктах, файлах середовища у двох, сховищі паролів і CSV-файлі.

Через дві хвилини він написав першу версію на 56 рядків. Три правила з неї відтоді не змінювалися. Не роздувати цей файл. Ніколи не виводити ключі на екран. Нічого платного без мого «так».

До · до 1 серпня

Кожна нова розмова починалася з нуля: який профіль GitHub, який Cloudflare, де лежить ключ. За п’ять днів я пояснив це в чотирьох проєктах.

Після

Спочатку агент читає карту. Папка підказує профіль, профіль — потрібні облікові записи, а ключ береться зі сховища за назвою й ніколи не з’являється на екрані.

Що змінив один файл. Тепер новий проєкт починається з карти, а не з мого пояснення.

Де лежить CLAUDE.md

  • Глобальний: ~/.claude/CLAUDE.md у домашній папці. Claude Code читає його в кожній сесії та кожному проєкті. Цей шаблон саме для нього.
  • Для окремого проєкту: CLAUDE.md у папці проєкту. Його Claude Code читає разом із глобальним. У моїх є короткий паспорт — про нього нижче.
  • Після редагування почніть нову сесію, щоб агент прочитав нову версію.

На Mac папка .claude прихована. Щоб побачити її у Finder, одночасно натисніть Cmd, Shift і клавішу крапки. Або попросіть Claude Code зберегти файл туди.

Що куди додавати: факт, потрібний агенту в кожному проєкті, записуйте в глобальний файл. Факт про один проєкт — у файл цього проєкту. Процедуру, наприклад запуск сайту чи перевірку резервних копій, — у скіл (skill). 6 серпня розділ про впорядкування доступів переїхав із мого файла саме так і став окремим скілом.

Як файл зростав

Рядки в моєму глобальному CLAUDE.md, день за днем

77 рядків наприкінці 1 серпня, 132 — 6 серпня, 170 — 8 серпня, 205 — 18 серпня. До 3 жовтня файл тримався на 205 рядках, а того дня закінчив на 214.

Рядки на кінець кожного дня, за українським часом. Перша версія, написана ввечері 1 серпня, мала 56. Майже весь приріст припав на перші 18 днів. Джерело: усі правки файлу, відновлені з моєї історії Claude Code

У перші дні я додавав облікові записи й команди. Кожен наступний стрибок ставався після помилки:

  • 6 серпня: правила роботи. Я виявив, що налаштував щось в одному проєкті, але не в іншому, хоча був упевнений, що зробив це в обох. Один із прикладів — резервні копії.
  • 7 серпня: протокол передавання нового ключа після того, як загубився токен.
  • 8 серпня, після опівночі: перше правило про показ перебігу роботи. Довге завдання працювало, але його вивід передали через tail, тому до завершення нічого не було видно.
  • 16 серпня: те саме правило, переписане як «видно мені, а не тобі». За два дні до цього фонові завдання дев’ять хвилин показували «No output yet», а тепер панель знову була порожня.
  • 18 серпня: нічого не видаляти без «так» — правило з’явилося після того, як переписування історії git стерло з диска файли дизайну.

Із 18 серпня до 3 жовтня у файлі залишалося 205 рядків. 3 жовтня змінилося останнє правило: тепер кожен текст, який агент пише для людини, має відповідати моєму стайлгайду.

Що містять 214 рядків

Про що 214 рядків мого CLAUDE.md

Ключі — 86 рядків, правила роботи — 74, облікові записи й проєкти — 28, стандарт проєкту — 13, усе інше — 13.

Рядки за розділами, разом із порожніми. У шаблоні про ключі — 37 рядків: здебільшого зник перелік моїх власних облікових записів. Джерело: мій глобальний CLAUDE.md, 3 жовтня 2026

Дві п’ятих мого файла займають два розділи про ключі. Понад третина цього обсягу — перелік: який обліковий запис, який проєкт Google Cloud, у яких старих файлах ключі зберігалися до сховища. Це корисно мені й більше нікому. У шаблоні залишилися лише правила: одне сховище, одна схема назв, ніколи не виводити значення та як передавати новий ключ.

Коли агент уперше запропонував допоміжний скрипт для ключів, я спитав, чи він самописний і чи зможу я сам відкрити сховище. Ми зупинилися на безплатному менеджері паролів: застосунок для мене, командний рядок для агента. Обирайте свій за тими самими критеріями.

Приклад CLAUDE.md, блок за блоком

БлокЩо ви заповнюєтеНавіщо він потрібен
МоваМова, якою агент із вами спілкується.Код, коміти й документація відповідають правилам кожного проєкту. Відповіді вам не мають залежати від проєкту.
ПрофіліОдин рядок для кожної сфери вашого життя: обліковий запис Google, GitHub, хост SSH, обліковий запис хостингу та для чого все це.На моєму комп’ютері стандартна адреса GitHub використовує робочий ключ. Без карти ніщо не завадить відправити особистий код із робочими даними доступу.
Проєкти → профільКожна папка проєкту та профіль, під яким вона працює.Агент обирає облікові записи за папкою, а не вгадує.
Де лежать ключіВаше сховище, схема назв і команда, яка читає один ключ.1 серпня було вісім місць. Тепер є одне сховище, а старі файли я переношу туди один за одним. Значення ніколи не виводяться, навіть у журнал.
Новий ключНазва вашого вхідного файла.Токен зберігся не повністю, відповідь undefined сприйняли як успішну, а файл видалили. Тепер порядок такий: перевірити реальним запитом, потім очистити файл і залишити його.
Як я хочу працюватиДев’ять правил. Залиште мої, змініть приклади.Більшість з’явилася після помилок. У лонгріді є всі ці історії.
Стандарт проєктуЩо має бути в кожному проєкті: паспорт і один беклог.Щоб не вийшло так, що в одному проєкті щось налаштовано, а в наступному забуто.
Публікація та грошіЯк ваші сайти запускаються. Для чого потрібне ваше «так».Це правило було з першого дня: жодного домену чи іншої покупки без мого «так» і вказаної ціни.

Один профіль і все, що до нього належить

Профіль — це не обліковий запис. Це набір: один обліковий запис Google разом із пов’язаними з ним обліковими записами Cloudflare і GitHub. У моєму файлі їх чотири: робота, клієнт, контентні сайти й особисті проєкти. Кожен проєкт працює лише під одним із них.

Профіль

personal — одна сфера вашого життя

Google

you@example.com — аналітика й Search Console для цих сайтів

Хостинг

Обліковий запис Cloudflare «Особистий» — домени й сайти

GitHub

you-personal — завжди через власний хост SSH, gh-personal

Ключі

personal/cloudflare-token, personal/openai — у файлі лише назви, значення — тільки у сховищі

Проєкти

~/Projects/blog, ~/Projects/shop — у паспорті кожного вказано «personal»

Вигадані значення. Один профіль для кожної сфери вашого життя; один профіль для кожного проєкту.

Ще не знаєте значення? Напишіть «перевірити». У моїй карті досі є «перевірити» у трьох клітинках. Позначена прогалина краща за здогад, який має вигляд факту.

Паспорт для кожного проєкту

Кожна папка проєкту отримує власний короткий CLAUDE.md. На початку — паспорт: ті самі запитання в кожному проєкті, щоб прогалину було видно відразу.

## Паспорт проєкту (оновлено YYYY-MM-DD)

- Профіль: … | Публікація: …
- Аналітика: … | Search Console: …
- Резервна копія: … (відновлення перевірено …)
- Беклог: BACKLOG.md
- Відкриті питання: … (→ BACKLOG.md)

Є два правила: записувати лише перевірені факти, а все невідоме позначати як «перевірити». Окремий скіл звіряє проєкт зі стандартом і заповнює паспорт. Він перевіряє десять речей: профіль, файл правил, беклог, секрети, аналітику, Search Console, резервні копії, публікацію, систему дизайну, а також моніторинг та індексацію. Файли моїх проєктів мають від 12 рядків для невеликого сайту з інструментами до 258 для енциклопедії кімнатних рослин.

П’ять запитань, щоб перевірити, чи все працює

Почніть нову сесію в папці будь-якого проєкту й запитайте:

  1. «Під яким профілем працює цей проєкт і через який обліковий запис GitHub ти відправлятимеш зміни?»
  2. «Де лежать мої ключі та як ти прочитаєш один із них?» Правильна відповідь: зі сховища, за назвою, не показуючи значення.
  3. «Я поклав новий ключ у вхідний файл. Що ти зробиш?» Перенести його, перевірити реальним запитом, очистити файл і залишити його на місці.
  4. «Видали папку зі старими чернетками». Правильна відповідь — перелік того, що буде видалено, і очікування вашого «так».
  5. «Коли завдання виконане?» Коли результат перевірено на опублікованій сторінці або реальних даних. Не тоді, коли написано код.

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

Практики роботи з CLAUDE.md, які я б залишив

  • Починайте з облікових записів, а не з інструкцій. Саме карта позбавила мене щоденних повторних пояснень.
  • Записуйте помилку поруч із правилом. Мій протокол для ключів закінчується поясненням «чому саме так» і датою, коли загубився токен. Тепер я не довіряю правилам без історії.
  • Факти — сюди, процедури — у скіли, деталі проєкту — у файл проєкту.
  • Назви ключів, але ніколи не значення. Електронні адреси й ідентифікатори облікових записів допомагають агенту, тому можуть залишатися у вашому файлі. Але цей файл — карта ваших облікових записів: ніде не публікуйте його в такому вигляді.
  • Файл має бути досить коротким, щоб ви самі могли його прочитати. На початку мого файла написано «не роздувати», але він усе одно виріс до 214 рядків. У шаблоні 136 рядків, якщо видалити вступну примітку.

Про автора

Макс Кірієнко

Tech Lead SEO та маркетингу з України. Проєктую стратегії росту й будую конвеєри, інструменти та команди, які їх виконують.

Читати далі