Cursor rules — это текстовые инструкции, которые Cursor подмешивает в контекст агента: проектные правила лежат в папке .cursor/rules файлами .mdc и путешествуют вместе с репозиторием. В заголовке файла указаны описание, маски файлов и флаг постоянного применения, поэтому правило про тесты включается при работе с тестами, а договорённость про язык ответов может действовать всегда. Подход окупается там, где командные соглашения уже существуют и поддаются записи в виде коротких проверяемых фраз.
Где лежат правила
Проектные правила Cursor — файлы .mdc в папке .cursor/rules, их хранит Git. Личные настройки живут в разделе Rules настроек Cursor, командные правила выдаёт администратор через панель управления.
Условный пример: репозиторий внутреннего портала с отдельными папками для миграций базы и для тестов. Разработчик просит агента добавить поле в таблицу, и без правил миграция выходит в произвольном стиле, а откат забыт. С файлом .cursor/rules/migrations.mdc Cursor добавляет в запрос договорённость: у каждой миграции есть откат, имена файлов следуют принятой схеме. Правило остаётся обычным текстом в репозитории, поэтому проходит ревью, как код, и доезжает до каждого, кто клонирует проект.
Документация Cursor называет три источника правил: проектные, пользовательские и командные (тарифы Team и Enterprise). Отдельно Cursor читает файл AGENTS.md — простой markdown с инструкциями без служебных полей; вложенные файлы из подпапок объединяются с родительскими, и более конкретные указания побеждают. Режим работы самого агента разобран в статье про Cursor Agent, а формат пакетов процедур у другого инструмента — в материале про Codex skills. Здесь разговор только о том, что агент Cursor читает до начала работы.
Создать правило можно командой /create-rule в чате или через раздел Customize, затем Rules и кнопку Add Rule. Черновик от Cursor полезен как заготовка, но дальнейшая работа ручная: отредактируйте формулировки, проверьте маску и закоммитьте файл отдельным коммитом, чтобы изменение было видно в истории. Так правило получает автора и дату, а команде есть к кому идти с вопросами.
Четыре режима применения
Каждое правило Cursor относится к одному из четырёх режимов. Режим определяют поля заголовка файла: alwaysApply, description и globs. Документация уточняет, что при alwaysApply: true описание и маски файлов игнорируются, поэтому смешивать флаг с масками бессмысленно.
| Режим | Как срабатывает | Для чего годится |
|---|---|---|
| Always Apply | Включается в каждый чат автоматически | Короткие договорённости на весь проект: язык ответов, формат сообщений коммита |
| Apply Intelligently | Агент читает поле description и решает сам | Случаи, которые маской файлов описать трудно: например, правила работы с внешним API |
| Apply to Specific Files | Срабатывает, когда в контексте появляются файлы под маску из поля globs, например src/**/*.tsx | Правила для папки или типа файлов: миграции, тесты, компоненты |
| Apply Manually | Подключается упоминанием @имя-правила в чате | Редкие процедуры, нужные по запросу: подготовка релиза |
Практическое правило выбора: чем уже область применения, тем реже правило мешает посторонним задачам. Постоянно включённый файл попадает в контекст каждого запроса и занимает в нём место, поэтому режим Always Apply оставьте для двух-трёх коротких фраз. Всё, что относится к конкретной папке, переводите на маски. Всё, что нужно раз в месяц, делайте ручным.
Для режима Apply Intelligently решающую роль играет поле description: агент выбирает правило, читая одну эту строку. Описание вида «правила» остаётся пустым звуком, а описание «как оформлять и откатывать миграции базы данных» даёт ему повод подключить файл именно в нужный момент. Проверяйте формулировку, как заголовок статьи: по ней должно быть понятно, о чём файл, без открытия.
Что писать внутрь
Хорошее правило похоже на строку чек-листа ревьюера: его можно проверить глазами по diff. Фраза «пишите аккуратный код» остаётся для агента пустой, а формулировка «каждая миграция в папке migrations содержит функцию отката» проверяется чтением diff.
- Команда проверки: каким запросом в терминале запускают тесты и линтер, и что считать успехом.
- Запрет с причиной: файлы в папке generated правит только генератор, поэтому ручные правки пропадут при следующей сборке.
- Ссылка на эталон: путь к образцовому модулю вместо копии его кода. Документация советует ссылаться на файлы, а общие руководства по стилю и описание привычных инструментов в правило переносить незачем.
- Граница автономности: изменение схемы базы агент согласует с человеком до правки.
Размер тоже часть качества: по рекомендации документации, правило держат короче пятисот строк и сосредоточенным на одной теме. Если файл разросся, разделите его на два с разными масками. Один файл с описанием «всё про проект» агенту подсказывает мало, а три файла с точными названиями выбираются осмысленно.
Заголовок файла migrations.mdc из примера выше выглядит так: в description записано, как оформлять и откатывать миграции, в globs стоит маска migrations/**, флаг alwaysApply выключен. Тело состоит из четырёх-пяти коротких строк по принципам списка. Сверьте этот набор с замечаниями из последних ревью: если какое-то из них повторялось, оно и просится в текст правила.
Какое повторяющееся замечание из ревью кода вы записали бы первым?
Конфликты правил
Когда правила спорят, действует порядок из справки Cursor: командные правила сильнее проектных, проектные сильнее пользовательских. Все подходящие правила объединяются в один набор, и приоритет решает только то место, где формулировки противоречат друг другу. Личная привычка разработчика вроде «отвечай кратко» уступит договорённости проекта, а требование администратора победит оба.
Конфликт внутри одного проекта разрешается человеком. Правила можно раскладывать по вложенным папкам внутри .cursor/rules, но чем больше файлов, тем легче пропустить два правила об одном и том же. Поэтому назначьте каждой теме единственный файл и владельца, который принимает изменения.
- Найдите два правила, дающих разные указания для одной и той же папки.
- Оставьте формулировку, которая подтверждена ревью или документом команды.
- Удалите вторую либо сузьте её маску до другой области.
- Запишите изменение в сообщении коммита, чтобы история объяснила причину.
Проверка на задаче
Правило считается рабочим только после прогона на типовой задаче. Текст в файле лежит независимо от того, подключил его Cursor или нет, а ошибка в маске или режиме обнаруживается лишь поведением агента. Для проверки нужен новый чат без истории, чтобы прошлые подсказки остались за бортом и файл работал в одиночку.
- Выберите задачу, где правило обязано сработать: например, добавление миграции для нового поля.
- Откройте чистый чат Cursor и сформулируйте задачу без напоминаний о правиле.
- Сверьте diff с формулировкой: откат на месте, имя файла по схеме, тесты запущены командой из правила.
- Повторите запрос на задаче вне маски файлов, например правке текста в README: правило должно молчать.
- Попросите агента нарушить правило. Хороший исход — отказ со ссылкой на договорённость или вопрос человеку.
Провал первого шага отправляет к режиму и маске, а лишнее срабатывание на четвёртом шаге выдаёт слишком широкую маску. Записывайте результат прогона рядом с файлом правила, чтобы следующий редактор видел, на чём правило проверено. Прогон повторяют после каждой правки файла и при смене модели в настройках Cursor: поведение агента зависит от обеих частей. Результаты сохраняйте таблицей из трёх колонок: задача, ожидаемое поведение, фактический diff. Командные ресурсы по обучению сотрудников работе с агентами в разработке собраны на странице об обучении сотрудников работе с ИИ.
Возьмите одно замечание, которое ревьюеры повторяют чаще остальных, и запишите его одним файлом с маской на нужную папку. Прогоните пять шагов выше, покажите команде diff и только после этого пишите второе правило. Нужна помощь с внедрением агентов в процесс разработки? Посмотрите, как мы подходим к внедрению ИИ в команде.