Cursor Rules: как писать правила, чтобы они реально работали

Знакомая сцена. Вы открыли awesome-cursorrules на GitHub, нашли подходящий набор правил под свой стек — React, Next.js, TypeScript. Скачали, положили в проект, перезапустили Cursor. Просите написать новый компонент. Cursor пишет его так, как будто никаких правил вы не клали — с default-экспортами, с лишними useMemo, с тем же магическим any в типах. В чём дело?

Дело в том, что в 2026 году правила Cursor — это не просто текстовый файл с пожеланиями. Это структурированные документы с YAML-фронтматтером, специальным расширением .mdc и чёткими условиями применения. Без всего этого правила либо не загружаются, либо срабатывают непредсказуемо. По данным независимых исследований, до 100% популярных наборов правил из открытых репозиториев имеют проблемы, из-за которых работают не так, как ожидается.

Дальше — конкретно: что изменилось в структуре правил, какой формат рабочий, как написать правило, которое реально влияет на поведение Cursor, и как проверить чужие правила перед тем, как тащить их в свой проект. Все примеры — рабочие, проверенные на реальных проектах.

Что вообще такое правила Cursor

Cursor Rules — это постоянные инструкции для ИИ-агента редактора. Стиль кода, архитектурные соглашения, антипаттерны проекта, форматы импортов — всё то, что обычно живёт в неписаных договорённостях команды. Без правил Cursor каждый раз начинает работу с нуля и угадывает стиль по открытым файлам. Иногда угадывает, иногда нет.

С явными правилами поведение становится предсказуемым. Когда вы говорите «напиши новый компонент», Cursor смотрит в правила и знает: компонент функциональный, экспорт именованный, валидация через zod, тесты в той же папке. Не нужно повторять это в каждом промпте.

Что изменилось: от .cursorrules к .cursor/rules/

Если последний раз вы настраивали Cursor в 2023 или 2024 году, у вас в голове формат «один файл .cursorrules в корне проекта». В 2026 году это устаревший подход. Cursor официально пометил его как deprecated и рекомендует переходить на новую систему.

Миграция простая: создаёте папку .cursor/rules/ в корне проекта, переносите содержимое старого .cursorrules в новые файлы, добавляете фронтматтер. Старый файл пока работает, но в любой момент может перестать — лучше мигрировать сейчас, чем потом разбираться, почему всё сломалось.

Анатомия рабочего правила: фронтматтер обязателен

Главное, что нужно понять про новый формат: без YAML-фронтматтера правило либо не загрузится, либо будет работать непредсказуемо. Это самая частая ошибка в наборах правил, которые лежат в открытых репозиториях.

Вот пример минимального рабочего правила. Файл .cursor/rules/react-components.mdc:

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

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

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

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

Разберём по частям, что в этом файле важно.

Если в файле нет ни одного из этих полей — Cursor не знает, когда правило должно срабатывать, и поведение становится непредсказуемым. Может загрузиться случайно, может не загружаться вообще.

Четыре режима правил: когда какой выбирать

В новой системе есть четыре способа задать, когда правило применяется. Выбор зависит от области применения и стоимости токенов.

Важная деталь, которая многих сбивает: правила работают только в Agent (Composer и Chat). В Tab completion и в Cmd+K (Inline Edit) они не подгружаются. Если вы пишете правило в надежде, что оно повлияет на автодополнение — оно не повлияет.

Самая частая ошибка новичков — ставить везде alwaysApply: true. Это сжирает токены. Правило, которое подгружается в каждый запрос, всегда висит в контексте. Если оно длинное, реального места для кода остаётся меньше. Используйте Always Apply только для общих вещей, специфичные — через globs.

Один файл — одна тема

Соблазн большой: написать один длинный файл с правилами на все случаи жизни. Не делайте этого.

Когда в одном файле перемешаны именование, обработка ошибок, структура папок и стилизация, происходит две неприятные вещи. Первая: агент не может применить правило точечно — он либо подгружает всё, либо ничего. Вторая: контекстное окно забивается лишним. Если общий файл правил весит 4000 символов, это примерно 1000 токенов в каждом запросе — токенов, которые могли бы идти на ваш код.

Правильная организация — один файл на одну область:

