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

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

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

Что уже умеем / что добавим

Вы владеете тремя механизмами: CLAUDE.md с уровнями и вложенными файлами, правила в .claude/rules/ с привязкой к путям и auto memory. Каждый разобран отдельно. Теперь соберём их в одну систему, добавим четвёртый вариант и выведем правило выбора, которым можно пользоваться не задумываясь.

Что вы узнаете в рамках статьи

• Чем различаются CLAUDE.md, правила и скиллы по моменту загрузки и области действия
• Как за пару вопросов определить подходящий механизм для конкретной инструкции
• По каким признакам понять, что инструкцию пора переносить в другое место
• Чего не гарантирует ни один из этих механизмов и что с этим делать
• Как система разрастается естественным путём, а не проектируется заранее

Ключевые термины

• Момент загрузки — когда содержимое попадает в контекст: при старте сессии, при обращении к подходящим файлам или по вызову.
• Скилл — markdown-файл со знаниями или сценарием, загружаемый по требованию: вручную командой /имя или самим Claude, когда он сочтёт содержимое уместным.
• Стоимость контекста — объём токенов, который механизм занимает в каждом запросе.
• Многошаговая процедура — последовательность действий, применимая целиком и не всегда: развёртывание, релиз, чек-лист ревью.
• Триггер — наблюдаемый признак, по которому пора завести или изменить механизм.

Три механизма и одна таблица

Все три хранят инструкции, различие — в моменте загрузки.

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

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

Подробности реализации скиллов — тема шестой главы. Здесь достаточно знать их место в системе.

Три вопроса для выбора

Практический алгоритм умещается в три вопроса, задаваемых по порядку.

Вопрос первый: это нужно в каждой сессии? Если да — CLAUDE.md, и дальше можно не идти. Команда сборки, отступ в два пробела, требование запускать тесты перед коммитом.

Вопрос второй: это касается только части кодовой базы? Если да — правило с paths. Требования к обработчикам API, соглашения об именовании миграций, специфика тестов.

Вопрос третий: это справочник или многошаговая процедура? Если да — скилл. Полное описание API стороннего сервиса, чек-лист релиза, руководство по стилю на несколько экранов.

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

Auto memory в этот алгоритм не входит намеренно: туда вы ничего не кладёте сами. Механизм наполняется Claude из ваших поправок, и ваше участие сводится к периодической ревизии.

Триггеры: когда что заводить

Настраивать всё заранее не нужно. У каждого механизма есть узнаваемый повод, и большинство команд приходят к ним примерно в таком порядке:

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

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

Отдельный триггер на перенос — рост CLAUDE.md. Правило простое: держите файл до 200 строк, а если он растёт, выносите справочные материалы в скиллы или разбивайте на файлы в .claude/rules/.

Чего не гарантирует ни один из них

Здесь важная оговорка, которая иначе всплывёт болезненно.

Все три механизма — контекст, а не принудительная конфигурация. Claude их читает и старается следовать, но строгого исполнения не гарантирует, особенно при расплывчатых или противоречивых формулировках. Инструкция «никогда не редактируй .env» — это просьба, а не запрет.

Отсюда практический вывод: чем конкретнее и короче инструкция, тем последовательнее ей следуют. И второй, важнее: если что-то обязано выполняться всегда и без исключений, ему не место среди инструкций вовсе. Для таких случаев в Claude Code есть механизм, который срабатывает детерминированно, независимо от решений модели. Его мы разберём в восьмой главе.

Пока держите в голове границу: инструкции направляют поведение, но не запрещают действия.

Частые ошибки

• Прятать за paths то, что нужно всегда. Команда сборки в правиле с привязкой к путям выглядит аккуратно, но если правило не сработает, агент останется без неё. При сомнениях делайте инструкцию безусловной.
• Складывать справочники в CLAUDE.md. Полная документация API или руководство по стилю на несколько страниц вытесняют из внимания короткие важные правила. Такому материалу место в скилле, который загружается по требованию.
• Противоречия между уровнями. Пользовательский файл говорит одно, проектный другое, правило третье — агент выберет произвольно. Периодически сверяйте уровни и вычищайте устаревшее.
• Настраивать всё заранее. Продуманная система из десятка правил и скиллов, написанная до появления реальных поводов, обычно не совпадает с тем, что нужно на практике. Заводите механизмы по триггерам.

Наиболее частые вопросы

• Куда девать инструкцию, подходящую под два механизма сразу? — Выбирайте тот, что загружается позже: сначала пробуйте правило или скилл, и только если инструкция нужна в каждой сессии — CLAUDE.md.
• Сколько правил и скиллов считается нормой? — Столько, сколько у вас реальных поводов. Один файл на тему, без дробления ради структуры и без объединения разнородного.
• Что произойдёт, если инструкция окажется в двух местах? — Дублирование расходует контекст и создаёт риск расхождения при правке одной из копий. Держите каждую договорённость в одном месте.
• Правило без paths — то же самое, что CLAUDE.md? — По моменту загрузки практически да: оно грузится при старте с приоритетом уровня .claude/CLAUDE.md. Различие в организации: правила разложены по темам.
• Можно ли положить в скилл то, что нужно постоянно? — Технически да, но смысла мало: скилл загрузится не гарантированно, а по решению Claude или по вашему вызову. Постоянно нужное — в CLAUDE.md.

Итоги

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

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