Cursor Rules: как записать правила проекта и проверить, что агент им следует
Cursor Rules нужны не для длинной редполитики, а для повторяющихся ограничений проекта. Хорошее правило коротко объясняет, когда оно действует, что агент обязан сохранить и как проверить результат. Актуальный формат хранится в .cursor/rules; старый файл .cursorrules считается устаревшим.
Выберите одно повторяющееся ограничение
Допустим, в проекте API-обработчики лежат в src/api, получают зависимости через аргументы и всегда возвращают объект с полями data и error. Агент регулярно создает собственный формат ответа.
Это подходит для правила. А фраза «пиши хороший код» не подходит: ее нельзя проверить.
Создайте узкое правило
В настройках Cursor откройте раздел Rules и создайте project rule. Сохраните его в .cursor/rules/api-handlers.mdc. Для автоматического применения привяжите правило к файлам API, например src/api/**/*.ts.
Содержание может быть таким:
Для файлов src/api/**/*.ts используй существующий тип ApiResult. Не создавай новый формат ответа. Зависимости получай через аргументы функции, не импортируй глобальный клиент базы. После изменения запускай существующие тесты этого обработчика. Не меняй публичные маршруты без отдельного запроса.
Правило должно ссылаться на реальный тип и реальную команду. Если структура проекта поменялась, обновите правило в том же pull request.
Проверьте применение на маленькой задаче
Попросите Cursor добавить обработчик проверки статуса:
В src/api/health.ts добавь функцию, которая проверяет доступность хранилища через переданную зависимость. Сначала перечисли активные правила и предложи минимальный план. Не меняй маршрутизацию.
До принятия кода проверьте три вещи: использован ли ApiResult, передана ли зависимость через аргумент и остались ли маршруты без изменений.
Сравните результат без правила
Для честной проверки временно отключите правило и попросите составить план похожей функции в другом учебном файле. Не обязательно принимать изменения. Если ответы одинаково соблюдают ограничения, правило может быть слишком общим или модель уже взяла паттерн из соседнего кода.
Полезное правило уменьшает количество исправлений, но не отменяет review. Cursor поддерживает Always, Auto Attached, Agent Requested и Manual rules. Выбирайте самый узкий режим, который стабильно срабатывает.
Не кладите в Rules секреты
Файлы project rules обычно попадают в Git. Не записывайте туда ключи, внутренние пароли и данные клиентов. Инструкции могут указывать названия переменных окружения, но не их значения.
В ИИ-лаборатории Глеба Кудрявцева «Вайбкодинг на максималках» правила проекта как раз решаются в связке с постановкой задач, Git и проверками в VS Code с Codex.
Правило готово, если оно автоматически применяется к нужным файлам, агент соблюдает три конкретных ограничения, а команда может понять файл без истории чата.