.cursor/rules/
  general.mdc           # язык, общие соглашения (alwaysApply: true)
  naming.mdc            # именование (globs: src/**/*.ts)
  components.mdc        # React-компоненты (globs: src/**/*.tsx)
  errors.mdc            # обработка ошибок (globs: src/**/*.ts)
  testing.mdc           # тесты (globs: **/*.test.ts)
  database.mdc          # запросы и миграции (globs: src/db/**)
  markdown.mdc          # документация (globs: **/*.md)

Рекомендуемый размер каждого файла — до 2000 символов в теле (примерно 500 токенов). Если получилось больше — разбейте на два файла с разными globs или сократите. Скорее всего, там есть размытые формулировки, которые можно выкинуть.

Конкретно и императивно — без «старайся» и «consider»

Это, наверное, главное правило хороших правил. Модель почти не реагирует на размытые формулировки. «Старайся писать чистый код», «consider best practices», «try to use modern patterns» — для агента это шум, который занимает токены, но не влияет на поведение.

Сравнение, как это выглядит на практике:

Размытое (не работает):

- Try to keep functions reasonably short
- Consider using modern React patterns where appropriate
- Aim for clean and maintainable code
- Use best practices for error handling

Конкретное (работает):

- Функции не длиннее 20 строк. Если длиннее — выноси в отдельную функцию.
- Используй функциональные компоненты с хуками. Классовые не пиши.
- Имена переменных описательные: `userOrders`, не `data` или `arr`.
- Все запросы к БД оборачивай в try/catch с конкретным типом ошибки.

Разница между этими двумя вариантами на уровне поведения Cursor — порядок раз. Первый набор Cursor пропустит мимо ушей. Второй — будет реально применять.

Императивная форма «делай так» работает лучше, чем описательная «правильно делать так». Это специфика LLM: они лучше следуют чётким командам, чем абстрактным принципам.

Блок «Что НЕ делать» — секретное оружие

Один из самых эффективных приёмов в Cursor Rules — раздел с явными запретами. Он часто работает лучше, чем длинный список «делай так».

Причина простая: LLM по умолчанию склонна к переусложнению. Добавить лишний слой абстракции, обернуть простую функцию в HOC, поставить useMemo «на всякий случай» — это её естественное поведение. Если явно сказать «не делай этого», модель удерживается от лишних движений.

Примеры рабочих запретов для разных стеков:

Не пытайтесь покрыть все возможные ошибки — выберите 3–5 самых частых для вашего стека. Если запретов больше десяти, начинаются конфликты и Cursor запутается.

Полный пример работающего правила

Сводим всё вместе. Реалистичное правило для проекта на React + TypeScript + TanStack Query, которое реально влияет на поведение Cursor.

Файл .cursor/rules/react-components.mdc:

---
description: React-компоненты с TanStack Query
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
alwaysApply: false
---

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

## Структура

- Один компонент — один файл. Имя файла = имя компонента в PascalCase.
- Хуки данных (useQuery, useMutation) в отдельной папке src/hooks/api/.
- Компонент не делает прямых fetch-вызовов — только через хуки.

## Именование

- Компоненты: PascalCase (UserProfile, OrderList).
- Пропсы: camelCase, типизированы интерфейсом.
- Интерфейс пропсов: ИмяКомпонентаProps (UserProfileProps).
- Бизнес-логика — функции с глаголом: handleSubmit, formatPrice.

## Экспорт

- Именованный экспорт: `export function Button()`.
- Никаких default exports.
- Барелы (index.ts с реэкспортами) — только для публичного API модуля.

## Данные

- Все запросы через TanStack Query (useQuery, useMutation).
- Состояния загрузки и ошибок обрабатываем явно — без скрытых fallback.
- Ключи запросов в src/queries/keys.ts — не разбрасывать по компонентам.

## Что НЕ делать

- Не добавлять useMemo и useCallback без профилировки.
- Не оборачивать в memo() без необходимости.
- Не использовать default exports — поломает рефакторинг.
- Не делать прямые fetch-вызовы в компонентах.
- Не использовать any — только unknown с явной валидацией.

Это правило весит примерно 1100 символов в теле (без фронтматтера). Влезает в рекомендуемые 2000 символов с запасом. Применяется только к компонентам и страницам — не нагружает контекст в других местах. Содержит конкретные команды и блок запретов. Cursor с таким правилом будет вести себя предсказуемо.

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

Прежде чем тащить готовое правило из открытого репозитория в свой проект, пройдитесь по короткому чек-листу из пяти пунктов.

Признаки правила, которое лучше не брать и написать своё с нуля:

