Модульные правила
Инструкции для путей
Как работают модульные правила в Claude Code
Модульные правила (modular rules) — это способ разбить инструкции для Claude Code на небольшие тематические файлы вместо одного огромного CLAUDE.md. Каждый файл живёт в директории .claude/rules/ и отвечает за свою область: один — за TypeScript, другой — за React-компоненты, третий — за маршруты API. Идея простая: правило должно подгружаться только тогда, когда оно действительно нужно, а не висеть в контексте при каждом запросе. Блок со структурой папки ниже как раз показывает типичную раскладку — отдельный .md на каждый тип файлов.
Главный механизм — сопоставление путей (path matching). В начале каждого файла стоит блок YAML frontmatter с ключом paths, где перечислены glob-шаблоны. Когда Claude читает, редактирует или создаёт файл, он смотрит, какие правила совпадают с путём этого файла, и подмешивает их инструкции в контекст. Шаблон **/*.ts в примерах на этой странице означает «любой .ts-файл на любой глубине вложенности», а строка с восклицательным знаком — !**/*.test.ts — это исключение: правило применится ко всем TypeScript-файлам, кроме тестов. Так инструкции для боевого кода не протекают в тестовый и наоборот.
Когда и зачем это использовать
Модульные правила стоит вводить, когда проект разросся и единый файл с памятью стал противоречивым: правила для бэкенда мешают фронтенду, а половина строк неактуальна для текущего файла. Конкретный пример: фронтенд-правило требует «только функциональные компоненты», а API-правило — «валидируй тело запроса через Zod». Если держать оба в одном CLAUDE.md, Claude тратит контекст на нерелевантные указания и иногда применяет их не туда. Разнеся их по react.md и api.md с точными paths, вы получаете точечную доставку инструкций. Главные подводные камни: слишком широкие шаблоны (правило цепляет лишние файлы), забытые исключения для сгенерированного кода и описание «что делать» без объяснения «почему» — без причины модель легче нарушит правило. Храните файлы правил в git вместе с проектом, чтобы они были общими для всей команды.
Модульные правила — это отдельные .md файлы в директории .claude/rules/, которые применяются только к определённым файлам.
.claude/rules/ ├── typescript.md # Rules for *.ts, *.tsx ├── react.md # Rules for components ├── api.md # Rules for API routes ├── tests.md # Rules for tests ├── security.md # Security guidelines └── database.md # Database conventions
💡 Правила автоматически подгружаются когда Claude работает с файлами, соответствующими паттернам.
Каждое правило — это Markdown файл с YAML frontmatter, содержащим paths:
--- paths: - "**/*.ts" - "**/*.tsx" - "!**/*.test.ts" --- # TypeScript Rules Your instructions here...
Включающие паттерны
**/*.ts— все TS файлыsrc/components/**— все в components*.config.js— конфиги в корне
Исключающие паттерны
!**/*.test.ts— кроме тестов!**/node_modules/**— кроме modules!dist/**— кроме dist
typescript.md**/*.ts**/*.tsx
--- paths: - "**/*.ts" - "**/*.tsx" --- # TypeScript Rules - Use strict TypeScript settings - Prefer interfaces over types for objects - Always add return types to functions - Use 'unknown' instead of 'any'
react.mdsrc/components/**/*.tsx
---
paths:
- "src/components/**/*.tsx"
---
# React Component Rules
- Use functional components only
- Props interface should be named {ComponentName}Props
- Use memo() for expensive renders
- Prefer composition over prop drillingapi.mdsrc/app/api/**/*.ts
--- paths: - "src/app/api/**/*.ts" --- # API Route Rules - Always validate request body with Zod - Return proper HTTP status codes - Handle errors with try/catch - Log all errors to monitoring
tests.md**/*.test.ts**/*.spec.ts
--- paths: - "**/*.test.ts" - "**/*.spec.ts" --- # Testing Rules - Use describe/it blocks - Mock external dependencies - Test edge cases - Aim for 80% coverage
Лучшие практики
- 1.Создавайте отдельные правила для разных типов файлов
- 2.Используйте исключения (!) для тестов и сгенерированных файлов
- 3.Документируйте "почему", а не только "что"
- 4.Коммитьте правила в git вместе с проектом
Частые вопросы
Что такое модульные правила (modular rules) в Claude Code?
Модульные правила — это отдельные Markdown-файлы в директории .claude/rules/, каждый из которых отвечает за свою область (TypeScript, React-компоненты, маршруты API). Вместо одного большого CLAUDE.md инструкции разбиваются на тематические файлы и подгружаются только тогда, когда Claude работает с подходящими файлами.
Где хранятся правила Claude Code и как задать, к каким файлам они применяются?
Правила лежат в папке .claude/rules/ в корне проекта. В начале каждого файла стоит YAML frontmatter с ключом paths, где перечислены glob-шаблоны (например, **/*.ts). Claude сопоставляет путь редактируемого файла с этими шаблонами и подмешивает в контекст только совпавшие правила.
Как исключить тесты или сгенерированные файлы из правила Claude Code?
В списке paths добавьте строку с восклицательным знаком — это исключение. Например, !**/*.test.ts применит правило ко всем TypeScript-файлам, кроме тестов, а !**/node_modules/** и !dist/** исключат зависимости и сборку. Так инструкции для боевого кода не протекают в тестовый.
Чем модульные правила лучше одного файла CLAUDE.md?
Когда проект разрастается, единый CLAUDE.md становится противоречивым: правила для бэкенда мешают фронтенду, а половина строк неактуальна для текущего файла. Разнеся инструкции по react.md, api.md и другим файлам с точными paths, вы получаете точечную доставку: Claude видит только релевантные правила и не тратит контекст на лишнее.
Этот урок — часть структурированного курса по LLM.
Мой путь обучения