CLAUDE.md: постійні орієнтири для Claude Code

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

У цій главі Application Programming Interface (API) означає інтерфейс, через який інші програми звертаються до сервісу. Ми розглянемо, як спроєктувати коротку інструкцію саме для Claude Code, знайти її правильне місце, перевірити завантаження й підтримувати її актуальною. Ця глава продовжує розділи 24–28: вони вже пояснюють обмеження контексту, джерела істини, архітектуру знань та різницю між завантаженням, пріоритетом і технічним контролем. Тут зосередимося на роботі з самим файлом.

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

29.1. Для чого потрібен CLAUDE.md

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

Додавайте правило, коли є повторювана причина: агент уже двічі пропустив потрібний документ, рецензент знаходить ту саму помилку або новому члену команди доводиться пояснювати спільну домовленість. Формулюйте правило так, щоб людина могла перевірити його виконання. «Пиши якісний код» не називає спостережуваної дії. «Для зміни переходів бронювання прочитай опис життєвого циклу та онови його тести» дає точну дію і межу.

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

29.2. Де Claude Code знаходить інструкції

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

Область	Розташування	Типове призначення
Організація	macOS: /Library/Application Support/ClaudeCode/CLAUDE.md; Linux і підсистема Windows для Linux (Windows Subsystem for Linux, WSL): /etc/claude-code/CLAUDE.md; Windows: C:\Program Files\ClaudeCode\CLAUDE.md	Спільні стандарти, які розгортає організація
Користувач	~/.claude/CLAUDE.md	Особисті вподобання для різних проєктів
Проєкт	./CLAUDE.md або ./.claude/CLAUDE.md	Командні домовленості, які зберігаються з проєктом
Локальний проєкт	./CLAUDE.local.md	Особисті нотатки лише для цього клону; додайте файл у .gitignore

Коли Claude Code запускається з каталогу проєкту, він завантажує CLAUDE.md і CLAUDE.local.md з цього каталогу та його батьківських каталогів. Уміст зібраних файлів поєднується в контекст; вищий за деревом каталог надається раніше, нижчий — пізніше. У межах одного каталогу локальний файл додається після командного. Це опис того, в якому порядку модель бачить текст, а не механізм технічного блокування чи загальне правило для інших продуктів.

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

Сумісність з AGENTS.md

AGENTS.md — назва інструкційного файла, яку використовують деякі інші засоби розробки. У режимі за замовчуванням Claude Code читає AGENTS.md замість проєктного CLAUDE.md, якщо в робочому каталозі або вище немає CLAUDE.md, .claude/CLAUDE.md чи CLAUDE.local.md. Файл ~/.claude/CLAUDE.md, організаційний CLAUDE.md і .claude/rules/ не змінюють цю перевірку.

Налаштування Project instructions відкривається командою /config. Залежно від вибраного режиму Claude Code може читати один тип файлів або обидва:

Режим	Які проєктні інструкції вибирає
claude-md-or-agents-md	CLAUDE.md або AGENTS.md; за замовчуванням шукає сумісний файл за описаною вище умовою.
claude-md-and-agents-md	Обидва типи — CLAUDE.md і AGENTS.md.
claude-md	Лише CLAUDE.md.
managed-only	На старті лише керований організаційний CLAUDE.md та автоматична пам’ять.

Цей вибір не вимикає завантаження вкладених CLAUDE.md, .claude/rules/ чи шляхових правил, коли Claude читає відповідні файли. Перевірте фактичне налаштування проєкту, особливо якщо в репозиторії є обидва типи файлів або персональний локальний CLAUDE.local.md.

Тут важливо розрізняти три версійні факти, перевірені 23–26 вересня 2026 року:

• Чинна документація вказує, що пряме читання AGENTS.md підтримується у Claude Code від версії 2.1.277. Деякі сесії з вимкненим збором прапорців функцій, через стороннього постачальника або з вимкненим вбудованим модулем можуть цього не робити; перша сесія після оновлення також може не завантажити файл.
• В офіційному списку випусків версія 2.1.283, оприлюднена 25 вересня, вже була найновішою станом на 26 вересня. Попередній дослідницький знімок із версією 2.1.278 як найновішою застарів після наступних випусків.
• У версіях до 2.1.280 команди /memory та /context не показували AGENTS.md, який Claude прочитав безпосередньо. Тому в старій версії відсутність файла у цьому списку сама по собі не доводить, що завантаження не відбулося.

