Правила
Правила задают системные инструкции для Agent. Они объединяют промпты, скрипты и другие элементы, упрощая управление рабочими процессами и обмен ими в команде.
Cursor поддерживает четыре типа правил:
Правила проекта
Хранятся в .cursor/rules, находятся под контролем версий и применяются к вашей кодовой базе.
Пользовательские правила
Действуют глобально в вашей среде Cursor. Используются Agent (Chat).
Правила команды
Правила для всей команды, которыми можно управлять из дашборда. Доступны на тарифах Team и Enterprise.
AGENTS.md
Инструкции для Agent в формате markdown. Простая альтернатива
.cursor/rules.
Как работают правила
Большие языковые модели не запоминают предыдущие ответы. Правила задают постоянный, многократно используемый контекст на уровне запроса.
При использовании содержимое правил добавляется в начало контекста модели. Это дает ИИ последовательные инструкции для генерации кода, интерпретации правок или помощи при работе с рабочими процессами.
Правила проекта
Правила проекта хранятся в .cursor/rules в виде файлов .mdc и находятся под управлением системы контроля версий. Область их действия задаётся шаблонами путей, они могут вызываться вручную или подключаться в зависимости от их актуальности.
Используйте правила проекта, чтобы:
- Зафиксировать доменные знания о вашей кодовой базе
- Автоматизировать специфичные для проекта рабочие процессы и шаблоны
- Унифицировать решения по стилю и архитектуре
Структура файла правила
Каждое правило — это файл .mdc, который можно назвать как угодно. Для правил проекта обязательно расширение .mdc. Обычный файл .md в .cursor/rules система правил игнорирует, потому что в нём нет фронтматтера, где задаются description, globs и alwaysApply. Если вы предпочитаете обычный markdown, используйте AGENTS.md.
.cursor/rules/ react-patterns.mdc # Распознаётся как правило проекта api-guidelines.md # Игнорируется (неверное расширение) frontend/ # Организуйте правила по папкам components.mdcСтруктура правила
Каждое правило — это markdown-файл с метаданными во фронтматтер и содержимым. Управляйте применением правил через выпадающий список типа правила, который изменяет свойства description, globs, alwaysApply.
| Тип правила | Описание |
|---|---|
Always Apply | Применяется к каждому сеансу чата |
Apply Intelligently | Применяется, когда Agent решает, что правило уместно, исходя из описания |
Apply to Specific Files | Применяется, когда файл соответствует указанному шаблону |
Apply Manually | Применяется, когда правило упоминается в чате через @ (например, @my-rule) |
На уровне реализации три поля фронтматтер определяют, когда правило включается:
alwaysApply | description | globs | Поведение |
|---|---|---|---|
true | — | — | Всегда включено. globs и описание игнорируются. |
false | — | provided | Автоматически прикрепляется, когда в контексте есть подходящий файл. |
false | provided | omitted | Agent читает описание и добавляет правило, когда это уместно. |
false | omitted | omitted | Включается только если вы упоминаете правило в чате через @. |
---alwaysApply: true---- Все исходные файлы должны содержать заголовок с авторскими правами компании- Если вы не уверены в деталях реализации, ознакомьтесь с соответствующими исходными файлами перед тем, как предлагать изменения- Никогда не изменяйте сгенерированные файлы в директориях `dist/` или `build/`---globs: src/components/**/*.tsxalwaysApply: false---- Use named exports, not default exports- Co-locate styles in a module CSS file next to the component- Keep components under 200 lines. Extract subcomponents into the same directory when a file grows beyond that- Prefer composition over prop drilling. Pass children or render props instead of threading data through multiple layers---description: RPC service conventions and patterns for the backendalwaysApply: false---- Define each service in its own file under `src/services/`- Always validate inputs at the service boundary before passing data to internal functions- Return structured error objects with a `code` and `message` field, never throw raw strings- Add a `@service-template.ts` reference file when creating a new service for the standard boilerplate---alwaysApply: false---- Каждая миграция базы данных должна содержать функции `up` и `down`, чтобы её можно было полностью откатить- Никогда не изменяйте тип столбца на месте. Добавьте новый столбец, заполните его данными, затем удалите старый в отдельной миграции- Используйте шаблон для ожидаемой структуры файла@migration-template.sqlПримеры шаблонов glob
Используйте globs, чтобы применить правило к определённым файлам или каталогам. Разделяйте несколько шаблонов запятыми.
| Шаблон | Совпадает с |
|---|---|
* | Любым одним сегментом имени файла |
** | Любым количеством каталогов (рекурсивно) |
*.ts | Всеми файлами .ts в корневом каталоге |
**/*.ts | Всеми файлами .ts в любом каталоге |
src/** | Всеми файлами в любом месте внутри src/ |
src/**/*.tsx | Всеми файлами .tsx в любом месте внутри src/ |
docs/**/*.md, docs/**/*.mdx | Файлами .md и .mdx внутри docs/ (через запятую) |
tailwind.config.* | tailwind.config с любым расширением |
Создание правила
Есть два способа создать правило:
/create-ruleв чате: Введите/create-ruleв Agent и опишите, что вам нужно. Agent сгенерирует файл правила с корректным фронтматтером и сохранит его в.cursor/rules.- Через Customize: Откройте Customize на боковой панели, перейдите в Rules и нажмите Add Rule. Это создаст новый файл правила в
.cursor/rules. В Customize вы можете просматривать все правила и их статус.
Рекомендации
Хорошие правила конкретны, применимы на практике и имеют чётко определённую область действия.
- Держите правила короче 500 строк
- Делите большие правила на несколько модульных, комбинируемых правил
- Приводите конкретные примеры или ссылки на файлы
- Избегайте расплывчатых формулировок. Пишите правила как понятную внутреннюю документацию
- Повторно используйте правила при повторяющихся промптах в чате
- Ссылайтесь на файлы вместо копирования их содержимого — так правила остаются компактными и не устаревают по мере изменений в коде
Чего избегать в правилах
- Копировать целые руководства по стилю: вместо этого используйте линтер. Agent уже знает распространённые соглашения по стилю.
- Документировать каждую возможную команду: Agent знает распространённые инструменты, такие как npm, git и pytest.
- Добавлять инструкции для редких edge cases: держите правила сфокусированными на паттернах, которые вы используете часто.
- Дублировать то, что уже есть в вашем коде: вместо копирования кода ссылайтесь на эталонные примеры.
Начните с простого. Добавляйте правила только тогда, когда замечаете, что Agent повторяет одну и ту же ошибку. Не занимайтесь преждевременной оптимизацией, пока не поймёте свои паттерны.
Закоммитьте свои правила в git, чтобы ими пользовалась вся команда. Когда увидите, что Agent ошибся, обновите правило. Вы даже можете отметить @cursor в issue или PR на GitHub, чтобы Agent обновил правило за вас.
Формат файла правила
Каждое правило — это markdown-файл с метаданными frontmatter и основным содержимым. Метаданные frontmatter определяют, как применяется правило. Основное содержимое — это само правило.
---description: "This rule provides standards for frontend components and API validation"alwaysApply: false---...rest of the rule contentЕсли alwaysApply имеет значение true, правило будет применяться к каждому сеансу чата. В противном случае описание правила будет показано агенту Cursor, который решит, следует ли его применять.
Примеры
Это правило задаёт стандарты для фронтенд‑компонентов:
При работе в директории components:
- Всегда используйте Tailwind для стилизации
- Используйте Framer Motion для анимаций
- Соблюдайте соглашения по именованию компонентов
Это правило обеспечивает валидацию для API‑эндпоинтов:
В директории API:
- Используйте zod для всей валидации
- Определяйте возвращаемые типы с помощью схем zod
- Экспортируйте типы, сгенерированные из схем
Это правило задаёт шаблон для сервисов Express:
Используйте этот шаблон при создании сервиса Express:
- Соблюдайте RESTful‑принципы
- Добавляйте middleware для обработки ошибок
- Настраивайте корректное логирование
@express-service-template.ts
Это правило определяет структуру компонента React:
Компоненты React должны соответствовать следующей структуре:
- Интерфейс props вверху
- Компонент как именованный экспорт
- Стили внизу
@component-template.tsx
Это правило автоматизирует анализ приложения:
Когда нужно проанализировать приложение:
- Запустите dev‑сервер с помощью
npm run dev - Получите логи из консоли
- Предложите улучшения производительности
Это правило помогает генерировать документацию:
Помогайте подготавливать документацию за счёт:
- Извлечения комментариев из кода
- Анализа README.md
- Генерации документации в формате Markdown
Сначала создайте переключаемое свойство в @reactiveStorageTypes.ts.
Добавьте значение по умолчанию в INIT_APPLICATION_USER_PERSISTENT_STORAGE в @reactiveStorageService.tsx.
Для beta‑функций добавляйте переключатель в @settingsBetaTab.tsx, в остальных случаях — в @settingsGeneralTab.tsx. Переключатели можно добавлять как <SettingsSubSection> для обычных чекбоксов. Посмотрите остальные части файла для примеров.
<SettingsSubSection label="Your feature name" description="Your feature description" value={ vsContext.reactiveStorageService.applicationUserPersistentStorage .myNewProperty ?? false } onChange={(newVal) => { vsContext.reactiveStorageService.setApplicationUserPersistentStorage( "myNewProperty", newVal, ); }}/>Чтобы использовать в приложении, импортируйте reactiveStorageService и используйте это свойство:
const flagIsEnabled = vsContext.reactiveStorageService.applicationUserPersistentStorage .myNewProperty;Примеры доступны у провайдеров и фреймворков. Правила, созданные сообществом, можно найти в краудсорсинговых коллекциях и репозиториях онлайн.
Правила команды
Тарифы Team и Enterprise позволяют создавать и применять правила во всей организации из панели управления Cursor. Администраторы могут настраивать, является ли каждое правило обязательным для участников команды.
Правила команды работают совместно с другими типами правил и имеют более высокий приоритет, чтобы обеспечить соблюдение организационных стандартов во всех проектах. Это эффективный способ обеспечить единые стандарты кодирования, практики и рабочие процессы для всей команды без необходимости индивидуальной настройки.
Управление командными правилами
Администраторы команды могут создавать и управлять правилами непосредственно из панели управления Cursor:
После создания командные правила автоматически применяются ко всем участникам команды и отображаются на панели управления:
Активация и применение
- Включить это правило сразу: Если отмечено, правило становится активным сразу после создания. Если не отмечено, правило сохраняется как черновик и не применяется, пока вы не включите его позже.
- Применять это правило принудительно: Если включено, правило обязательно для всех участников команды и не может быть отключено в Customize. Если не применяется принудительно, участники команды могут отключить правило в разделе Правил команды в Customize.
По умолчанию правила команды без принудительного применения могут быть отключены пользователями. Используйте Применять это правило принудительно, чтобы этого не допустить.
Формат и применение правил команды
- Содержимое: правила команды — это свободный текст. Они не используют структуру папок, как правила проекта.
- шаблоны glob: правила команды поддерживают шаблоны glob для применения на уровне отдельных файлов. Когда задан шаблон glob (например,
**/*.py), правило применяется только тогда, когда соответствующие файлы находятся в контексте. Правила без шаблона glob применяются ко всем беседам. - Где применяются: когда правило команды включено (и не отключено пользователем, если только оно не принудительное), оно добавляется в контекст модели для Agent (Chat) во всех репозиториях и проектах этой команды.
- Приоритет: правила применяются в таком порядке: правила команды → правила проекта → пользовательские правила. Все применимые правила объединяются; источники с более высоким приоритетом имеют преимущество при противоречиях в инструкциях.
Некоторые команды используют принудительные правила как часть внутренних процедур соответствия требованиям. Хотя это поддерживается, рекомендации ИИ не должны быть вашей единственной мерой безопасности.
Импорт правил
Вы можете импортировать правила из внешних источников, чтобы повторно использовать существующие настройки или перенести правила из других инструментов.
Удалённые правила (через GitHub)
Импортируйте правила напрямую из любого GitHub-репозитория, к которому у вас есть доступ — публичного или приватного.
- Откройте Customize на боковой панели
- Перейдите в Rules и нажмите Add Rule
- Выберите Remote Rule (Github)
- Вставьте URL-адрес GitHub-репозитория, содержащего правила. Cursor просканирует все файлы
.mdcв репозитории. - Cursor загрузит и синхронизирует правила с вашим проектом
Правила будут размещены в .cursor/rules/imported/<repoName>. Правила также сохранят свои относительные пути, поэтому dir/rule.mdc будет импортирован как .cursor/rule/imported/<repoName>/dir/rule.mdc.
AGENTS.md
AGENTS.md — это простой файл Markdown для задания инструкций агентам. Разместите его в корне проекта как альтернативу .cursor/rules для простых сценариев использования.
В отличие от Project Rules, AGENTS.md — это обычный файл Markdown без метаданных и сложных конфигураций. Он идеально подходит для проектов, которым нужны простые, легко читаемые инструкции без накладных расходов на структурированные правила.
Cursor поддерживает AGENTS.md в корне проекта и во вложенных каталогах.
# Project Instructions## Code Style- Use TypeScript for all new files- Prefer functional components in React- Use snake_case for database columns## Architecture- Follow the repository pattern- Keep business logic in service layersУлучшения
Теперь доступна поддержка вложенных AGENTS.md в подкаталогах. Вы можете размещать файлы AGENTS.md в любом подкаталоге вашего проекта, и они будут автоматически применяться при работе с файлами в этом каталоге или его дочерних каталогах.
Это позволяет более тонко управлять инструкциями для агента в зависимости от части кодовой базы, с которой вы работаете:
project/ AGENTS.md # Глобальные инструкции frontend/ AGENTS.md # Инструкции для фронтенда components/ AGENTS.md # Инструкции для компонентов backend/ AGENTS.md # Инструкции для бэкендаИнструкции из вложенных файлов AGENTS.md объединяются с инструкциями из родительских каталогов, при этом более конкретные инструкции имеют приоритет.
Пользовательские правила
Пользовательские правила — это глобальные параметры в Customize → Rules, которые действуют во всех проектах. Их использует Agent (Chat), и они отлично подходят для задания предпочтительного стиля общения или код‑стиля:
Please reply in a concise style. Avoid unnecessary repetition or filler language.FAQ
Проверьте тип правила. Для Apply Intelligently убедитесь, что задано описание. Для Apply to Specific Files убедитесь, что шаблон файла соответствует файлам, на которые есть ссылки.
Да. Используйте @filename.ts, чтобы включать файлы в контекст правила. Вы также можете
упоминать правила с помощью @ в чате, чтобы применять их вручную.
Да, вы можете попросить агента создать для вас новое правило.
Нет. Правила не влияют на Cursor Tab или другие функции ИИ.
Нет. Пользовательские правила не применяются к Inline Edit (Cmd/Ctrl+K). Они используются только Agent (Chat).
