О чём этот гайд? Короткий ответ
Короткий ответ: Что такое Rules в Cursor, как оформить .cursor/rules/*.mdc, чем User Rules отличаются от Project Rules и как не перегружать контекст — урок с таблицами и готовыми шаблонами.
Правила в Cursor: User Rules, Project Rules и файлы .mdc
Что такое Rules, какие бывают типы, как написать свои первые правила — и почему это первое, что нужно настроить в любом проекте
Правило (Rule) в Cursor — постоянная инструкция, которую агент видит в начале каждого чата: User Rules (глобально в настройках) и Project Rules в .cursor/rules/*.mdc. Настройте стек, стиль кода и процесс — до скиллов, команд и субагентов.
Что такое правила
Короткий ответ: правило (Rule) — это постоянная инструкция, которую ИИ-агент видит в начале каждого разговора. Это как записка на мониторе: «Помни — комментарии на русском, используй Tailwind, всегда проверяй ошибки».
Представь правила дорожного движения. Ты не включаешь их вручную перед каждой поездкой — они действуют всегда. Красный — стоп, зелёный — езжай. Rules в Cursor работают так же: один раз написал — и агент соблюдает их в каждом разговоре, автоматически. Не нужно напоминать.
Без правил
Каждый раз пишешь: «Отвечай на русском, используй TypeScript, комментируй код…» — агент забывает через 3 сообщения.
С правилами
Написал один раз в файл — агент помнит всегда. Открываешь новый чат — правила уже там. Даже коллеги получают те же правила через Git.
Правила — фундамент. Скиллы, команды, субагенты — всё это надстройки. А правила задают базу: на каком языке общаться, какой стек использовать, какие паттерны соблюдать. Без правил агент каждый раз начинает «с чистого листа».
Два уровня правил
Короткий ответ: глобальные правила — в настройках Cursor; проектные — в .cursor/rules/; устаревший вариант — .cursorrules в корне.
User Rules
Глобальные — действуют во всех проектах. Твои личные предпочтения: язык, стиль общения.
Project Rules
Проектные — действуют только в этом проекте. Стек, паттерны, команды сборки. Попадают в Git.
.cursorrules
Устаревший формат. Ещё работает, но Cursor рекомендует переходить на Project Rules.
User Rules — «Я всегда хочу ответы на русском, код с комментариями, без лишних объяснений».
Project Rules — «В этом проекте мы используем Next.js 15, Tailwind v4, PostgreSQL, деплой на Railway».
Типы проектных правил
Короткий ответ: тип определяет, когда правило цепляется: всегда, по маске файлов, по решению агента или вручную через @rule.
Проектные правила в .cursor/rules/ бывают нескольких типов. Тип определяет, когда правило активируется:
| Тип | Когда активируется | Пример использования |
|---|---|---|
| Always | Всегда — в каждом разговоре | Общие правила проекта: стек, команды сборки, стиль кода |
| Auto Attached | Когда в контексте есть файлы, совпадающие с glob-паттерном | Правила для фронтенда (*.tsx), для бэкенда (*.py), для стилей (*.css) |
| Agent Requested | Агент сам решает по описанию, нужно ли правило | Правила для конкретных задач: «при работе с API используй такой-то паттерн» |
| Manual | Только когда ты вручную подключишь через @ruleName |
Редкие кейсы: шаблоны, специальные инструкции |
Для новичка: начни с Always — это самый простой и понятный тип. Написал правило → оно работает всегда.
Как устроен файл правила
Каждое правило — это файл формата .mdc в папке .cursor/rules/. Внутри — YAML-шапка + Markdown-инструкция:
---
description: Основные правила проекта
globs:
alwaysApply: true
---
# Правила проекта
## Стек
- Frontend: React 18 + TypeScript + Tailwind CSS
- Backend: Node.js + Express
- База данных: PostgreSQL
- Деплой: Railway
## Стиль кода
- Все комментарии на русском языке
- Используй ES modules (import/export)
- Каждый файл не длиннее 200 строк
- Всегда добавляй обработку ошибок
## Команды
- `npm run build` — сборка
- `npm run dev` — локальный сервер
- `npm run test` — тесты
Параметры в шапке
| Параметр | Что делает | Примеры |
|---|---|---|
| description | Описание — для типа Agent Requested агент решает по нему | «Правила для работы с API» |
| globs | Паттерн файлов — для типа Auto Attached | ["*.tsx", "src/components/**"] |
| alwaysApply | Всегда включено — для типа Always | true или false |
Ссылки на файлы
Внутри правила можно ссылаться на файлы проекта через @filename.ts — и они подтянутся как контекст. Например: «Компоненты пиши по образцу @components/Button.tsx». Это мощнее, чем копировать код в правило — файл всегда актуальный.
Как создать правило
Способ 1: Через палитру команд
Нажми Cmd+Shift+P (Mac) или Ctrl+Shift+P (Windows) → набери «New Cursor Rule» → Enter. Cursor создаст файл автоматически.
Способ 2: Вручную
mkdir -p .cursor/rules
touch .cursor/rules/project.mdc
Способ 3: Сгенерировать из чата
Прямо в разговоре с агентом набери команду /Generate Cursor Rules — и агент создаст правило на основе текущего контекста.
User Rules (глобальные)
Открой Cursor Settings → Rules — там простое текстовое поле. Напиши свои предпочтения:
Отвечай на русском языке.
Комментарии в коде — на русском.
Объясняй простым языком, как для новичка.
Не добавляй лишних объяснений — сразу к делу.
Используй ES modules (import/export), не CommonJS.
Правила vs всё остальное — итоговое сравнение
| Критерий | Правила | Скиллы | Команды | Субагенты |
|---|---|---|---|---|
| Когда | Всегда | По необходимости | По вызову / | По решению агента |
| Суть | Фон, контекст | Инструкция | Кнопка | Отдельный работник |
| Токены | Тратит всегда | Только при активации | Только при вызове | Свой контекст |
| Хранение | .cursor/rules/ | .cursor/skills/ | .cursor/commands/ | .cursor/agents/ |
| В Git | Да | Да | Да | Да |
| Для чего | Общие настройки | Процедуры | Частые действия | Сложные задачи |
Правила = фундамент дома (всегда на месте).
Скиллы = инструменты в мастерской (берёшь когда нужен).
Команды = кнопки на пульте (нажал — работает).
Субагенты = нанятые специалисты (работают параллельно).
См. также: субагенты в Cursor и вайбкодинг.
Топ-5 правил для новичка
Готовые правила — скопируй и используй. Каждое решает конкретную проблему.
project-overview.mdc
Самое важное правило: описание стека, команды сборки, структура. Агент читает это первым делом.
---
description: Обзор проекта
globs:
alwaysApply: true
---
# Мой проект
## Стек
- Frontend: HTML + Tailwind CSS
- Backend: Node.js + Express
- База данных: SQLite
- Деплой: Railway
## Команды
- `npm run dev` — запуск локально
- `npm run build` — сборка
- `npm run test` — тесты
## Структура
- src/ — исходный код
- public/ — статические файлы
- tests/ — тесты
code-style.mdc
Единые стандарты: язык комментариев, длина файлов, обработка ошибок.
---
description: Стиль кода
globs:
alwaysApply: true
---
# Стиль кода
- Все комментарии на русском языке
- Используй ES modules (import/export)
- Файлы не длиннее 200 строк — разбивай на модули
- Всегда добавляй try/catch для обработки ошибок
- Имена переменных — осмысленные, на английском
- Перед крупным изменением объясни план словами
frontend.mdc
Активируется только когда ты работаешь с .tsx/.jsx файлами. Не тратит токены на бэкенд-задачи.
---
description: Правила для фронтенд-компонентов
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
alwaysApply: false
---
# Фронтенд-правила
- Функциональные компоненты, не классы
- Tailwind CSS для стилей, не чистый CSS
- Каждый компонент — в отдельном файле
- Деструктуризация пропсов в аргументах
- Адаптивность: mobile-first
workflow.mdc
Как агент должен работать: проверять после изменений, не ломать существующее, предлагать тесты.
---
description: Рабочий процесс
globs:
alwaysApply: true
---
# Рабочий процесс
- После серии изменений — запусти typecheck
- Не удаляй существующий код без объяснения
- При добавлении зависимости — объясни зачем
- API-роуты — в папке api/ по существующим паттернам
- Если задача сложная — сначала составь план
communication.mdc
Как агент разговаривает с тобой: язык, формат ответов, уровень детализации.
---
description: Стиль общения
globs:
alwaysApply: true
---
# Стиль общения
- Отвечай на русском языке
- Объясняй простым языком, без жаргона
- Не повторяй то, что уже сказано
- Если не уверен — спроси, а не угадывай
- Перед кодом — кратко объясни, что будешь делать
- После кода — предложи протестировать
Частые ошибки
Слишком длинные правила
Правила Always тратят токены в каждом разговоре. Если засунуть туда 500 строк — агенту останется меньше места для ответа. Держи правила короткими и по делу. Всё сложное — в скиллы.
Копировать целые файлы в правила
Вместо копирования кода — используй ссылки: @components/Button.tsx. Так правило останется коротким, а файл-образец всегда актуальным.
Писать правила заранее «на все случаи»
Лучший подход: заметил, что агент повторяет одну и ту же ошибку → добавил правило. Не пытайся предугадать всё заранее — правила растут вместе с проектом.
Всё в одном файле
Когда правила разрастаются — разбей по файлам: project-overview.mdc, code-style.mdc, frontend.mdc. Используй Auto Attached для специфичных правил — они не будут тратить токены на нерелевантные задачи.
Организация правил в проекте
Вот пример структуры для реального проекта:
📁 .cursor/
📁 rules/
📄 project-overview.mdc ← Always, общий обзор
📄 code-style.mdc ← Always, стиль кода
📄 frontend.mdc ← Auto Attached: *.tsx
📄 api.mdc ← Auto Attached: api/**
📄 workflow.mdc ← Always, процесс
📄 communication.mdc ← Always, общение
# Держи 2–3 коротких Always-файла + Auto Attached по зонам (frontend, api)
Принцип: 2–3 файла Always (короткие, по делу) + несколько Auto Attached для специфичных частей проекта. Если правил больше 6–7 — подумай, не стоит ли часть вынести в скиллы.
Чеклист: что запомнить
Правила = постоянный контекст — агент видит их в начале каждого разговора
Два уровня: User Rules (глобальные, в настройках) и Project Rules (.cursor/rules/)
Формат файла: .mdc = YAML-шапка + Markdown
4 типа: Always, Auto Attached, Agent Requested, Manual
Правила Always тратят токены всегда — держи их короткими
Используй @filename вместо копирования кода в правила
Попадают в Git — вся команда получает одинаковые настройки
Начни с project-overview + code-style + communication — этого хватит
Правила растут с проектом: заметил ошибку → добавил правило