Каждый раз, когда вы открываете новый чат с Claude Code, модель начинает с чистого листа. Она не помнит, о чём вы говорили вчера. Не знает, как устроен ваш проект. Не знает, какие у вас правила оформления текстов, какие команды нужно запускать и какие инструменты вы предпочитаете. Вы оказываетесь в ситуации, когда каждый разговор начинается с объяснений, которые вы давали уже десять раз.

CLAUDE.md решает эту проблему. Это обычный текстовый файл, который Claude Code автоматически читает в начале каждой сессии. Вы один раз записываете в него всё, что модель должна знать о вашем проекте, и дальше эта информация подгружается сама, без напоминаний с вашей стороны. Открыли новый чат — Claude уже в курсе ваших правил, ваших предпочтений и особенностей проекта.

По содержанию CLAUDE.md — это набор инструкций и фактов о проекте: какие технологии используются, как запускать приложение, какие есть соглашения в команде, на что обращать внимание. Формат простой — обычный текст с заголовками и списками, который удобно читать и человеку, и модели.

Если вы читали предыдущий урок про скиллы, может возникнуть вопрос: чем CLAUDE.md отличается от скилла? Разница принципиальная. CLAUDE.md загружается всегда, в каждом разговоре, автоматически. Это постоянная память проекта — то, что модель должна знать при любой задаче. Скилл загружается только когда он нужен: вы вызвали его командой или модель сама решила, что он подходит к текущему запросу. Поэтому в CLAUDE.md кладут короткие, универсальные вещи, а в скиллы — подробные инструкции по конкретным задачам.

CLAUDE.md можно хранить в нескольких местах, и от места зависит, кому и когда этот файл будет доступен. Это не просто вопрос удобства — это способ организовать инструкции по уровням: от личных предпочтений до командных стандартов.

Пользовательский файл хранится в вашей домашней директории по пути ~/.claude/CLAUDE.md. Всё, что вы сюда запишете, будет действовать во всех ваших проектах на этом компьютере. Сюда имеет смысл класть ваши персональные предпочтения: как вы любите получать ответы, какой стиль общения предпочитаете, какие инструменты используете постоянно.

Проектный файл лежит в корне проекта — просто CLAUDE.md в главной папке. Это самое распространённое расположение. Если вы работаете в команде, этот файл можно добавить в систему контроля версий (например, в Git), и тогда каждый участник команды автоматически получит одни и те же инструкции. Альтернативный вариант — положить файл в .claude/CLAUDE.md, если вы предпочитаете держать служебные файлы в отдельной папке.

Локальный файл называется CLAUDE.local.md и тоже лежит в корне проекта. Он предназначен для вещей, которые не нужно показывать другим участникам команды: ваши личные настройки для конкретного проекта, адреса тестовых серверов, предпочтения по работе с данными. Этот файл не попадает в систему контроля версий — он остаётся только у вас.

Файлы в поддиректориях. В больших проектах, где разные части кодовой базы живут по своим правилам, можно положить отдельный CLAUDE.md в каждую подпапку. Claude Code подхватит его не сразу при запуске, а в тот момент, когда начнёт работать с файлами из этой подпапки. Это удобно, когда в одном проекте соседствуют, например, мобильное приложение и серверная часть — у каждой могут быть свои соглашения.

Все эти файлы выстраиваются в иерархию. Более конкретные инструкции имеют приоритет над более общими: правила из проектного файла важнее правил из пользовательского, а правила из файла в подпапке важнее правил из корня проекта.

CLAUDE.md поддерживает импорт других файлов через символ @. Вместо того чтобы копировать содержимое большого документа прямо в CLAUDE.md, вы можете сослаться на него:

Claude Code прочитает указанные файлы и подтянет их содержимое. Ссылки могут быть вложенными — файл, на который вы сослались, тоже может ссылаться на другие файлы (до пяти уровней вложенности). Это позволяет держать сам CLAUDE.md компактным, а детали хранить в отдельных документах, где их удобно поддерживать и обновлять.

Это самый важный вопрос, и ответ на него определяет, будет ли ваш CLAUDE.md работать или превратится в длинный текст, который модель игнорирует.

Принцип простой: включайте то, что Claude не может узнать сам, изучив ваш проект. Исключайте то, что он и так знает или может легко выяснить.

Claude Code умеет читать файлы вашего проекта, просматривать структуру папок, изучать код. Если в вашем проекте уже используется определённый стиль оформления, модель с большой вероятностью подхватит его сама, просто посмотрев на существующие файлы. Объяснять ей стандартные вещи вроде «пиши чистый код» или «используй осмысленные названия переменных» бесполезно — это всё равно что напоминать опытному повару, что еда должна быть вкусной.

