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

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

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

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

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

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

• Как устроен каталог .claude/rules/ и как раскладывать по нему правила
• Как работает поле paths во frontmatter и когда правило попадает в контекст
• Какие glob-шаблоны применимы и как сопоставлять несколько расширений
• Чем правила отличаются от вложенных CLAUDE.md и когда что выбирать
• Как разделять правила уровня проекта и уровня пользователя

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

• Правило — markdown-файл в .claude/rules/, содержащий инструкции по одной теме.
• Frontmatter — блок YAML в начале файла, отделённый строками из трёх дефисов.
• paths — поле frontmatter со списком glob-шаблонов; правило загружается только при работе с подходящими файлами.
• Glob-шаблон — образец пути с подстановочными знаками: * внутри одного сегмента, ** — на любую глубину.
• Brace expansion — запись вида {ts,tsx}, разворачивающаяся в несколько шаблонов.
• Безусловное правило — файл без поля paths; загружается при старте наравне с .claude/CLAUDE.md.

Как устроен каталог правил

Правила — это обычные markdown-файлы в .claude/rules/ проекта. Одна тема — один файл с говорящим именем. Файлы находятся рекурсивно, поэтому вложенные каталоги допустимы.

your-project/
├── .claude/
│   ├── CLAUDE.md           # основные инструкции проекта
│   └── rules/
│       ├── code-style.md   # правила стиля
│       ├── testing.md      # соглашения о тестах
│       └── security.md     # требования безопасности

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

Отсюда простое решение: если инструкция нужна всегда — обходитесь без paths; если только для части кодовой базы — привязывайте.

Привязка к путям через frontmatter

Синтаксис минимален: блок YAML в начале файла, в нём поле paths со списком шаблонов.

---
paths:
  - "src/api/**/*.ts"
---

# Правила разработки API

- Все эндпоинты обязаны валидировать входные данные
- Использовать стандартный формат ответа при ошибке
- Добавлять комментарии для документации OpenAPI

Такое правило молчит, пока вы работаете со стилями или конфигурацией, и появляется в контексте ровно тогда, когда агент открывает файл под src/api/.

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

Шаблонов можно указать несколько, а расширения — свернуть в фигурные скобки:

---
paths:
  - "src/**/*.{ts,tsx}"
  - "lib/**/*.ts"
  - "tests/**/*.test.ts"
---

Соответствие шаблонов и того, что они покрывают:

• */*.ts — все файлы TypeScript в любом каталоге
• src/**/* — всё, что лежит под src/
• .md — markdown-файлы в корне проекта
• src/components/*.tsx — компоненты в конкретном каталоге

Пара ограничений, о которых полезно знать заранее. Фигурные скобки перемножаются: src/*.{ts,tsx} разворачивается в два шаблона, а {a,b}/{c,d}/*.{ts,tsx} — уже в восемь. Весь список paths одного правила делит общий бюджет в 1000 развёрнутых шаблонов; шаблоны без скобок в бюджет не входят. И ещё: символ [ трактуется как начало символьного класса, поэтому имя вида photos [2024/** невалидно — literal-скобку экранируют обратным слешем.

Правила проекта и правила пользователя

Уровней два, и у них разное назначение.

Проектные правила лежат в .claude/rules/ репозитория, коммитятся и действуют для всей команды. Личные — в ~/.claude/rules/ и применяются во всех ваших проектах на этой машине.

~/.claude/rules/
├── preferences.md    # личные предпочтения по коду
└── workflows.md      # привычные рабочие сценарии

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

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

ln -s ~/shared-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.md

Симлинки разрешаются и загружаются как обычные файлы, а циклические ссылки обрабатываются корректно.

Правила или вложенный CLAUDE.md

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

Вложенный CLAUDE.md привязан к каталогу, где лежит. Он удобен, когда граница совпадает с границей подпроекта: frontend/CLAUDE.md, backend/CLAUDE.md в монорепозитории.

Правило с paths привязано к шаблону и границами каталогов не ограничено. Оно годится, когда критерий — тип файла, а не место: правила для всех тестов, где бы они ни лежали; требования ко всем миграциям; соглашения по TypeScript во всём проекте.

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

Отсюда практическая рекомендация: границы подпроектов — вложенные CLAUDE.md, тематические и типовые правила — .claude/rules/.

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

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

• Привязка к путям того, что нужно всегда. Команды сборки или общий стиль кода за paths прятать нельзя: если правило не сработает, агент будет действовать без него. В сомнительных случаях оставляйте правило безусловным.
• Слишком узкий шаблон. src/api/*.ts не покрывает вложенные каталоги — файл src/api/users/handler.ts под него не подпадёт, и правило промолчит. Для рекурсии нужен *.
• Ожидание срабатывания на каждое действие. Правило подключается, когда агент читает подходящий файл. Если он до него не добрался, правила в контексте нет — и после /compact оно вернётся только при новом обращении.
• Перенос в правила всей документации. Каталог правил задуман для инструкций, а не для справочников. Раздутое правило ведёт себя ровно так же, как раздутый CLAUDE.md, просто загружается реже.

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

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

Итоги

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

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