Правила Cursor: настройка проекта и примеры для TypeScript

Польза — меньше правок на ревью. Допустим, четыре разработчика каждую неделю тратят по пять минут на три одинаковых исправления. Получается 60 минут на повторение одних и тех же соглашений. Это условный расчёт, а не обещанная экономия. Посчитайте, какие исправления исчезли после настройки, и вычтите время на поддержку правил. Стоимость подписки — отдельная тема, разобранная в статье о тарифах Cursor.

Где хранить правила Cursor

Общие решения по коду должны лежать рядом с кодом. Личные предпочтения к ответам пусть остаются личными.

Инструкции из вложенного AGENTS.md действуют в его каталоге и дочерних каталогах вместе с инструкциями родительских уровней; более конкретные указания имеют приоритет. Для правил команды, проекта и пользователя документация задаёт такой порядок разрешения конфликтов: Team → Project → User. Документация Cursor о правилах

Для небольшой команды я обычно выбираю правила проекта. Указание «используй наши готовые компоненты форм» относится к репозиторию. «Отвечай кратко в финальном сообщении» — ваше личное предпочтение. Если хранить их отдельно, личная привычка случайно не превратится в правило для всей команды.

Когда подключать каждое правило

За подключение отвечает frontmatter — небольшой блок настроек перед текстом правила.

«По выбору агента» означает, что агент сам выбирает правило по его описанию. Glob — это шаблон пути к файлу. Как работают подключение и синтаксис правил

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

Три готовых правила для веб-приложения на TypeScript

Создайте в репозитории следующие файлы. Это примеры внутренних соглашений команды с полями frontmatter и синтаксисом шаблонов из документации Cursor. Сами инструкции — основа для адаптации, а не стандарты разработки, предписанные Cursor.

Стиль кода: подключайте правило к файлам TypeScript

Сохраните в .cursor/rules/style.mdc:

---
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---

- Follow the nearest existing module's naming and import conventions.
- Prefer named exports unless the framework requires a default export.
- Reuse existing UI components and utilities before adding alternatives.
- Keep formatting in the repository's formatter and linter configuration.

В примере предполагается, что код приложения находится в src/; измените пути под свой репозиторий. Здесь намеренно описаны решения, которые не примет форматтер: например, есть ли в приложении подходящая кнопка или утилита для работы с датами. Если команда выбрала другой подход к экспорту, измените соответствующую строку. Правило должно описывать ваш репозиторий, а не незаметно менять его устройство.

Тесты: опишите задачи, для которых они нужны

Сохраните в .cursor/rules/tests.mdc:

---
description: Testing requirements when adding features, fixing bugs, or changing TypeScript behavior
alwaysApply: false
---

- Cover changed behavior with a focused regression test.
- Use the existing test runner, fixtures, and file naming conventions.
- Read package.json for the relevant test script; do not invent a command.
- Report the command and actual result, or explain why tests were not run.

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

Если хотите явно применить этот список требований к задаче, добавьте в запрос @tests. Если команда хочет применять его ко всем задачам, переключите режим на Always Apply. Это должно быть осознанным решением команды: одно лишь описание оставляет выбор за агентом.

Безопасность: короткий список базовых требований

Сохраните в .cursor/rules/security.mdc:

---
alwaysApply: true
---

- Never put secrets in source code, test fixtures, or application logs.
- Use existing server-side authentication and authorization helpers.
- Validate untrusted input at server boundaries with the existing schemas.
- Do not remove permission checks to make a feature or test pass.

Когда знаете точные пути к модулям репозитория, укажите их вместо «существующих вспомогательных функций». Базовые требования должны быть понятны и при работе над обычной функцией продукта. Формулировка «сделай безопасно» мало помогает на ревью; «сохрани проверку прав доступа» задаёт конкретное требование.

Этот файл задаёт инструкции, но сам по себе не обеспечивает защиту. Продолжайте проверять права доступа в коде и проводить ревью изменений, затрагивающих безопасность. Сам Cursor предостерегает от использования инструкций для ИИ как единственной меры защиты. Рекомендации по Team Rules

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

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