Для файлів CLAUDE.md документація пропонує запустити /context і перевірити список Memory files. Після зміни інструкції найнадійніше почати нову сесію і знову перевірити список. Є задокументована точка повторного читання: після /compact Claude Code читає кореневий проєктний CLAUDE.md з диска й знову додає його до контексту; вкладені CLAUDE.md та правила з paths: підвантажуються, коли Claude читає файли, до яких вони належать. Це не означає, що будь-яке редагування всіх уже завантажених інструкцій автоматично й негайно змінює поточний контекст. Якщо поведінка важлива, перевірте фактично завантажений файл у новій сесії або на задокументованій точці оновлення.

Імпорти

Щоб обов’язково додати текст іншого файла до контексту, Claude Code підтримує імпорт у вигляді @шлях/до/файла. Імпорт розгортається під час завантаження. Відносний шлях рахується від файла, у якому записано імпорт, а не від поточного каталогу. Вкладені імпорти можна поєднувати максимум на чотири переходи. Абсолютні шляхи дозволені. Перший імпорт із проєктного файла за межі робочого каталогу потребує схвалення користувача.

Імпорт — це не просто посилання: весь уміст потрапляє до контексту та витрачає його місткість. Наприклад, @docs/reservation-policy.md включає цей файл у кожну відповідну сесію; запис `docs/reservation-policy.md` лише називає місце, куди Claude має перейти, коли це потрібно. Для докладної довідки або великої процедури зазвичай достатньо короткого посилання. Не додавайте імпорт лише для того, щоб файл «точно знайшовся».

29.3. Який зміст лишити у файлі

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

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

Для кожної команди назвіть джерело перевірки: файл маніфесту, інструкція репозиторію або безперервна інтеграція (Continuous Integration, CI) — процес автоматичних перевірок змін. Якщо команда ще не перевірена, позначте це як припущення або спершу з’ясуйте. Назва команди у старому чаті не є доказом, що вона досі діє.

Не дублюйте цілі розділи README.md, опис архітектури чи всі рішення з журналу змін. Для маршрутизації достатньо сказати, який документ відповідає на яке питання: наприклад, README.md для першого запуску, docs/reservation-lifecycle.md для дозволених переходів і docs/decisions/ для зафіксованих архітектурних рішень. Якщо запис у CLAUDE.md суперечить цим актуальним джерелам, перевірте кожне твердження, погодьте з власником проєкту і виправте джерело, де живе помилка.

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

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

• Розмите: «Тестуй добре».
• Перевірне: «Після зміни переходів бронювання запусти pnpm test -- reservation; пакет визначає цю команду в package.json. У підсумку назви результати та неперевірені частини».
• Надто широко: «Не змінюй API».
• Обмежене: «Якщо зовнішня поведінка ендпойнта змінюється, онови openapi.yaml і тест, що фіксує новий контракт».

Anthropic рекомендує орієнтуватися на обсяг до 200 рядків у кожному файлі CLAUDE.md: великий текст витрачає контекст і може зменшити дотримання правил. Це рекомендація щодо практичної компактності, а не поріг, що сам визначає якість. Окрема технічна межа: поточна документація каже, що Claude Code пропускає файл CLAUDE.md, якщо його розмір перевищує 4 MiB. Імпортовані файли теж додають текст у контекст, тому розбити одну енциклопедію на десять автоматично імпортованих частин не означає зменшити її вартість.

29.4. Повний приклад 1: короткий файл сервісу бронювання

Нижче вигаданий репозиторій. Припустімо, що його package.json містить скрипт test, який запускає vitest run, а конфігурація безперервної інтеграції використовує той самий пакетний менеджер і lock-файл. Команди у прикладі доречні лише за цих умов; їх потрібно звірити у справжньому репозиторії.

# Reservation service

## Project map
- This repository runs the reservation API.
- `src/reservations/` owns reservation state transitions.
- `openapi.yaml` defines the public API contract.

## Local checks
- Install from the repository root: `pnpm install --frozen-lockfile`.
- Run unit tests: `pnpm test` (`package.json` maps `test` to `vitest run`).
- Report a check as passed only if you ran it and saw it succeed.