А вот чего Claude точно не может узнать сам — это ваших внутренних договорённостей, нестандартных решений и подводных камней, которые не видны из кода.

Описание проекта. Одно-два предложения о том, что это за проект и для чего он нужен. Может показаться очевидным, но для модели эта короткая фраза задаёт контекст всей дальнейшей работы. «Это сервис для автоматической оценки телефонных звонков» — и Claude уже понимает предметную область.

Команды. Как запустить проект, как прогнать тесты, как проверить код на ошибки. Claude не может угадать, что в вашем проекте тесты запускаются командой npm run test: e2e, а не npm test. Если у команд есть обязательные параметры или флаги, которые вы всегда используете, тоже запишите их.

Рабочие процессы. Если в вашей команде есть определённый порядок работы — например, перед каждым коммитом нужно прогнать проверку типов, или новые функции сначала обсуждаются в виде плана, — опишите это. Без такой инструкции Claude будет действовать по своему усмотрению, и его представление о правильном процессе может не совпасть с вашим.

Стиль кода, который отличается от стандартного. Если ваша команда договорилась об определённых соглашениях, которые не являются общепринятыми — например, вы используете именованные экспорты вместо экспортов по умолчанию, или предпочитаете конкретный формат сообщений при сохранении изменений в Git, — это стоит прописать. Стандартные соглашения языка программирования описывать не нужно, Claude их и так знает.

Архитектура. Как организован проект, какие папки за что отвечают, какие архитектурные решения были приняты и почему. Это особенно важно в больших проектах, где модели без подсказки будет сложно понять, куда класть новые файлы и как связаны разные части системы.

Терминология. Если в вашей предметной области есть специфические термины, которые Claude может не знать или понять неправильно, перечислите их с короткими пояснениями. Если вы работаете с медициной, финансами, логистикой или любой другой специализированной областью, пара строк с определениями сэкономит массу времени на объяснениях в каждом разговоре.

Подводные камни. Вещи, которые неочевидны из кода и могут привести к ошибкам. Например, что один из модулей нельзя менять напрямую, потому что он генерируется автоматически, или что определённый файл настроек требует специального формата.

Стандартные конвенции языка. Claude знает, как принято писать на Python, JavaScript, Go и других популярных языках. Объяснять ему базовые правила — пустая трата места в контексте.

Подробную документацию. Если у вас есть большой документ с описанием API или детальные спецификации, не копируйте их целиком в CLAUDE.md. Лучше сошлитесь на файл через @docs/api-spec.md — Claude прочитает его, когда ему понадобится.

Информацию, которая часто меняется. Если что-то устаревает каждую неделю, оно будет создавать путаницу, а не помогать. Лучше ссылаться на актуальный источник.

Очевидные вещи. «Пиши чистый и понятный код», «следуй лучшим практикам», «не забывай тестировать» — всё это не несёт никакой информации. Claude и без вас знает, что код должен быть понятным. Если вам нужно конкретное поведение, формулируйте конкретно.

Подробные описания каждого файла. Claude умеет читать файлы сам. Перечислять содержимое каждого модуля — это работа, которую модель может выполнить по запросу, и не нужно занимать этим постоянный контекст.

У CLAUDE.md нет обязательного формата — это обычный текстовый файл, и вы можете организовать его как угодно. Но некоторые подходы работают лучше других, потому что модели проще ориентироваться в хорошо организованном тексте.

Общий принцип: файл должен быть таким, чтобы новый человек в команде мог пробежать его глазами и за минуту понять самое важное о проекте. Если файл удобен для человека, он будет удобен и для модели.

Начинайте с короткого описания проекта — буквально одно предложение. Затем группируйте инструкции по темам, каждая тема под своим заголовком. Внутри темы используйте короткие пункты списка — одна мысль на строку. Команды и примеры кода оформляйте в блоках кода, чтобы они визуально отделялись от остального текста.

Вот пример файла для проекта, который помогает малому бизнесу вести учёт клиентов:

Обратите внимание на несколько вещей. Файл начинается с одного предложения, которое объясняет, что это за проект и на чём он построен. Команды записаны так, что их можно скопировать и вставить в терминал без изменений. Стилевые правила описывают только то, что отличается от стандартных соглашений. Архитектура показывает, какие папки за что отвечают, чтобы модель знала, куда класть новые файлы. Рабочий процесс фиксирует договорённости, которые нельзя узнать из кода. Терминология объясняет слова, которые имеют специфическое значение в контексте этого проекта.

