Коротко: правила Cursor (Cursor Rules) — постоянные инструкции для агента, которые Cursor добавляет в начало контекста, чтобы не повторять их в каждом промте. Правила проекта лежат в .cursor/rules в виде файлов .mdc. Когда правило подключается, решают три поля в его заголовке: alwaysApply, globs и description. Варианты такие: всегда, для файлов по маске, по решению агента или вручную через @. Кроме правил проекта есть пользовательские (для всех ваших проектов), командные (Team Rules) и простой AGENTS.md.
Все факты — из документации Cursor о правилах (проверено 03.11.2026). Что писать в AGENTS.md и как он работает в разных агентах, разобрано на отдельной странице AGENTS.md. Здесь — механика правил именно в Cursor.
Четыре вида правил#
| Вид | Где | Для чего |
|---|---|---|
| Project Rules | .cursor/rules/*.mdc, в git | правила этого проекта: стек, структура, соглашения |
| User Rules | Customize → Rules | ваши предпочтения во всех проектах, например стиль ответов |
| Team Rules | панель команды (Team, Enterprise) | общие стандарты для всей команды |
| AGENTS.md | корень и подпапки проекта | простые инструкции без настроек, понятные и другим агентам |
Если правила противоречат друг другу, приоритет такой: Team Rules → Project Rules → User Rules. Применимые правила объединяются, но при конфликте выигрывает более ранний источник.
Как устроен файл правила#
Каждое правило — файл .mdc с любым именем. Сверху заголовок (frontmatter), ниже текст правила:
---
description: Соглашения для API-эндпоинтов
globs: src/api/**/*.ts
alwaysApply: false
---
- Каждый эндпоинт в отдельном файле в src/api/.
- Входные данные проверяй на границе, до передачи во внутренние функции.
- Ошибки возвращай объектом { code, message }.
Важно: расширение именно .mdc. Обычный .md в папке .cursor/rules Cursor не считает правилом — у такого файла нет заголовка с настройками. Правила можно раскладывать по подпапкам, например .cursor/rules/frontend/components.mdc.
Когда правило подключается: alwaysApply, globs, description#
| Тип в интерфейсе | alwaysApply | globs | description | Когда работает |
|---|---|---|---|---|
| Always Apply | true | — | — | в каждом чате |
| Apply to Specific Files | false | задан | — | когда в контексте файл по маске |
| Apply Intelligently | false | нет | задан | агент читает описание и решает сам |
| Apply Manually | false | нет | нет | только когда упомянули @имя-правила |
Из этого следуют две частые ошибки. Первая: у правила «по решению агента» пустое description, и агенту не по чему решать. Вторая: globs не совпадает с реальными путями.
Маски globs
| Маска | Что подходит |
|---|---|
*.ts | .ts в корне |
**/*.ts | .ts в любой папке |
src/** | всё внутри src/ |
src/**/*.tsx | .tsx в любом месте внутри src/ |
docs/**/*.md, docs/**/*.mdx | несколько масок через запятую |
Примеры правил#
Общие правила проекта (всегда):
---
alwaysApply: true
---
- Стек: Next.js, TypeScript, без новых зависимостей без объяснения.
- Не трогай файлы, о которых тебя не просили.
- Секреты и ключи — только в переменных окружения.
- Перед словом «готово» запусти npm run build и npm test.
- В конце перечисли изменённые файлы.
Для компонентов (по маске):
---
globs: src/components/**/*.tsx
alwaysApply: false
---
- Именованные экспорты, без default.
- Стили — CSS-модуль рядом с компонентом.
- Компонент длиннее 200 строк дели на подкомпоненты в той же папке.
- Образец: @src/components/Button.tsx
Миграции базы (вручную, через @):
---
alwaysApply: false
---
- У каждой миграции есть up и down.
- Тип колонки не меняй на месте: новая колонка → перенос данных → удаление старой.
- Структура файла — как в @migration-template.sql
Упоминание файла через @ в правиле не вставляет его содержимое: агент сам прочитает файл, когда он понадобится. Если что-то должно быть в контексте всегда, пишите это прямо в правило.
Правила под 1С. Тот же формат работает для проектов на 1С, выгруженных в файлы: маска globs: **/*.bsl, в тексте — версия платформы, «работаем в расширении, типовые объекты не меняем», ссылка на образцовый модуль. Подробнее о работе ИИ с 1С — в задаче ИИ и 1С.
Как создать правило#
- Из чата: наберите
/create-ruleи опишите правило. Агент создаст файл с правильным заголовком в.cursor/rules. - Из настроек: Customize → Rules → Add Rule. Там же видно все правила и их статус.
Как писать хорошие правила#
По рекомендациям документации:
- Коротко и по делу. Одно правило — до 500 строк; большое делите на несколько.
- Конкретно. Пишите, как внутреннюю документацию: что делать, с примером или ссылкой на файл-образец.
- Ссылайтесь, а не копируйте. Код-образец — ссылкой
@файл, иначе правило устареет вместе с кодом. - Не дублируйте линтер. Стиль-гайд целиком не нужен: агент знает общие соглашения, а форматирование лучше проверять линтером.
- Не перечисляйте очевидные команды. npm, git, pytest агент знает.
- Начинайте с малого. Добавляйте правило, когда агент повторяет одну и ту же ошибку.
- Держите в git. Увидели ошибку агента — обновите правило.
Правила, промты и AGENTS.md: что куда#
| Что | Куда |
|---|---|
| Задача на сейчас | промт (как писать промты для Cursor) |
| Общие инструкции проекта, нужные и другим агентам | AGENTS.md |
| Правила для отдельных типов файлов или вызываемые вручную | .cursor/rules/*.mdc |
| Ваши личные предпочтения во всех проектах | User Rules |
Составить первый вариант правил по существующему проекту поможет промт создать AGENTS.md. Ещё быстрее — генератор, который собирает правила по полям.