• Это просто список технологий: «Next.js 15, React 19, TypeScript 5.4, Tailwind»

• Половина файла — это «You are an expert developer with 20 years of experience...»

• Файл больше 5000 символов

• Используются конструкции вида «think step by step» и другие промпт-инжиниринг-рудименты

• Нет ни одного конкретного запрета — только «делай хорошо»

Когда правило проходит чек-лист — копируйте, иногда правьте под свой проект. Когда не проходит — не пытайтесь его починить, напишите своё. Своё короче, понятнее и будет работать.

Правила в git: командная работа

Папку .cursor/rules/ нужно класть в git. Cursor официально это рекомендует, и для команды это даёт несколько вещей сразу.

Первое — единый контекст у всех разработчиков. Когда коллега открывает проект, у него те же правила, что у вас. Не нужно по чату объяснять «мы тут не используем дефолтные экспорты». Это уже зафиксировано в репозитории.

Второе — упрощённый онбординг. Новый разработчик клонирует репо, открывает в Cursor, и его агент сразу знает соглашения проекта. Без долгого ввода в курс дела.

Третье — версионирование. Когда правила меняются, это видно в истории git. Можно посмотреть, почему какое-то правило добавили, обсудить в pull request, откатить, если что-то идёт не так.

Приоритет правил, если их несколько источников:

На практике большинство команд работает только с Project Rules в репо — этого хватает. Team Rules в дашборде — для крупных компаний с десятками проектов и едиными корпоративными стандартами.

Применимость в других AI-IDE: Claude Code, Windsurf, Continue

Cursor — не единственный AI-редактор в 2026 году. Похожие системы правил есть в большинстве серьёзных инструментов, и принципы там одинаковые. Поэтому навык писать хорошие правила для Cursor легко переносится.

Если в вашей команде используется несколько разных AI-IDE — стоит держать общий источник правды (например, в виде Markdown-документации проекта) и оттуда генерировать формат под каждый инструмент. Иначе правила быстро разъезжаются.

FAQ

Что делать, если правило явно не применяется?

Сначала проверьте фронтматтер: есть ли description, globs или alwaysApply. Дальше проверьте, что вы работаете в Agent (Composer или Chat), а не в Tab или Cmd+K — в них правила не подгружаются. Третье — посмотрите консоль Cursor (Developer Tools), там обычно видно, какие правила загрузились в текущей сессии.

Можно ли подключать одно правило из другого?

Нет, в Cursor нет директивы вроде @include. Каждое правило самостоятельно. Если нужны общие принципы для нескольких правил — напишите их в general.mdc с alwaysApply: true, и они будут подгружаться вместе с любым другим.

Стоит ли писать правила на русском или английском?

Современные LLM одинаково понимают оба языка. Русский удобнее для команды, где все говорят по-русски — проще читать и поддерживать. Английский удобнее, если в команде есть зарубежные участники или если правила копируете из открытых источников. Главное — не смешивать в одном файле.

Что важнее — Cursor Rules или хороший промпт?

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

Сколько правил оптимально иметь в проекте?

5–10 файлов в .cursor/rules/ — нормально для типичного проекта. Если меньше пяти — возможно, вы упускаете важные области. Если больше пятнадцати — скорее всего, есть дубли или слишком мелкое дробление. Оптимально: один файл на каждую крупную область (компоненты, тесты, ошибки, БД, документация).

Cursor не учитывает правило — что-то с globs?

Проверьте синтаксис globs внимательно. Частые ошибки: src/*.tsx вместо src/**/*.tsx (одна звёздочка — только файлы в этой папке, две — рекурсивно), забытый префикс пути, неправильное расширение. Также Cursor применяет globs к пути относительно корня проекта, не относительно текущего файла.

Можно ли проверить правила автоматически?

Да, есть несколько утилит. Самая известная — cursor-doctor, запускается командой npx cursor-doctor lint. Проверяет наличие фронтматтера, длину, размытые формулировки, конфликты между правилами. Полезно прогонять в CI, чтобы не коммитили сломанные правила.

А что насчёт безопасности — правила могут быть вредными?

Правила сами по себе — не код, который выполняется. Это инструкции для модели. Но через них теоретически можно скомпрометировать контекст — например, попросить модель «всегда добавлять этот скрипт в HTML». Поэтому правила из непроверенных источников читайте внимательно. Особенно подозрительно смотрите на правила со ссылками на внешние ресурсы или специфическими URL — это не норма.