Вот ловушка, в которую попадаются почти все: ваш файл CLAUDE.md постоянно растёт. Столкнулись с проблемой — добавили правило. Столкнулись с другой — добавили ещё одно. Вскоре у вас один гигантский файл, и Claude начинает игнорировать его части. Это не баг в Claude. Так этот файл работает.

Главное, что нужно понять: CLAUDE.md — это не принудительная конфигурация. Это рекомендации. Каждая строка конкурирует со всеми остальными за внимание Claude. Чем длиннее файл, тем сильнее он конкурирует сам с собой и тем менее надёжно Claude следует каждому отдельному правилу. Так что цель — не записать всё. Цель — держать файл компактным. Чем лаконичнее файл, тем большая его часть реально выполняется.

Сначала спросите, подходит ли вообще CLAUDE.md

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

Возьмём правило вроде "never push to main". Если положить его в CLAUDE.md, вы надеетесь, что Claude его прочитает и будет уважать. Чаще всего так и будет. Но «чаще всего» недостаточно для чего-то настолько опасного. Такое жёсткое правило должно жить в хуке pre-tool-use.

Разница важна. Хук — это код, который выполняется до действия Claude, и он реально может заблокировать действие. Так что даже если Claude попытается запушить в main, хук его остановит. Это настоящее принуждение, а не вежливая просьба. Перенесите жёсткие правила в хуки, а CLAUDE.md пусть занимается более мягкими соглашениями.

Четыре расположения

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

Вот для чего каждое из них:

• Managed policy — файл уровня организации, которым управляет ваша платформенная команда. Его нельзя исключить, так что политика организации действует всегда.

• User — ваши личные предпочтения, которые следуют за вами во всех проектах на вашей машине.

• Project — файл, общий для вашей команды, закоммиченный в репозиторий.

• Local — игнорируется git. Ваши личные заметки только для этого репозитория.

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

Разбивайте большой файл с помощью импортов

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

```

@.claude/conventions/code-style.md

@.claude/conventions/testing.md

@.claude/conventions/workflow.md

```

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

Формулировка — вот что заставляет правила работать

Когда вы решили, что правило должно жить в CLAUDE.md, будет ли Claude его реально соблюдать, зависит от формулировки. Большинство правил не работают, потому что они расплывчаты. Вот как это исправить.

Будьте конкретны и проверяемы

Не пишите "follow best practices". Вы сами-то точно знаете, что это значит? Если вы не можете проверить, было ли правило соблюдено, то и Claude не сможет. Сравните эти два варианта:

• Расплывчато: "Follow best practices for API routes."

• Конкретно: "Put new API routes in src/api/handlers, one per file."

Второй вариант явный. Можно посмотреть на результат и сразу сказать, сделано ли правильно. Этой планке должно соответствовать каждое правило.

Называйте замену, а не просто запрещайте

Когда вы говорите Claude чего-то не делать, скажите, что делать вместо этого. Иначе дверь останется открытой.

• Оставляет открытым: "Don't use default exports." Хорошо, а что тогда?

• Закрывает: "Use named exports, not default exports."

Вторая версия называет замену, так что неверному толкованию — не остаётся места.

Акцент — это бюджет

Такие слова, как "IMPORTANT" и "YOU MUST", действительно повышают приоритет правила. Но только относительно всего более тихого вокруг. Если кричит каждое правило, то ничего не выделяется и акцент ничего не значит. Так что относитесь к акценту как к бюджету. Тратьте его на два-три правила, нарушение которых действительно болезненно, а остальные пусть звучат на обычной громкости.

Держите файл в состоянии пересмотра

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

Когда Claude делает что-то не так, не просто вздыхайте и исправляйте вручную. Воспринимайте это как баг-репорт против вашего файла CLAUDE.md. Можно даже сказать Claude напрямую: "add that to the CLAUDE.md file", и он сам напишет правило. Так файл становится лучше каждый раз, когда что-то идёт не так.

Итог

Относитесь к своему CLAUDE.md как к продакшен-коду. Если не можете обосновать строку — удалите её. Чтобы файл оставался лаконичным и исполнимым:

• Перенесите жёсткие правила в хуки, где они реально принудительно исполняются.

• Организуйте длинные файлы с помощью импортов (только помните, что они не уменьшают контекст).

• Делайте каждое правило конкретным и проверяемым и называйте замену.

• Тратьте бюджет акцента на те немногие правила, которые важнее всего.

• Продолжайте пересматривать файл всякий раз, когда Claude что-то делает не так.

Идея проста. Чем лаконичнее файл, тем большая его часть выполняется Claude.