1. Запишите ожидаемый результат. Укажите, какой готовый компонент использовать, какое поведение проверить тестом и на какой границе сохранить валидацию.
2. Сохраните три файла и проверьте их статус. В Cursor правила доступны в Customize → Rules; в Agent также есть команда /create-rule. Создание правила
3. Попросите внести изменение, добавив нужные файлы в контекст. Сформулируйте обычный рабочий запрос. Если повторить в нём все правила, вы не узнаете, помогла ли настройка.
4. Изучите diff и отчёт о проверках. Смотрите, соблюдены ли соглашения в самом коде, а не верьте заверению, что правила выполнены. Если для этой пробы важны требования к тестам, явно запросите @tests.
5. Добавьте полезные правила в коммит вместе с изменением. Так у команды появится исходный вариант, который можно обсудить на ревью. Прежде чем создавать ещё один файл, исправьте расплывчатую формулировку в существующем.

Если соглашение не соблюдено, различайте две причины: правило не попало в контекст задачи либо попало, но не помогло. В первом случае нужно исправить подключение. Во втором — уточнить инструкцию, добавить пример или автоматическую проверку.

Какие соглашения стоит закрепить в правилах

Начните с повторяющихся ошибок, которые обходятся команде дороже всего. Ниже — практические варианты в порядке того, сколько работы они потенциально могут снять с ревью.

Это не повод обязательно создавать ещё пять файлов. Если проблема не возникала, не добавляйте правило. Если требование можно точно проверить автоматически, выбирайте такую проверку. Полезное правило закрывает пробел между запросом на задачу и уже имеющимися инструментами репозитория.

Что делать со старым файлом .cursorrules?

Для настройки правил проекта по актуальной документации используйте .cursor/rules/*.mdc. По состоянию на 11 октября 2026 года страница документации о правилах не упоминает .cursorrules, поэтому она не подтверждает, работает ли ещё старый файл. Актуальная документация

Если старый файл ещё есть в репозитории, я рекомендую перенести полезные инструкции в отдельные правила проекта, взяв за основу три файла выше. Выберите условия их подключения и проверьте всё на реальной задаче, прежде чем убирать старую копию. Не сохраняйте устаревшие соглашения только потому, что они уже записаны.

Как это соотносится с CLAUDE.md и AGENTS.md

Общий принцип — постоянные инструкции для проекта: у Claude Code есть CLAUDE.md, а Codex читает рабочие соглашения в AGENTS.md. В Cursor вариант с обычным Markdown решает ту же простую задачу, а файлы .mdc позволяют выбирать условия подключения. Сами соглашения должны быть согласованы между инструментами, но поведение загрузки нужно настраивать для каждого отдельно: скопировать текст — не то же самое, что перенести настройки. Если команда работает с несколькими агентами, назначьте одного ответственного за общие соглашения, чтобы файлы не превратились в противоречащие друг другу источники правил.

Какие два небольших инструмента можно сделать после настройки

Проверка правил репозитория — более перспективная идея для технического руководителя: проверять расширения файлов, допустимые поля frontmatter и шаблоны, под которые не попадает ни один отслеживаемый файл. Минимальная полезная версия — локальный отчёт, запускаемый во время ревью. Признак спроса скромный: при подготовке этой статьи DataForSEO показал 140 поисковых запросов «cursor rules examples» в месяц по оценке сервиса. Это интерес к смежной теме, а не доказательство готовности платить. Ограничение очевидно: даже структурно корректное правило может содержать неудачные инструкции. Определение метрики

Пакет материалов для ревью командных соглашений может помочь руководителю, который поддерживает несколько репозиториев. Собирайте повторяющиеся замечания с ревью и одобренные примеры в предлагаемый diff правил, назначая проверяющего для каждого изменения. DataForSEO показал 70 поисковых запросов «cursor team rules» в месяц по оценке сервиса. Начните с внутренней утилиты: встроенные Team Rules уже решают задачу распространения, поэтому ещё одна панель для хранения правил — слабая продуктовая идея. Полезная работа здесь — решить, что заслуживает места в постоянных инструкциях. Определение метрики

Частые вопросы о настройке правил

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

Если хотите встроить это в процесс разработки команды, такая работа относится к направлению ИИ-систем для продакшена.