Весь файл занимает около 30 строк. Это хороший ориентир для начала — по мере работы вы будете добавлять и убирать пункты, но стартовая версия не должна быть большой.

Всё, что вы записываете в CLAUDE.md, загружается в контекст модели при каждом разговоре. Каждая строка занимает место, которое могло бы быть использовано для вашей текущей задачи. И чем больше инструкций в файле, тем хуже модель следует каждой из них — не потому что она ленится, а потому что внимание распределяется на больший объём текста и неизбежно размывается.

Anthropic рекомендует простой тест: посмотрите на каждую строку в вашем CLAUDE.md и спросите себя — «Если убрать эту строку, Claude начнёт делать ошибки?». Если ответ «нет» или «не уверен» — строку лучше удалить. Если Claude и без этой инструкции делает всё правильно, значит, она только занимает место и мешает модели обращать внимание на действительно важные правила.

Есть характерный симптом раздутого файла: вы прописали правило, а Claude его игнорирует. Первая реакция — выделить правило жирным, добавить слово «ВАЖНО», продублировать в другом месте. Но проблема обычно не в том, что правило плохо сформулировано, а в том, что вокруг него слишком много всего остального. Модель теряет его в потоке инструкций. Правильное решение — не добавлять ещё текст, а убрать лишний.

Хороший ориентир — держать файл в пределах 50−150 строк. Некоторые команды обходятся ещё меньшим объёмом. Если вам кажется, что 150 строк — это мало для описания всех правил вашего проекта, значит, часть этих правил нужно вынести из CLAUDE.md.

Здесь работает тот же принцип прогрессивного раскрытия, о котором мы подробно говорили в уроке про скиллы. Вместо того чтобы записывать все подробности в один файл, вы оставляете в CLAUDE.md только ссылку с коротким пояснением, а детали храните в отдельном документе.

Например, у вас есть подробные стандарты оформления кода на 200 строк. Вставлять их целиком в CLAUDE.md — плохая идея, потому что они будут загружаться в каждом разговоре, даже когда вы обсуждаете с моделью архитектуру базы данных и оформление кода вообще не при чём. Вместо этого вы пишете в CLAUDE.md одну строку:

Claude Code увидит эту ссылку, но не будет загружать файл сразу. Когда дело дойдёт до написания или изменения кода, модель откроет документ и прочитает стандарты. В остальное время они не занимают место в контексте.

Этот подход позволяет описать сколько угодно правил и при этом сохранить CLAUDE.md лёгким. Главный файл превращается в оглавление: короткие описания и ссылки на детали. Модель получает карту проекта, а не энциклопедию.

CLAUDE.md — не документ, который пишется один раз и остаётся неизменным. Ваш проект развивается, в команде появляются новые договорённости, вы замечаете, что модель регулярно делает одну и ту же ошибку. Файл должен меняться вместе с проектом, иначе он постепенно устаревает и начинает приносить больше вреда, чем пользы — модель будет следовать инструкциям, которые уже не актуальны.

Самый естественный способ обновлять CLAUDE. md — делать это по ходу работы. Если вы заметили, что Claude запускает не ту команду для тестов, не просто поправьте его в чате, а добавьте нужную команду в файл. Если модель раз за разом кладёт новые файлы не в ту папку, допишите правило об архитектуре. Каждая ошибка модели — это сигнал, что в CLAUDE. md чего-то не хватает. Вы можете попросить Claude сделать это за вас прямо в разговоре: «Добавь в CLAUDE. md, что тесты серверной части запускаются командой такой-то».

Раз в несколько недель стоит пройтись по файлу целиком и навести порядок. За время работы инструкции накапливаются, некоторые начинают противоречить друг другу, другие становятся неактуальными, третьи дублируют то, что уже сказано в другом месте. Можно попросить Claude помочь с ревизией — отправьте ему файл и скажите: «Посмотри на этот CLAUDE. md и предложи, что можно убрать, объединить или переформулировать». Модель хорошо справляется с такими задачами, потому что видит текст свежим взглядом, без привычки к нему.

Если вы работаете в команде, CLAUDE. md стоит хранить в системе контроля версий вместе с остальным кодом проекта. Это даёт сразу несколько преимуществ. Во-первых, все участники команды работают с одним и тем же набором инструкций. Во-вторых, изменения в файле проходят через тот же процесс проверки, что и изменения в коде — коллеги могут посмотреть, что именно вы добавили, и предложить правки. В-третьих, если новая версия файла оказалась неудачной, всегда можно откатиться к предыдущей.