## Change guidance
- Before changing reservation states, read `docs/reservation-lifecycle.md` and `docs/decisions/ADR-004-idempotency.md`.
- Preserve idempotency: a repeated request with the same `Idempotency-Key` must not create a second active reservation.
- If public behavior changes, update `openapi.yaml` and the relevant tests.

## Final report
- List changed files, exact checks run, their outcomes, and checks you could not run.

Назви розділів описують призначення, щоб агент і людина могли швидко знайти правило. Перші три рядки показують малу карту репозиторію та його справжній контракт замість довгої копії README.md. Блок перевірок фіксує команди й джерело команди test; коли маніфест зміниться, змінити треба й цей рядок. Блок зміни вказує на детальні документи, які потрібні лише для роботи над життєвим циклом, і стисло нагадує інваріант. Фінальний звіт вимагає розрізнити виконану перевірку та ту, яку не запускали.

ADR у назві файла означає Architecture Decision Record — запис архітектурного рішення. Idempotency-Key — ключ, який допомагає сервісу розпізнати повтор одного запиту; у цьому вигаданому прикладі повтор не створює ще одного активного бронювання. Це пояснення не задає схему для чужого проєкту: назву заголовка і поведінку слід підтвердити контрактом власного сервісу.

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

29.5. Повний приклад 2: журнал задач конфліктує з README

Уявімо вигаданий сайт футбольної статистики, який показує профілі гравців і зміни складів команд. Його кореневий CLAUDE.md виріс у копію чатів та планів. Один фрагмент у ньому говорить: «Пакет встановлюється через npm install, повний тест — npm test, імпортер транзакцій лежить у src/api/transactions/, а перебудову сторінки календаря ще не завершено». Водночас чинний README.md описує pnpm install --frozen-lockfile; package.json має packageManager: [email protected]; pnpm-lock.yaml та перевірка в CI відповідають новому менеджеру пакетів; каталог src/api/ видалено, а імпортер офіційних змін складу тепер у src/feeds/transactions/. Перелік незавершених робіт скопійовано з минулого кварталу. Читачеві не потрібно знати правила конкретного виду футболу: приклад стосується лише шляху коду й перевірених джерел проєкту.

Агент, який прочитав обидва документи, може побачити несумісні команди й стару карту дерева. Проблема не вирішується правилом «завжди слухай CLAUDE.md»: файл є маршрутом до знань, а не гарантованою правдою про файлову систему. Перевірте конкретні твердження у джерелах, які відповідають за запуск, скрипти та поточне розташування коду. У наведеному сценарії маніфест, lock-файл, CI та дерево підтверджують актуальну картину; наздоганяти їх застарілим журналом недоречно.

Перероблений постійний файл містить тільки те, що має сенс у наступних сесіях:

# Football statistics service

## Start and tests
- For the current quickstart, follow `README.md`.
- Use `pnpm`; its pinned version is declared in `package.json`.
- Run the unit suite with `pnpm test` after confirming the script in `package.json`.

## Project map
- Official roster transaction adapters live in `src/feeds/transactions/`.
- Player profiles live in `src/players/`; roster history is specified in `docs/roster-history.md`.
- `openapi.yaml` is the public API contract.

## Read before changing roster history
- Read `docs/roster-history.md` and the relevant decision records.
- Keep documentation current when the public behavior or supported commands change.

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

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

29.6. Повний приклад 3: команда тесту застаріла

Уявімо окрему зміну: файл інструкцій ще говорить «запусти npm test», але після переходу проєкту на pnpm команда в README.md і робочому процесі перевірок змінилася на pnpm test. Людина повідомляє, що агент витратив час на відсутні залежності або записав неправильну команду у звіт. Сам симптом не доводить, що коренем є саме CLAUDE.md: сесія могла стартувати не з того каталогу, файл міг бути відсутнім у контексті або налаштування могли змінити набір інструкцій.

Спершу перевіряють завантаження й джерела без зміни коду:

