Cursor rules — как писать правила .cursor/rules, frontmatter, globs, чтобы срабатывали

Правила Cursor (Rules) — это постоянные инструкции для ИИ-агента: стиль кода, архитектура, соглашения по проекту. Без них модель не знает ваших конвенций и может предлагать лишнее или не в том формате. В Cursor правила живут в .cursor/rules/ в виде файлов .mdc (или .md) с frontmatter: без него правила часто не подхватываются или срабатывают непредсказуемо. В статье разберём, как писать правила Cursor, чтобы они реально срабатывали: обязательный frontmatter, globs и alwaysApply, принцип «один файл — одна зона», конкретные формулировки и блок «что не делать», как проверять чужие правила перед копированием (по материалам DEV Community и Cursor Docs) и зачем версионировать правила в git. Базовое введение в правила проекта — в статье Cursor: примеры настроек, чистка Markdown и полезные приёмы.

Содержание

• Зачем нужны правила и почему старый .cursorrules уходит
• .cursor/rules и формат .mdc: frontmatter обязателен
• Один файл — одна зона ответственности, до ~2000 символов
• Конкретные формулировки и блок «что не делать»
• Как проверять чужие правила перед копированием (чеклист)
• Версионирование правил в git и работа в команде
• Связь с чистым кодом и курсами
• Выводы

Зачем нужны правила и почему старый .cursorrules уходит

Правила дают агенту Cursor (чат, Composer) постоянный контекст: язык ответов, отступы, именование, архитектурные решения. Без правил каждый запрос начинается «с нуля», и модель угадывает стиль по открытым файлам — часто ошибается или переусложняет. С явными правилами агент стабильнее следует вашим конвенциям.

Раньше достаточно было одного файла .cursorrules в корне проекта. Сейчас Cursor переходит на папку .cursor/rules/ и файлы с расширением .mdc (Markdown с frontmatter). В документации Cursor явно сказано: «The .cursorrules file in your project root is legacy and will be deprecated». Миграция проста: скопировать содержимое .cursorrules в новый файл в .cursor/rules/, задать тип «Always Apply» и при необходимости разбить на несколько файлов по темам. Структура «один корневой файл» и «папка с правилами»:

.cursor/rules и формат .mdc: frontmatter обязателен

Файлы правил лежат в .cursor/rules/ в корне проекта. Поддерживаются расширения .md и .mdc. Для управления тем, когда правило применяется, нужен YAML frontmatter в начале файла — блок между ---. Без frontmatter Cursor не понимает, к каким файлам или сессиям правило относится, и оно может загружаться случайно или не загружаться вообще. Подробнее о лучших практиках можно прочитать в гайдах на Cursor Docs и dotcursorrules.com.

По исследованию на DEV Community: при проверке четырёх популярных наборов правил из сообщества 100% не имели frontmatter — это была главная причина, почему правила «не работали из коробки».

Минимально нужны:

• description — краткое описание правила; используется для типа «Apply Intelligently», чтобы агент решал, релевантно ли правило текущему контексту.
• alwaysApply или globs — когда применять: всегда (alwaysApply: true) или только для файлов, подходящих под шаблон (например, globs: ["**/*.tsx"]).

Пример корректного frontmatter:

---
description: Правила именования и стиля для React-компонентов
globs: ["src/**/*.tsx", "src/**/*.ts"]
alwaysApply: false
---

Анатомия frontmatter и типов правил:

Один файл — одна зона ответственности, до ~2000 символов

Когда в одном файле смешаны именование, обработка ошибок, структура папок и стилизация, агенту сложно применять правило точечно, а контекстное окно забивается лишним. Рекомендация из Cursor Docs и DEV: один файл — одна тема (naming, errors, structure, markdown и т.д.) и объём тела правила до ~2000 символов (порядка 500 токенов). Правила с alwaysApply: true подгружаются в каждый запрос; длинное правило съедает токены, которые могли бы идти на код.

В том же исследовании: из четырёх популярных наборов 75% были длиннее 2000 символов, а один — почти 4000 символов (~1100 токенов на каждый запрос). Итог: разбивать большие правила на несколько .mdc с разными globs. Пример структуры:

Не смешивайте в одном файле «PascalCase для компонентов», «оборачивай роуты в error boundary» и «храни стили в CSS modules» — это три отдельные зоны. Как разделять:

Конкретные формулировки и блок «что не делать»

Размытые формулировки вроде «старайся писать чистый код» или «следуй best practices» модель почти не использует для изменения поведения. Имеет смысл писать императивно и конкретно: «Функции не длиннее 20 строк», «Именование: camelCase для переменных, PascalCase для компонентов», «Все роут-хендлеры оборачивать в try/catch». В Cursor Docs прямо сказано: избегайте размытых указаний, пишите правила как чёткую внутреннюю документацию.

Очень полезный приём — блок «Что не делать» (What NOT to do). На Reddit и в статьях (например, dotcursorrules.com) подчёркивают: явный запрет лишних абстракций, лишних зависимостей и переусложнения часто даёт больший эффект, чем длинный список «делай так». Пример для React/Next:

## Что не делать
- Не добавлять useMemo/useCallback без измеренного узкого места.
- Не создавать папки/сервисы «на будущее» — только под текущую задачу.
- Не обрабатывать ошибки «в общем» — конкретный тип и сообщение.

Такие правила хорошо сочетаются с темами чистого кода и архитектуры, которым посвящены курсы вроде ООП на Python, ООП в PHP, ООП на JavaScript и Архитектура фронтенда: понимание принципов помогает формулировать правила осознанно.