Для личных предпочтений, которые не нужны остальной команде, используйте CLAUDE.local.md — он не попадает в систему контроля версий и остаётся только у вас.

Отдельно стоит сказать про выделение критически важных правил. Если какое-то правило настолько важно, что его нарушение приводит к серьёзным проблемам, можно усилить формулировку словами ВАЖНО или ТЫ ОБЯЗАН — модель обращает на такие маркеры больше внимания. Но используйте это экономно. Если пометить каждое второе правило как критически важное, эффект исчезнет: модель не сможет отличить по-настоящему важное от всего остального.

Помимо файлов, которые вы пишете и поддерживаете сами, у Claude Code есть собственный блокнот для заметок. Эта функция называется автоматической памятью, и она работает параллельно с вашим CLAUDE. md, дополняя его.

Когда Claude Code работает над вашим проектом, он замечает вещи, которые могут пригодиться в будущем: какие команды используются для сборки, какие паттерны встречаются в коде, какие решения принимались при отладке сложных ошибок. Всё это он записывает в отдельные файлы, чтобы в следующей сессии не выяснять заново.

Заметки хранятся в специальной папке на вашем компьютере — для каждого проекта своя. Внутри лежит файл MEMORY. md, который выполняет роль оглавления, и при необходимости — дополнительные файлы по конкретным темам: отладка, архитектурные решения, соглашения по API и так далее. При запуске новой сессии Claude Code загружает первые 200 строк из MEMORY. md — этого обычно достаточно, чтобы освежить контекст. Если нужны подробности, модель сама заглянет в нужный файл.

Вы можете влиять на то, что Claude запоминает. Если хотите, чтобы модель сохранила конкретный факт, просто скажите об этом прямо: «Запомни, что для запуска тестов нужно сначала поднять локальную базу данных» или «Сохрани в память, что в этом проекте мы используем pnpm, а не npm». Claude запишет это в свои заметки, и в следующих сессиях уже не забудет.

Автоматическая память не заменяет CLAUDE. md, а дополняет его. Разница в том, кто пишет и для чего. CLAUDE. md пишете вы — это осознанные, продуманные инструкции, которые вы хотите донести до модели. Автоматическая память — это заметки, которые модель пишет сама для себя на основе того, что обнаружила в процессе работы. Первое — это ваш голос, второе — конспект модели.

Если вы хотите посмотреть или отредактировать заметки, которые Claude сделал о вашем проекте, используйте команду /memory прямо в сессии. Она откроет файл в текстовом редакторе, и вы сможете удалить неактуальное, поправить неточности или добавить что-то от себя.

Когда проект растёт, вместе с ним растёт и количество правил. В какой-то момент вы замечаете, что CLAUDE.md стал длинным, а внутри соседствуют инструкции, которые не имеют друг к другу никакого отношения: правила для серверного кода, соглашения по оформлению интерфейса, стандарты написания тестов, требования безопасности. Читать такой файл неудобно, поддерживать — ещё хуже, особенно если над ним работает несколько человек.

Для таких ситуаций в Claude Code есть механизм модульных правил. Вместо одного большого файла вы создаёте папку .claude/rules/ в корне проекта и раскладываете правила по отдельным файлам, каждый из которых посвящён одной теме:

Все файлы с расширением .md из этой папки автоматически загружаются вместе с основным CLAUDE. md, с тем же приоритетом. Не нужно ни на что ссылаться и ничего импортировать — просто положили файл в папку, и он работает. Папка может содержать и вложенные подпапки, Claude Code найдёт файлы на любой глубине.

У такого подхода есть практическое преимущество, которое проявляется в командной работе. Разные люди могут отвечать за разные файлы правил: фронтенд-разработчик поддерживает code-style.md, тестировщик — testing.md, специалист по безопасности — security.md. Никому не нужно разбираться в чужих разделах или бояться случайно сломать чужие правила при редактировании. Каждый работает со своим файлом, конфликтов не возникает.

Среди модульных правил есть особенно полезная возможность — привязать правило к конкретным файлам или папкам проекта. Это делается через небольшую шапку в начале файла правила:

Правило с такой шапкой применяется только тогда, когда Claude работает с файлами, подходящими под указанный шаблон. В данном случае — только с TypeScript-файлами из папки src/api/. Когда модель редактирует файлы интерфейса или тестов, это правило не загружается и не занимает место в контексте.

Это ещё один способ держать контекст чистым. Вместо того чтобы загружать все правила при каждом разговоре, вы говорите Claude Code: «Вот это применяй только при работе с серверным кодом, а вот это — только при работе с компонентами интерфейса». Модель получает только те инструкции, которые относятся к текущей задаче.