1. У Claude Code виконують claude --version та звіряють, що сесія працює з потрібним продуктом і версією.
2. Виконують /context і перевіряють, чи містить список Memory files потрібний CLAUDE.md. Для старої версії згадане вище обмеження щодо прямого AGENTS.md не слід трактувати як відсутність самого файла.
3. Читають актуальні README.md, package.json, lock-файл і workflow безперервної інтеграції. Звіряють менеджер пакетів, оголошений скрипт і команду, яку реально використовує автоматична перевірка.
4. Якщо ці джерела все ще суперечать одне одному, визначають власника та з’ясовують намір. Не змінюють README або команду тесту навмання лише через конфлікт текстів.
5. Оновлюють CLAUDE.md на перевірену команду або, якщо простіше, прибирають повтор команди та спрямовують агента до єдиного актуального джерела.
6. Для перевірки завантажують нову сесію, перевіряють /context, потім просять Claude назвати поточну команду і джерело. Це перевіряє, чи інструкція видима та зрозуміла; саме по собі не доводить, що тест пройшов.

Якщо домовлена команда — pnpm test, відредагований фрагмент може бути таким:

## Tests
- Run the unit suite with `pnpm test`; the script is defined in `package.json`.
- Run it from the repository root with the lockfile-based install completed.
- In your report, say whether the command actually ran and include the result.

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

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

29.7. Коли потрібен інший механізм

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

Механізм	Що там тримати	Приклад межі
CLAUDE.md	Короткі стабільні факти й звички для широкої частини роботи в Claude Code	«Для зміни контракту синхронізуй опис і тест»
.claude/rules/	Тематичні інструкції, особливо прив’язані до конкретних шляхів або типів файлів	Детальні вимоги лише до src/http/
Skill із SKILL.md	Повторювана процедура, довідка або багатокрокова робота, яку потрібно завантажувати за потреби	Рецензування міграції за чек-листом
Налаштування settings.json	Вибір моделі, змінні середовища, гачки та доступ до інструментів	Де дозволити, запитати або заборонити виклик
Hook	Подієва автоматизація; PreToolUse може перевіряти виклик до його обробки	Зупинити конкретний виклик інструмента за умовою
Документація проєкту	Повні контракти, рішення, інструкції запуску та детальні процедури для людей	README.md, архітектурний опис, запис рішення

Правила в .claude/rules/ підтримують власні файли у цьому каталозі, а окремі правила можуть застосовуватися лише до заданих шляхів. Синтаксис і умови завантаження належать до окремої глави 30. Skill — це файл SKILL.md для знань і процедур, які Claude Code може використовувати, коли вони потрібні або коли його прямо викликають; докладно це розглянуто в главі 31. Не переносіть увесь їхній зміст у кореневий файл.

Налаштування Claude Code зберігаються у файлах JavaScript Object Notation (JSON — текстовому форматі структурованих даних), наприклад ~/.claude/settings.json, .claude/settings.json або .claude/settings.local.json. Спільні налаштування проєкту зберігаються у Git; локальні налаштування призначені для одного клону й мають бути виключені з Git. Набори permissions.allow, permissions.ask та permissions.deny задають правила доступу. Керований шар політик організації може мати ширшу дію. Точні значення та їхню область потрібно перевірити у чинних settings і permissions docs.

Гачки також задаються конфігурацією, але запускаються через визначені події. Зокрема, PreToolUse спрацьовує перед обробкою виклику інструмента і може дозволити, відхилити, попросити підтвердження чи відкласти його. За звичайної домовленості у CLAUDE.md немає такого механізму рішення. Текст «ніколи не видаляй production-таблицю» нагадує моделі про очікувану поведінку, але не є гарантією блокування. Якщо дія має бути технічно недоступною, потрібне налаштування дозволів або інша перевірена межа середовища, а не сильніше формулювання речення.

29.8. Як перевірити якість і підтримувати її

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

• Чи Claude Code завантажує файл із каталогу, де запускається сесія? Чи показує /context шлях потрібного файла?
• Чи спрямовує кожен маршрут до документа, який існує й справді відповідає за це твердження?
• Чи команди підтверджуються актуальним маніфестом, README або CI?
• Чи кожне правило має зрозумілу дію та область, чи можна перевірити результат?
• Чи залишилися старі задачі, суперечливі назви, дубльовані документи або припущення без джерела?
• Чи не містить файл секретів або даних, які не повинні бути в загальному контексті?
• Чи потрібне правило в кожній сесії, чи його слід перенести до документа, правила за шляхом, Skill або механізму контролю?

