Claude Code завантажує CLAUDE.md повністю на початку кожної сесії та постійно тримає його в пам'яті. Це означає, що за кожен рядок у цьому файлі ви «платите» токенами при кожному запиті — незалежно від того, чи потрібен він для конкретного завдання. У статті CLAUDE.md Is RAM, Not Disk я пропонував розділити пам'ять на два рівні: CLAUDE.md містить лише те, що Claude Code потребує постійно (стек, команди, інваріанти), а все інше переноситься в docs/ і завантажується лише за потреби. Так робоча пам'ять залишається мінімальною та економною, а довготривала — дешевою, бо вона опціональна.
Тоді я ще не використовував custom skills. Коли почав, спершу логічно відніс їх до «диска»: це деталі, які не потрібні Claude Code щоразу, тож їм місце серед матеріалів за запитом. Але я помилився. Перевіривши, як skills поводяться в контексті, я зрозумів чому. Skill — це не документ, який Claude відкриває, коли йому цікаво. Це радше програма, що запускається. Якщо сприймати її як диск, важливі правила (інваріанти) можуть опинитися за тригером, який просто не спрацює.
Ось оновлена модель із чотирма рівнями: CLAUDE.md — це RAM (ОЗП), правила з обмеженою областю (path-scoped rules) — це RAM із підкачуванням сторінок за запитом, skills — це встановлені програми, а docs/ — диск. Кожен рівень по-своєму відповідає на питання: коли це завантажується і що з ним стається потім. Правильна відповідь для конкретної інструкції автоматично визначає її рівень.
Перевірено на Claude Code v2.1.212 станом на 27 липня 2026 року. Бюджети лістингів та компакції можуть змінюватися, тому звіряйте цифри з актуальною документацією.
Чого не враховувала дворівнева модель
Раніше я запитував: чи потрібна ця інформація Claude Code щоразу, чи лише іноді? Це допомагало розмежувати CLAUDE.md та docs/, але припускало лише два сценарії завантаження: або файл резидентний від початку, або завантажується, коли Claude Code вирішує його відкрити. Проте path-scoped rules та skills завантажуються умовно, і це не те саме, що «Claude Code вирішив відкрити файл».
Правило (rule) завантажується, бо шлях до файлу збігся з шаблоном glob. Це детермінований процес, як і старт сесії, але обмежений областю видимості. Skill завантажується, бо Claude Code зіставив опис завдання з назвою у списку. Це імовірнісний процес: він базується на тексті, тому зазвичай спрацьовує, але іноді — ні. Якщо звалити все це в категорію «іноді» поруч із docs/, ми втратимо головну відмінність: чи гарантована поява контенту, коли він потрібен, чи це просто ймовірно.
Рівень 1: RAM (без змін)
CLAUDE.md працює так само, як і раніше: завантажується повністю на старті, залишається в пам'яті, перечитується з диска та повторно ін'єктується після команди /compact. Нові рівні не змінюють того, що має бути тут: стек, команди та кілька критичних інваріантів, які ніколи не мають порушуватися. Це єдиний рівень, де відповідь на питання «коли завантажується» завжди однакова: «завжди».
Рівень 2: RAM із підкачуванням за запитом (і виправлення до попереднього посту)
Трюк із вкладеними файлами CLAUDE.md працює, але зараз є кращий механізм. Якщо ви вже використовуєте вкладені файли, раджу мігрувати на .claude/rules/*.md. Файли в цій директорії з параметром paths: у frontmatter завантажуються в контекст так само, як і вкладені CLAUDE.md — коли Claude Code читає відповідний файл. Документація каже, що вкладений CLAUDE.md не ін'єктується повторно після /compact, а перезавантажується лише при наступному зверненні до піддиректорії. Мої тести показують, що правила (rules) поводяться аналогічно.
Якщо прибрати paths:, правило завантажиться на старті з таким же пріоритетом, як і сам .claude/CLAUDE.md. Тож .claude/rules/testing.md без frontmatter — це фактично перший рівень, просто в іншій папці. Рівень визначає не папка, а логіка завантаження.
Яка перевага правил над вкладеними CLAUDE.md? Glob дозволяє охоплювати структуру проєкту гнучкіше. Наприклад, правило «для всіх *.php у app/Domains, крім тестів» можна описати одним рядком. Крім того, всі правила лежать в одній папці: щоб переглянути всі умовні контексти, достатньо однієї команди ls, а не пошуку по всьому дереву каталогів. Поведінка та сама, форма — краща:
---
paths:
- "app/Domains/**/*.php"
---
# Domain layer rulesРівень 3: Встановлені програми
Назва та опис skill знаходяться у списку, який Claude Code бачить від початку сесії. Цей список має свій бюджет: приблизно 1% від контекстного вікна. Коли місце закінчується, Claude Code скорочує описи тих skills, які ви використовуєте найрідше. Це коштує небагато: проєкт може мати тридцять skills за ціною кількох абзаців у CLAUDE.md, доки більшість із них не активні.
Але як тільки skill спрацьовує, ситуація змінюється. Весь вміст SKILL.md потрапляє в контекст і залишається там до кінця сесії за тією ж ціною, що й CLAUDE.md. Команда /compact обробляє їх специфічно: перші 5000 токенів кожного активованого skill зберігаються (загальний ліміт — 25 000 токенів на всі skills), пріоритет надається тим, що запускалися останніми. Якщо ви активуєте забагато skills за довгу сесію, старіші будуть просто видалені з пам'яті без попередження.
Skill — це не RAM і не диск з двох причин. По-перше, він може містити скрипти, які виконуються поза контекстом: Claude Code отримує лише результат, чого не вміють CLAUDE.md чи docs/. По-друге, ви можете вимкнути автозапуск за допомогою disable-model-invocation: true. Тоді skill працюватиме лише через команду /name. Це прибирає ризик випадкового спрацювання, але змушує вас пам'ятати про команду. Важливо: цей прапор повністю прибирає назву та опис зі списку, тож такий skill не коштує нічого, доки ви його не викличете. Також skills можуть мати доступ до інструментів через allowed-tools, що робить їх більше схожими на конфігураційні файли, ніж на документацію. Хоча skills підтримують paths:, це лише фільтр для автозапуску, а не гарантія завантаження.
Skills — це не диск, бо диск пасивний. Skill — це встановлена програма, яка «спить», доки її не викличуть. Саме тому важливо не ховати інваріанти за тригерами skills. Якщо процедура не спрацює — Claude просто виконає кроки вручну. Якщо ж не спрацює важливе правило (інваріант), Claude Code просто його проігнорує, а покладатися на імовірнісний збіг тексту в таких питаннях не варто.
Рівень 4: Диск (без змін)
docs/ працює як і раніше. DESIGN.md, PLAN.md, DECISIONS.md — це великі тексти, які читають і люди. Вони завантажуються лише тоді, коли Claude Code вирішує перейти за посиланням. Це найслабша гарантія завантаження, і це правильно: диск — це рівень для матеріалів, де важлива доступність, а не стовідсоткова присутність у пам'яті.
Важливий нюанс: @docs/DESIGN.md всередині CLAUDE.md — це не посилання, а імпорт. Файл буде розгорнутий і завантажений у контекст повністю на старті. Тільки згадка шляху без символу @ (наприклад, docs/DESIGN.md) залишає файл на диску, доки Claude Code не знадобиться його прочитати.
Порівняння чотирьох рівнів
| Рівень | Механізм | Коли завантажується | Вартість у пам'яті | Чи виживає після /compact |
|---|---|---|---|---|
| 1. RAM | Кореневий CLAUDE.md | Повністю на старті сесії | Кожен запит | Так, перечитується та ін'єктується знову |
| 2. Demand-paged RAM | .claude/rules/*.md з paths: | Коли Claude Code читає відповідний файл | Кожен запит після завантаження | Ні, до наступного читання відповідного файлу |
| 3. Встановлені програми | Skill у .claude/skills/ | Опис завжди в списку (якщо не disabled); тіло — при тригері | Резидентно після активації | Перші 5000 токенів на skill (ліміт 25 000) |
| 4. Диск | docs/*.md (посилання за шляхом) | Тільки якщо Claude Code вирішить прочитати | Кожен запит після читання | Тільки те, що потрапило в summary |
Ці рівні — це градієнт впевненості. Рівень 1 — гарантований. Рівень 2 — гарантований для конкретних файлів. Рівень 3 — імовірний (або гарантований при ручному виклику). Рівень 4 — опціональний. Вибір рівня залежить від того, наскільки ви хочете бути впевнені, що Claude Code знає цю інструкцію.
Застосування у Laravel та event sourcing проєкті
У моєму стартовому репозиторії раніше було три рівні, тепер — усі чотири:
claude-code-laravel-starter/
├── CLAUDE.md # рівень 1: стек, команди, інваріанти
├── README.md
├── .claude/
│ ├── rules/
│ │ └── domain.md # рівень 2: paths: ["app/Domains/**/*.php"]
│ └── skills/
│ └── README.md # рівень 3: як встановити скіли
├── docs/
│ ├── DESIGN.md # рівень 4: доменна модель, агрегати, події
│ ├── PLAN.md # рівень 4: план реалізації
│ └── DECISIONS.md # рівень 4: лог архітектурних рішень (ADR)
└── app/
└── Domains/ # правила тепер замість вкладених CLAUDE.mdФайл domain.md містить правила для доменного шару: жодних імпортів фреймворку, агрегати лише записують події, події незмінні та в минулому часі. Тепер це правило лежить в одній папці з іншими, а не десь глибоко в дереві каталогів. У .claude/skills/ я не додаю фейкових прикладів, а описую встановлення реального інструменту — мого Laravel event sourcing skill, який допомагає проєктувати та генерувати агрегати, події та проектори прямо в діалозі.
Чотири головні висновки
Якщо Claude Code потребує інформацію щоразу — пишіть у CLAUDE.md. Якщо вона стосується лише певних файлів — створюйте правило (rule), а не вкладений CLAUDE.md. Якщо це покрокова процедура, скрипт або шаблон — створюйте skill (і додавайте disable-model-invocation: true для всього, що не має спрацьовувати автоматично). Якщо це великий текст для людей, який потрібен Claude лише іноді — залишайте на диску.
Дворівнева модель працювала непогано, але вона не давала відповіді на питання: куди покласти код, що має виконуватися.