Модульные правила не обязательны для небольших проектов. Если ваш CLAUDE. md умещается в 50−100 строк и вы работаете над проектом в одиночку, одного файла вполне достаточно. Но если проект большой, команда растёт и правила множатся — разбивка по файлам помогает сохранить порядок и не раздувать контекст.

Хороший вопрос, и наверняка он возникнет у читателей. Давайте я добавлю пояснение прямо в этот блок, после описания модульных правил и перед разделом про привязку к файлам. Вот вставка:

На первый взгляд правила и скиллы похожи — и то, и другое представляет собой отдельные файлы с инструкциями для Claude. Но между ними есть принципиальная разница в том, когда и как они загружаются.

Правила из папки .claude/rules/ — это часть постоянной памяти проекта. Они загружаются автоматически в начале каждой сессии, точно так же, как сам CLAUDE. md. Вы не вызываете их вручную и не решаете, когда их подключить — они просто всегда на месте. По сути это тот же CLAUDE. md, только разбитый на отдельные файлы для удобства. Правила, привязанные к конкретным файлам через шапку paths, загружаются чуть умнее — только когда Claude работает с подходящими файлами, — но всё равно автоматически, без вашего участия.

Скиллы работают иначе. Они не загружаются при старте сессии. Claude видит только короткое описание каждого скилла и подключает его содержимое, когда скилл вызван — вами через команду /имя-скилла или самой моделью, если она решила, что он нужен для текущей задачи. После выполнения задачи скилл больше не занимает контекст.

Отсюда простой ориентир. Если инструкция нужна в каждом разговоре и относится к общим правилам проекта — это правило, и ему место в CLAUDE. md или в .claude/rules/. Если инструкция нужна только при выполнении конкретной задачи и содержит подробный порядок действий — это скилл, и ему место в .claude/skills/.

Например, соглашение «используем именованные экспорты» нужно всегда, когда Claude пишет код в вашем проекте, — это правило. А подробная редакционная политика на 400 строк для написания кейсов нужна только тогда, когда вы пишете кейс, — это скилл.

Напоследок — список проблем, которые встречаются чаще всего. Если что-то из этого покажется знакомым, вы будете знать, в чём причина и как исправить.

Файл разросся и перестал работать. Вы добавляли инструкции по мере работы, и в какой-то момент CLAUDE. md стал занимать несколько экранов. Claude начал игнорировать часть правил, причём не самые новые или самые старые, а произвольные — внимание модели размылось по всему объёму текста. Решение — безжалостная чистка. Пройдитесь по каждой строке и честно спросите себя, нужна ли она. Подробности вынесите в отдельные файлы и сошлитесь на них через @. После сокращения файла вы, скорее всего, заметите, что модель стала лучше следовать оставшимся правилам.

Дублирование инструкций. Одно и то же правило записано в двух местах разными словами. Или в CLAUDE. md описан стиль кода, и точно такое же описание есть в файле правил в .claude/rules/. Дубли не просто занимают лишнее место — они могут незаметно разойтись при обновлении, и модель получит противоречивые инструкции. Каждое правило должно жить только в одном месте.

Инструкции, которые Claude и так выполняет. Вы прописали «используй осмысленные названия переменных» или «обрабатывай возможные ошибки» — вещи, которые модель делает по умолчанию. Такие строки не улучшают поведение Claude, но занимают контекст и отвлекают внимание от правил, которые действительно меняют поведение модели. Если вы не уверены, нужна ли строка, попробуйте убрать её и посмотреть, изменится ли что-нибудь. Если нет — значит, она была лишней.

Файл написан и забыт. Проект изменился, команда перешла на другой инструмент для тестирования, часть соглашений по коду пересмотрели — а CLAUDE. md остался прежним. Модель продолжает следовать устаревшим инструкциям, и вы тратите время на то, чтобы поправлять её в каждом разговоре, вместо того чтобы один раз обновить файл. CLAUDE. md — это живой документ, который нуждается в регулярном пересмотре, точно так же, как и сам код проекта.

Попытка решить инструкцией то, что решается инструментом. Если вы прописали правила форматирования кода и хотите, чтобы Claude их соблюдал — лучше настроить автоматический форматировщик, который исправит оформление за доли секунды и без ошибок. Модель — дорогой и медленный способ расставлять отступы и запятые. Всё, что можно автоматизировать традиционными инструментами, стоит автоматизировать. В CLAUDE. md оставляйте то, с чем может справиться только модель: работу со смыслом, логикой и структурой.