Перевірка завантаження та перевірка якості — різні результати. /context допомагає побачити, які файли включено, але не доводить, що кожна команда правильна або що модель точно виконає кожну вказівку. І навпаки, агент може виконати потрібне правило, навіть якщо автор не мав доказу, що воно було завантажене. Перевірте і джерело інструкції, і результат роботи, і технічні обмеження окремо.

Корисним прикладом версійованої зміни є відкритий репозиторій crytic/slither. У коміті від 20 січня 2026 року автори звузили надто спрощене правило обходу функцій у CLAUDE.md: замість поради завжди використовувати суфікс _declared вони розрізнили три типи аналізу. В описі коміту сказано, що попереднє формулювання вже спричинило некоректні зауваження під час перевірки коду. Це одиничний історичний приклад того, як правило може вимагати точнішої області та умов; він не є статистичним доказом ефективності інструкцій. Самі правила Slither залежать від внутрішніх типів цього інструмента, тому переносити їх до іншого проєкту не слід.

Під час змін коду переглядайте пов’язані рядки CLAUDE.md: команда могла змінитися, структура — переміститися, а архітектурний інваріант — отримати новий контракт. Коли правило більше не потрібне, видаліть його, а не залишайте як історичну довідку. Для змін, які впливають на широкий перелік сесій, зазначте у рецензії причину й джерело нової інформації.

29.9. Підсумок

CLAUDE.md корисний як компактний постійний путівник для Claude Code: важливі спільні домовленості, перевірені команди, критичні інваріанти та посилання до повніших джерел. Його розташування визначає область; імпорти завантажують додатковий текст у контекст; команда /context допомагає перевірити присутність файла. Для вибору, налаштування і технічного блокування існують інші механізми.

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

Джерела та подальше читання

Функції та версії Claude Code звірено 26 вересня 2026 року. Перевірені сторінки постачальників не показували окремої дати публікації чи номера редакції; тому дата нижче є датою доступу. Claude Code мінливий продукт: перед використанням точних шляхів і режимів перевірте актуальну документацію та версію встановленої програми.

1. Anthropic, How Claude remembers your project, доступ 26.09.2026. Підтверджує розташування й завантаження CLAUDE.md, імпорти, цільовий розмір, правила та відмінності підтримки AGENTS.md за версіями.
2. Anthropic, Settings files and precedence, доступ 26.09.2026. Описує області файлів налаштувань Claude Code та призначення керованих налаштувань.
3. Anthropic, Extend Claude with skills, доступ 26.09.2026. Пояснює, коли використовувати SKILL.md і як навички відрізняються від постійного вмісту CLAUDE.md.
4. Anthropic, Hooks reference та Configure permissions, доступ 26.09.2026. Підтверджують межі доступу й подієву поведінку гачків, включно з перевіркою PreToolUse.
5. Anthropic, Extend Claude Code, доступ 26.09.2026. Зіставляє постійний контекст, навички, гачки й інші розширення із завданнями, для яких їх призначено.
6. Anthropic, Claude Code v2.1.283, оприлюднений 25.09.2026 і показаний як найновіший 26.09.2026. Це орієнтир стану випусків на дату доступу, а не дата появи підтримки AGENTS.md.
7. OpenAI, Custom instructions with AGENTS.md, доступ 26.09.2026. Офіційний опис того, як Codex підбирає AGENTS.md для власних поверхонь. Первісне посилання на документацію Codex перенаправляє на цю сторінку. Її поведінка не задає семантику Claude Code.
8. crytic/slither, CLAUDE.md у зафіксованій ревізії і коміт b4da3e93e82991590ead901d5a950a51a258b947, 20.01.2026, доступ 26.09.2026. Первинне джерело для одного прикладу уточнення проєктної інструкції після помилкового відгуку рецензента; не рекомендація копіювати специфічні правила репозиторію.

Межі перевірки. Ця глава пояснює опубліковану документацію та один зафіксований приклад із відкритого GitHub. Для неї не налаштовували Claude Code, не перевіряли конкретний користувацький обліковий запис і не запускали прикладні команди. Ілюстративний файл не є готовою конфігурацією для іншого репозиторію.