Пример полного правила с frontmatter и блоком «что не делать»

Файл .cursor/rules/react-components.mdc для React/TypeScript:

---
description: Стиль React-компонентов и именование, только .tsx
globs: ["src/**/*.tsx"]
alwaysApply: false
---

# React-компоненты

- Компоненты — функциональные, с хуками. Классовые компоненты не использовать.
- Именование: PascalCase для компонентов, camelCase для пропсов и переменных.
- Функции внутри компонента не длиннее 15 строк; при необходимости выносить в отдельные функции или хуки.
- Экспорт компонента — именованный (export function ComponentName), не default.

## Что не делать
- Не добавлять useMemo/useCallback без явной необходимости (измеренная проблема производительности).
- Не создавать лишние обёртки и HOC «на будущее».
- Не смешивать логику запросов и разметку в одном компоненте — выносить данные в хук или родителя.

Такой файл короткий, с чётким frontmatter и globs, одна тема (компоненты и именование), и блок «что не делать» ограничивает переусложнение. Для углубления в компонентный подход и тесты пригодятся курс React и автотесты фронтенда.

Как проверять чужие правила перед копированием (чеклист)

Правила из репозиториев вроде awesome-cursorrules или из статей часто выглядят удобно, но при проверке оказывается, что они не загружаются или работают плохо. По материалу на DEV Community можно использовать пятипунктный чеклист перед тем как копировать правило в проект:

1. Есть ли YAML frontmatter? Должны быть description и либо alwaysApply, либо globs. Без этого правило может не подхватиться.
2. Длина тела до ~2000 символов? Если больше — разбить или сократить, иначе тратится контекст.
3. Одна зона ответственности? Если в файле и именование, и ошибки, и структура — разделить на несколько файлов.
4. Формулировки конкретные и императивные? Заменить «старайся», «consider», «best practices» на явные команды.
5. Нет ли конфликта с уже существующими правилами? Например, «ставь точку с запятой» в одном файле и «без точки с запятой» в другом — агент будет вести себя непредсказуемо.

Автоматическая проверка: можно сохранить скачанное правило в .cursor/rules/test-rule.mdc и запустить линтер (например, cursor-doctor): npx cursor-doctor lint. Он проверяет frontmatter, длину, размытый язык и конфликты.

Когда правило лучше не исправлять, а отложить: если это просто список технологий без инструкций («Next.js 15, React 19, TypeScript»), или синтаксис не Markdown, или больше половины файла — примеры и «You are an expert…», или объём больше 5000 символов. В таких случаях часто проще написать своё короткое правило с нуля, опираясь на курсы по стеку (например, React, Django, Laravel).

Визуально чеклист:

Версионирование правил в git и работа в команде

Правила в .cursor/rules/ лежат в репозитории и версионируются вместе с кодом. В документации Cursor это указано явно: «Check rules into git so your whole team benefits». Тогда у всех один и тот же контекст для агента: стиль, соглашения и ограничения не зависят от машины или настроек пользователя. Онбординг упрощается — новый разработчик клонирует репо и получает те же правила. Для командной работы полезно завести в репо хотя бы общий файл (например, general.mdc) и при необходимости правила по языкам или типам файлов (например, для тестов — курс по тестированию на Jest или Pytest); так конвенции по коду и тестам будут едиными.

Приоритет правил (если используются Team Rules): Team Rules → Project Rules → User Rules. Project rules в .cursor/rules/ переопределяют пользовательские, но уступают правилам команды из дашборда Cursor.

Связь с чистым кодом и курсами

Умение формулировать правила для ИИ опирается на понимание стиля кода, архитектуры и тестирования. Курсы Хекслета по разным языкам и слоям стека помогают заложить базу:

• Чистый код и архитектура: ООП на Python, ООП в PHP, ООП на JavaScript, ООП в Java, Архитектура фронтенда — именование, слои, границы модулей.
• Структура и алгоритмы: Алгоритмы и структуры данных — помогает задавать правила про сложность и структуры в коде.
• Тестирование: Jest, Pytest — правила вида «все новые функции покрыты тестами» или «используй такие-то паттерны тестов».
• Фреймворки: React, Django, Laravel — правила под конкретный стек и конвенции фреймворка.

Чем яснее у вас собственные стандарты (благодаря курсам и практике), тем точнее вы опишете их в .cursor/rules/ и тем стабильнее будет вести себя агент.

Выводы

• Правила Cursor переносятся с .cursorrules на .cursor/rules/ и файлы .mdc; без frontmatter (description, alwaysApply или globs) правила часто не срабатывают или работают непредсказуемо.
• Один файл — одна зона, тело до ~2000 символов; длинные правила разбивать на несколько файлов с разными globs.
• Формулировки конкретные и императивные; блок «Что не делать» сильно снижает переусложнение кода агентом.
• Перед копированием чужих правил проверять: frontmatter, длину, одну тему, конкретику, отсутствие конфликтов; при возможности использовать линтер (например, npx cursor-doctor lint).
• Правила в git — единый контекст для команды; приоритет: Team Rules → Project Rules → User Rules.

Базовые примеры правил и настройки Cursor — в статье Cursor: примеры настроек, чистка Markdown и полезные приёмы. Чтобы углубить тему чистого кода и архитектуры для формулировки правил, можно пройти курсы по ООП и архитектуре фронтенда на Хекслете.