Как автоматизировать это в Cursor
Чтобы не держать всё в голове и не пересказывать каждый раз, я для больших вайб-код проектов создаю хитрые Cursor Rules.
Если кратко то рулесы это постоянный, управляемый контекст курсора, который содержит в себе правила поведения идешки, они лежат в директории .cursor/rules/, которая коммитается в реп, что позволяет версионировать правила курсора вместе с кодом проекта.
Обычно указанная папка находится в корне проекта, но случае если проект имеет формат монорепозитория возможно для каждого подпроекта сделать свой собственный набор правил.
project/
.cursor/rules/ # глобальные правила
backend/
.cursor/rules/ # правила бэкенда
frontend/
.cursor/rules/ # правила фронтенда
Внутри указанных директорий в .mdc-файлах хранятся собственно сами правила, MDC как я понял был выбран потому, что помимо текста в Markdown там можно хранить дополнительные метаданные и ещё мне кажется, потому, что авторы курсор не смогли через гугл найти аналогичный, но чуть более проработанной, стандарт, под названием MDX.
Пример .mdc-файла:
---
description: Краткое описание данного набора правил
globs: app/**/*.php
alwaysApply: true
---
- Следуй паттерну PSR-2
- Используй camelCase в названии фукций
@ссылка-на-файл.php
@или-скажем-на-ТЗ.md#главу-1
@или-на-другой.mdc
Тексты из .mdс-файлов подмешиваю к промтам через alwaysApply (true - всегда), если не указывать alwaysApply то агент будет сам решать когда их применять, а ещё можно заставить агента выполнить их принудительно (ручной вызов через @название-mdc-файла).
Помимо этого стараюсь в директорию docs складывать какие-то общие правила и документацию по проекту, само техническое задание, эскизы архитектуры и так далее.
docs/
ARCHITECTURE.md
CLASS_MAP.md
TECH_REQUIREMENTS.md
Благодаря чему из .mdc-файлов можно ссылаться на файлы документации, чтобы они попадали в контекст когда вызывается рулес.
Ещё одна важная фича, которую умеет Cursor - это автоматическая генерация правил, просто пишем команду /Generate Cursor Rules и идешка сама создаст правила для уже существующей кодовой базы, что облегчает переход на вайб-кодинг в легаси проектах.
Чтобы не держать всё в голове и не пересказывать каждый раз, я для больших вайб-код проектов создаю хитрые Cursor Rules.
Если кратко то рулесы это постоянный, управляемый контекст курсора, который содержит в себе правила поведения идешки, они лежат в директории .cursor/rules/, которая коммитается в реп, что позволяет версионировать правила курсора вместе с кодом проекта.
Обычно указанная папка находится в корне проекта, но случае если проект имеет формат монорепозитория возможно для каждого подпроекта сделать свой собственный набор правил.
project/
.cursor/rules/ # глобальные правила
backend/
.cursor/rules/ # правила бэкенда
frontend/
.cursor/rules/ # правила фронтенда
Внутри указанных директорий в .mdc-файлах хранятся собственно сами правила, MDC как я понял был выбран потому, что помимо текста в Markdown там можно хранить дополнительные метаданные и ещё мне кажется, потому, что авторы курсор не смогли через гугл найти аналогичный, но чуть более проработанной, стандарт, под названием MDX.
Пример .mdc-файла:
---
description: Краткое описание данного набора правил
globs: app/**/*.php
alwaysApply: true
---
- Следуй паттерну PSR-2
- Используй camelCase в названии фукций
@ссылка-на-файл.php
@или-скажем-на-ТЗ.md#главу-1
@или-на-другой.mdc
Тексты из .mdс-файлов подмешиваю к промтам через alwaysApply (true - всегда), если не указывать alwaysApply то агент будет сам решать когда их применять, а ещё можно заставить агента выполнить их принудительно (ручной вызов через @название-mdc-файла).
Помимо этого стараюсь в директорию docs складывать какие-то общие правила и документацию по проекту, само техническое задание, эскизы архитектуры и так далее.
docs/
ARCHITECTURE.md
CLASS_MAP.md
TECH_REQUIREMENTS.md
Благодаря чему из .mdc-файлов можно ссылаться на файлы документации, чтобы они попадали в контекст когда вызывается рулес.
Ещё одна важная фича, которую умеет Cursor - это автоматическая генерация правил, просто пишем команду /Generate Cursor Rules и идешка сама создаст правила для уже существующей кодовой базы, что облегчает переход на вайб-кодинг в легаси проектах.