Файл контекста разрастается незаметно. Сначала это десяток правил, через месяц — двести строк, из которых работает четверть. Модель при этом ведёт себя хуже, чем в начале: чем больше в файле общих формулировок, тем меньше веса у конкретных.
Правило одной строки
Строка остаётся в файле, только если она меняет вывод модели. Всё остальное удаляется. Формулировка звучит грубо, но она единственная, которая работает без исключений, и документация Claude Code приводит её же на примерах: инструкция «Use 2-space indentation» меняет результат, инструкция «Format code properly» — нет, потому что модель и без неё считает, что форматирует код правильно.
Разница не в длине, а в проверяемости. «Пиши понятно» нельзя нарушить так, чтобы это было видно. «Первый абзац — не длиннее двух предложений» нарушить видно сразу.
Три вопроса к каждой строке
Пройдите файл сверху вниз и задайте к строке три вопроса. Первый: можно ли посмотреть на результат и однозначно сказать, соблюдено правило или нет. Если ответ зависит от вкуса — строка не работает. Второй: что изменится в выводе, если строку убрать. Если ничего — убирайте. Третий: не противоречит ли строка другим строкам файла. Это самый дорогой пункт: при двух конфликтующих правилах модель выбирает одно из них произвольно, и вы получаете нестабильный результат, причину которого потом ищете в промпте, а не в файле.
Типичный конфликт выглядит так: в одном месте «отвечай кратко», в другом «разбирай тему подробно, с примерами». Лечится не выбором одного из правил, а уровневой структурой: сначала короткий ответ, затем развёрнутая часть по запросу. Тогда оба требования выполняются в одном ответе и перестают спорить.
Что удаляется почти всегда
Вводные абзацы вроде «этот файл описывает правила работы» — модель уже знает, что читает инструкцию. Похвала и мотивирующие фразы. Смайлики и восклицательные знаки, если вы одновременно требуете сдержанный тон: файл сам себе противоречит стилем. Английские термины там, где есть русские: смешанная лексика в правилах даёт смешанную лексику в выводе. Повторы одного требования в трёх формулировках — они не усиливают правило, а размывают его.
Ориентир по объёму — до двухсот строк. Дальше файл перестаёт читаться целиком как набор жёстких требований и начинает работать как фон.
Где лежат правила и в каком порядке применяются
Инструкции подхватываются с нескольких уровней: политика организации, ваш личный файл в домашнем каталоге, файл проекта в его корне (./CLAUDE.md или ./.claude/CLAUDE.md) и локальный файл, который не уходит в репозиторий. Сборка идёт по дереву каталогов, поэтому правило проекта уточняет личное, а не отменяет его молча. Практический вывод: в личный файл идёт то, что верно для любой вашей работы (язык, тон, запрет на выдумывание источников), в файл проекта — то, что верно только здесь (структура папок, формат заголовков, имена полей).
Второе следствие важнее. Файл контекста подаётся модели как обычное сообщение после системного промпта. Это не настройка и не ограничение доступа. Строка «никогда не удаляй файлы» в нём — просьба, а не запрет, и надеяться на неё как на защиту нельзя.
Чужая ошибка: MEMORY.md пишете не вы
В руководствах по Claude часто советуют завести корневой MEMORY.md и начать его с заголовка и пометки, что здесь вы будете записывать наблюдения. Совет смешивает два разных слоя. Файл с таким именем действительно существует, но это индекс автопамяти, который ведёт сама модель: он лежит в служебном каталоге проекта, подгружается с ограничением по объёму, а тематические заметки рядом с ним подтягиваются по необходимости. Ваш слой — CLAUDE.md: то, что вы решили и хотите повторять. Слой модели — автопамять: то, что она вывела из работы.
Разделение имеет цену ошибки. Автопамять привязана к машине и не переносится сама между компьютерами и облачными сессиями, поэтому правило, положенное в неё вручную, на другом устройстве не сработает. Обратное тоже верно: ручные заметки в чужом слое затираются или игнорируются, и вы получаете правило, которое существует в файле, но не существует в поведении.
Как сократить файл за один проход
Возьмите текущий файл и перепишите каждое требование как утверждение о выводе: не «стиль должен быть деловым», а «без смайлики и восклицательных знаков». Не «учитывай SEO», а «ключевая фраза в заголовке и в первом абзаце». Не «проверяй факты», а «каждая цифра и дата — со ссылкой на первоисточник, без ссылки цифра не публикуется». После переписывания половина строк исчезнет сама: их нельзя превратить в утверждение о выводе, потому что они ничего о выводе не говорили.
Процедуры из файла лучше вынести отдельно. Если раздел вырос в последовательность шагов, ему место в навыке, который загружается только при вызове, а не в файле, который читается каждый раз. Разбор этого разделения — в материале Правило, навык или хук.
