Cursor пишет код в чужом стиле, тащит библиотеку, которую вы выпилили полгода назад, и каждый раз заново придумывает, как у вас называются колонки в базе. Дело не в модели. Вы посадили нового сотрудника за проект и не провели онбординг.
Живой человек хотя бы спросит, где лежит auth-хелпер. AI-редактор не спрашивает — он угадывает. И чем больше угадывает, тем больше времени вы тратите на правки вместо результата.
Cursor Rules — это и есть онбординг для редактора. Файлы, где записано: вот стек, вот конвенции, вот то, что уже готово в репозитории, сюда не лезь. Дальше — где эти правила лежат, в каком формате их писать и как не превратить их в налог на токены.
Что такое Cursor Rules и где они лежат
Раньше всё держалось в одном файле .cursorrules в корне репозитория — простой текст или Markdown. Сейчас Cursor перешёл на модульную систему Project Rules: каталог .cursor/rules/ с отдельными файлами под расширением .mdc. Старый файл всё ещё работает, но новые проекты лучше строить на модульной схеме.
Важно понимать, откуда именно Cursor читает правила. Валидных места всего три, всё остальное он просто не видит.
~/.cursor/rules/*.mdc— глобальные правила (User / Global Rules). Действуют во всех проектах: ваш личный тон, общие предпочтения..cursor/rules/*.mdc— правила проекта, модульно. Рекомендуемый способ: лежат в репозитории, едут с командой через git..cursorrules— старый одиночный файл в корне проекта. Ещё поддерживается, но не рекомендуется.
Когда правила пересекаются, приоритет такой: Team Rules важнее Project Rules, Project Rules важнее User Rules. То есть командные настройки перебьют ваши личные, а правила репозитория — глобальные.
Файл в README, в cursor.config.js или с расширением .md вместо .mdc Cursor молча проигнорирует. Если правило не работает — первым делом проверьте, лежит ли оно в одном из трёх валидных мест и с правильным расширением.
Современный формат: .cursor/rules и .mdc
Каждый .mdc-файл устроен одинаково: сверху YAML-frontmatter между двумя строками ---, ниже — тело в Markdown. Frontmatter описывает, когда правило срабатывает, тело — что именно делать.
Три поля во frontmatter: description (по нему агент решает, нужно ли правило), globs (маски файлов, при работе с которыми правило подключается), alwaysApply (грузить ли правило в каждый чат). Вот реальный пример — конвенции схемы Drizzle для одного репозитория:
---
description: "Конвенции схемы Drizzle для этого репозитория"
globs: ["db/schema/**/*.ts"]
alwaysApply: false
---
# тело правила (Markdown)
При редактировании файлов в db/schema используй pgTable.
Имена колонок — в snake_case, без camelCase.Здесь правило подключится автоматически, как только в контексте окажется файл из db/schema. В остальное время оно лежит тихо и не ест токены — потому что alwaysApply стоит в false, а globs задаёт точную область действия.
Четыре режима активации правил
Frontmatter определяет, в каком из четырёх режимов живёт правило. Это главное решение при настройке: от режима зависит, сработает ли правило вовремя и сколько токенов оно стоит.
| Режим | Когда срабатывает | Для чего | Риск |
|---|---|---|---|
| Always Apply | В каждом чате, всегда | Базовые конвенции стека, тон, общие запреты | Налог на токены и пере-управление: грузится даже там, где не нужно |
| Auto Attached | Когда glob совпал с файлом в контексте | Правила под конкретный модуль или фреймворк — рабочая лошадка | Слишком широкий glob цепляет лишнее, слишком узкий не срабатывает |
| Agent Requested | Агент решает сам по полю description | Процедуры, нужные изредка | При размытом description агент правило пропустит |
| Manual | Только по явному вызову @rule-name | Тяжёлые редкие воркфлоу: релиз, миграция | Забываешь, что правило вообще есть |
Правило выбора простое: берите самый узкий режим, который всё равно срабатывает тогда, когда нужно. Always Apply кажется надёжным («пусть всегда знает»), но это самый дорогой режим — текст уходит в каждый запрос. Ориентир: правило на ~500 слов добавляет примерно 650 токенов к каждому обращению. Числа зависят от модели и версии Cursor, но направление понятно: в Always Apply держат только то, что действительно нужно везде.
Пример рабочего набора правил для проекта
Как это выглядит на живом проекте. Возьмём типичный Next.js-стек: каждое правило сидит в своём режиме и отвечает за свою зону.
.cursor/rules/
always-apply.mdc # ~150 слов, грузится в каждый чат
drizzle-schema.mdc # auto, globs: db/schema/**
server-actions.mdc # auto, globs: app/**/actions.ts
tailwind-styling.mdc # auto, globs: **/*.tsx
zod-validation.mdc # agent-requested
release-prep.mdc # manual, вызов @release-prepЛогика разбивки: общие конвенции стека — в коротком always-apply. Правила под слой данных, серверные экшены и стили — auto, чтобы подключались только при работе с нужными файлами. Валидация через Zod нужна не постоянно — отдаём агенту на усмотрение. А подготовка релиза — редкий тяжёлый процесс, его вызывают руками через @release-prep.
Хотите ровно настроить эту цепочку под себя — у нас есть отдельный разбор по настройке правил и работе с Cursor без хаоса в проекте.
cursor python rules: язык-специфичные правила
Для языковых конвенций заводят отдельный .mdc с глобами под нужные файлы. Для Python это ["**/*.py", "**/*.pyi"] и alwaysApply: false — правило подключится только когда в контексте есть Python-файлы, а не висит в каждом чате фронтенд-проекта.
Внутрь складывают конкретику: обязательные type hints, форматирование через Ruff, тесты на pytest, структуру модулей. Тот же приём работает для любого языка в репозитории — отдельный файл правил под свой набор глобов.
Legacy .cursorrules: когда ещё ок
Старый .cursorrules — простой текстовый файл в корне репозитория, без frontmatter и режимов. Cursor его всё ещё читает, так что для маленького проекта с парой общих конвенций он сойдёт:
Code Style:
- функциональные компоненты со стрелочными функциями
- именованные экспорты
- строгий режим TypeScriptМинус один и существенный: всё лежит в одном файле и грузится целиком, как режим Always Apply. Нет глобов, нет точечной активации, нет приоритетов. Как только правил становится больше пяти-шести — переезжайте на .cursor/rules с разбивкой по .mdc.
Типичные ошибки и как чинить
- Размытое правило вроде «пиши чистый код». Агенту не за что зацепиться — замените на конкретный констрейнт с измеримым результатом: «функции до 40 строк», «без any в TypeScript».
- Нет контекста проекта. Перечислите, что уже есть в репозитории: db client, logger, auth-хелперы. Иначе агент напишет своё вместо того, чтобы взять готовое.
- Конфликт правил без приоритета. Задайте явную иерархию и пометьте критичное: правила безопасности не нарушать никогда, остальное — по обстоятельствам.
- Правило в неправильном файле — README,
cursor.config.js,.mdвместо.mdc. Работают только три валидных места и расширение.mdc. - Stale cache: поправили
.mdc, а изменения не подхватились. Перезапустите чат и проверьте, что во frontmatter есть закрывающая строка---. - Нет области действия: либо забыли
globs, либо поставилиalwaysApply: trueтам, где не надо. Задавайтеglobs; глобально держите только базлайны безопасности и конвенции коммитов. - Prompt-style вместо rule-style: «ты эксперт по React, веди себя как...». Правила — это декларативные констрейнты, а не ролевая игра. Пишите, что делать, а не кем притвориться.
- Слишком длинное правило — эссе на три тысячи слов. Правило это карточка-справка. Объяснения «почему так» вынесите в отдельный RATIONALE.md для людей, а always-on правило держите коротким: ~100 строк, до 200 слов.
Проверить, что правило вообще загрузилось, можно прямо в чате: в ответе Cursor показывает бейдж «Rules applied: …» со списком сработавших правил. Нет вашего файла в этом списке — значит, оно не подключилось, и причину ищите по списку выше.
Cursor Rules vs CLAUDE.md vs AGENTS.md
Задача у всех трёх одна — объяснить AI контекст проекта. Но читают их разные инструменты, и держать в голове это полезно, если в команде не один редактор.
| Формат | Кто читает | Где лежит |
|---|---|---|
| .cursor/rules / .cursorrules | Только Cursor | Каталог .cursor/rules с .mdc или одиночный .cursorrules в корне |
| CLAUDE.md | Claude Code (Anthropic) | Markdown-файл памяти в репозитории |
| AGENTS.md | Открытый стандарт: Codex, Cursor, Aider и многие другие (Cursor умеет читать и его) | Markdown в корне или в пакетах |
Если работаете в основном через Claude Code, начните с разбора как написать CLAUDE.md. А когда в команде несколько разных редакторов, смотрите в сторону открытого формата — у нас есть отдельный материал, как написать AGENTS.md. Форматы не конфликтуют: можно держать .cursor/rules для Cursor и AGENTS.md для остальных инструментов рядом.
Больше об AI в разработке
В Telegram разбираю редакторы, агентов и рабочие приёмы без хайпа: что реально экономит время, а что просто маркетинг.
Подписаться.cursorrules — один текстовый файл в корне, грузится целиком. .cursor/rules — каталог из отдельных .mdc-файлов с frontmatter, у каждого свой режим активации и область действия по глобам. Cursor читает оба, но для проектов с несколькими правилами рекомендуется модульный .cursor/rules..md вместо .mdc, не закрыт frontmatter строкой ---, или правки не подхватились из кэша. Проверьте бейдж «Rules applied» в ответе чата — если правила там нет, оно не загрузилось..mdc с globs: ["**/*.py", "**/*.pyi"] и alwaysApply: false. Внутрь — конкретные конвенции: type hints, форматирование через Ruff, тесты на pytest. Правило подключится только при работе с Python-файлами и не будет грузиться в каждый чат..cursor/rules читает только Cursor, а AGENTS.md — открытый формат для многих инструментов, включая сам Cursor. В команде с несколькими редакторами держат оба файла рядом, они не конфликтуют.
