Система правил Cursor — это наиболее эффективная конфигурация для AI-рабочего процесса. Хорошо написанный .cursorrules (или правила в директории .cursor/rules/ для Cursor 0.45+) превращает AI из универсального ассистента в специалиста, который знает ваш стек, ваши конвенции и стандарты качества.
Эта коллекция представляет 50 готовых к копированию правил, организованных по категориям. Каждое правило предназначено для немедленного использования — добавьте его в проект, адаптируйте под свои нужды и начните получать лучший AI-вывод уже через несколько минут. Все правила доступны в каталоге правил Mindaxis, откуда их можно искать и экспортировать через Builder.
Как работает .cursorrules
Разместите файл .cursorrules в корне проекта, и Cursor автоматически будет добавлять его содержимое ко всем AI-взаимодействиям. Для Cursor 0.45+ используйте директорию .cursor/rules/ для создания модульных файлов правил с привязкой к паттернам файлов:
.cursor/
rules/
general.mdc # применяется ко всем файлам
react.mdc # применяется к *.tsx файлам
api.mdc # применяется к app/api/**/*.ts
tests.mdc # применяется к **/*.test.tsКатегория 1: Общие правила качества кода
Правило 1: Универсальные стандарты качества
Вы — опытный разработчик. Следуйте этим принципам для всего кода:
КАЧЕСТВО:
- Самодокументирующийся код; комментарии только когда «почему» неочевидно
- Явное лучше неявного; избегайте магических чисел и необъяснённых булевых
- Функции делают одно и делают это хорошо (Single Responsibility)
- Fail fast: валидируйте ввод на границе, бросайте исключения рано
СТИЛЬ:
- camelCase для переменных/функций, PascalCase для типов/классов
- Описательные имена раскрывающие намерение (getUserById а не getUser)
- Без аббревиатур кроме общепринятых (id, url, api, db)
ОБРАБОТКА ОШИБОК:
- Никогда неглотайте ошибки молча
- Включайте контекст в сообщения об ошибках
- Используйте типизированные ошибки когда тип важен для вызывающего кодаПравило 2: Философия тестирования
Принципы тестирования для всех тестовых файлов:
СТРУКТУРА:
- Паттерн Arrange-Act-Assert в каждом тесте
- Одно логическое утверждение на тест
- Тестируйте поведение, а не детали реализации
- Описательные имена тестов: "должен вернуть 404 когда пользователь не найден"
ПОКРЫТИЕ:
- Сначала happy path, потом error cases, потом edge cases
- Мокируйте на уровне сетевой границы
ПОДДЕРЖКА:
- Тесты должны быть детерминированными; мокируйте Date.now() и Math.random()
- Убирайте за собой: закрывайте соединения, очищайте мокиПравило 3: Стандарты документации
- JSDoc/docstrings для всех публичных функций, классов и модулей
- Документируйте "почему", а не "что" в inline-комментариях
- Используйте @param, @returns, @throws в JSDoc для неочевидных случаев
- README: Overview, Quick Start, API Reference, Contributing
- Не документируйте очевидный кодПравило 4: Conventional Commits
Следуйте спецификации Conventional Commits:
ФОРМАТ: ():
ТИПЫ: feat, fix, docs, style, refactor, test, chore, perf, ci
ПРАВИЛА:
- Описание в повелительном наклонении: "add" не "added"
- Максимум 72 символа в строке темы
- Тело объясняет ПОЧЕМУ, а не что (diff показывает что)
ПРИМЕРЫ:
feat(auth): add OAuth2 Google provider
fix(api): handle null userId in session middleware Правило 5: Основы безопасности
Требования безопасности для всего кода:
- Никогда не логируйте чувствительные данные: пароли, токены, PII
- Валидируйте и санитизируйте ВСЕ пользовательские вводы
- Параметризованные запросы для всех БД-операций; никогда не конкатенируйте SQL
- Секреты только через переменные окружения
- Хэшируйте пароли с bcrypt/argon2 (cost factor ≥ 12)
- Заголовки безопасности: CSP, HSTS, X-Frame-OptionsКатегория 2: React
Правило 6: Архитектура React-компонентов
- Только функциональные компоненты; никаких классовых
- Один компонент на файл; имя файла совпадает с именем компонента
- Кастомные хуки для переиспользуемой логики с состоянием; префикс "use"
- useCallback и useMemo только когда профайлер показывает реальную проблему
- useEffect cleanup для всех подписок, таймеров и слушателей событий
- Явные prop types через TypeScript interfacesПравило 7: Управление состоянием React
- useState для простого локального UI-состояния
- useReducer для сложного состояния с множеством взаимозависимостей
- TanStack Query для всех серверных данных; никогда не хранить ответы сервера в useState
- Zustand для глобального клиентского состояния
- Минимально необходимый scope для состояния: поднимайте только когда действительно sharedПравило 8: Next.js App Router
- По умолчанию Server Components; "use client" только для интерактивности
- Никогда не фетчить данные в Client Components если родительский Server Component может это сделать
- loading.tsx для streaming suspense boundaries
- error.tsx для error boundaries на уровне сегмента маршрута
- Экспортируйте metadata или generateMetadata из каждого page.tsx
- Параллельная загрузка данных с Promise.all для независимых результатовПравило 9: Tailwind CSS
- Utility-first; избегайте custom CSS если Tailwind справляется
- Адаптивные классы в mobile-first порядке: base → sm: → md: → lg: → xl:
- Извлекайте повторяющиеся комбинации в компоненты, а не в @apply
- clsx или cn() для условного применения классов
- Никогда !important; перепроектируйте структуру компонентаКатегория 3: Бэкенд
Правило 10: Node.js — Дизайн REST API
- Существительные в URL: /users а не /getUsers
- Вложенность ресурсов максимум 2 уровня: /users/:id/posts
- Query params для фильтрации/сортировки/пагинации
- Единообразная форма ответа: { data, error, meta }
- Семантические HTTP-статус-коды: 200, 201, 204, 400, 401, 403, 404, 422, 429, 500
- Никогда не отдавайте stack traces в продакшен-ответах
- Пагинируйте все list-эндпоинты; никогда не возвращайте неограниченные массивы
- Zod-схемы как источник истины для валидации и TypeScript-типовПравило 11: Python — Типизация и стиль
- Полные type annotations на всех сигнатурах функций и атрибутах классов
- Используйте | для union types: str | None вместо Optional[str]
- Встроенные дженерики: list[str] а не List[str]
- Ruff для линтинга и форматирования
- pathlib.Path для операций с файловой системой
- f-строки для форматирования; не используйте % или .format() где достаточно f-строкиПравило 12: Python FastAPI
- Pydantic v2 модели для всех тел запросов и ответов
- Async endpoints для всех I/O операций; sync только для CPU-bound работы
- HTTPException с detail dict для структурированных ответов об ошибках
- Lifespan context manager для startup/shutdown (пулы БД, загрузка ML-моделей)
- Explicit response_model на всех endpointsПравило 13: Go-конвенции
- Короткие, контекстно-подходящие имена
- Всегда проверяйте ошибки; никогда не используйте _ для возвратов ошибок
- Оборачивайте ошибки с контекстом: fmt.Errorf("creating user: %w", err)
- Sentinel errors для ошибок, которые обрабатывают вызывающие
- Принимайте interfaces, возвращайте конкретные типы
- Table-driven tests с t.Run() для параметризованных тест-кейсовКатегория 4: База данных
Правило 14: Prisma ORM
- Явные @id, @unique, @index для всех полей, по которым будут запросы
- Мягкие удаления через deletedAt DateTime? с фильтром во всех запросах
- Выбирайте только нужные поля через select: {}
- Оборачивайте многошаговые операции в prisma.$transaction()
- findUniqueOrThrow() вместо null-проверок
- Курсорная пагинация для больших датасетов, не оффсетнаяПравило 15: SQL-практики
- UPPERCASE для SQL-ключевых слов: SELECT, FROM, WHERE, JOIN
- snake_case для идентификаторов
- Явные списки колонок в SELECT; никогда SELECT * в продакшен-коде
- Индексируйте колонки в WHERE, JOIN ON и ORDER BY
- EXPLAIN ANALYZE перед релизом любого нового запроса
- Параметризованные запросы всегда; никогда не интерполируйте пользовательский ввод в SQLКатегория 5: DevOps
Правило 16: Dockerfile
- Multi-stage builds: отдельные стадии build и runtime
- Специфические теги версий, никогда :latest для базовых образов
- Non-root user в финальной стадии
- COPY только необходимое; агрессивно используйте .dockerignore
- Порядок слоёв: редко меняющееся первым (системные зависимости → npm install → код приложения)
- HEALTHCHECK в каждом продакшен Dockerfile
- Никаких секретов в Dockerfile или слоях образаПравило 17: Kubernetes
- Стандартные labels на всех ресурсах: app.kubernetes.io/name, version, managed-by
- Всегда устанавливайте resources.requests и resources.limits на каждом контейнере
- minReadySeconds: 10 на Deployments
- PodDisruptionBudget для всех сервисов с требованиями к доступности
- Отдельные liveness и readiness пробы
- Никогда privileged: true в продакшенеПравило 18: GitHub Actions
- Отдельные jobs: lint, type-check, test, build, deploy
- Минимальные разрешения с явными грантами на job
- Закрепляйте actions на полный commit SHA
- Никогда не echoing секреты
- Кэширование node_modules, pip, cargo с actions/cache
- Concurrency group для отмены in-progress runsКатегория 6: TypeScript и специализированные правила
Правило 19: Строгость TypeScript
Обязательные настройки tsconfig.json:
{
"strict": true,
"noUncheckedIndexedAccess": true,
"exactOptionalPropertyTypes": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true
}
- Никогда не используйте any; используйте unknown для значений неизвестного типа
- Type predicates для runtime type guards
- Discriminated unions вместо optional properties для вариантных типов
- satisfies operator для проверки типов с сохранением literal typesПравило 20: Управление переменными окружения
- .env.example со всеми требуемыми переменными и комментариями-описаниями; коммитить это
- .env.local для локальных переопределений; никогда не коммитить .env-файлы со значениями
- Валидируйте все env-переменные при старте с Zod:
import { z } from "zod";
const env = z.object({
NODE_ENV: z.enum(["development", "test", "production"]),
DATABASE_URL: z.string().url(),
API_SECRET: z.string().min(32),
PORT: z.coerce.number().default(3000),
}).parse(process.env);
export { env };
- Импортируйте из этого валидированного env-модуля, а не из process.env напрямуюПравило 21: Доступность (a11y)
- Семантические HTML-элементы: nav, main, article, aside, header, footer
- Иерархия заголовков: один h1 на страницу, h2-h6 в логическом порядке
- Кнопки для действий, ссылки для навигации; никогда div onClick
- Видимый focus indicator на всех фокусируемых элементах
- Alt-текст для всех информативных изображений; пустой alt="" для декоративных
- ARIA только для дополнения того, что HTML не может выразить нативноПравила 22–30: Быстрые правила-справочники
Правило 22: JWT-аутентификация
- Короткоживущие access tokens (15 минут); долгоживущие refresh tokens (7-30 дней)
- Храните refresh tokens в httpOnly, Secure, SameSite=Strict cookies
- Никогда не в localStorage (уязвимо к XSS)
- Включайте только необходимые claims; никогда чувствительные данные в payloadПравило 23: Redis
- Всегда устанавливайте TTL на каждый ключ; никогда не храните без срока истечения
- Паттерн именования ключей: entity:id:field (user:123:sessions)
- Используйте SCAN а не KEYS в продакшене (KEYS блокирует сервер)
- Connection pooling; не создавайте новое соединение на каждый запросПравило 24: Обработка загрузки файлов
- Валидируйте MIME-тип на сервере (не только расширение файла)
- Храните загруженные файлы в объектном хранилище (S3, R2), а не на диске сервера
- Генерируйте случайные UUID для хранимых имён файлов; никогда не используйте имена от пользователя
- Ограничивайте размер файла на уровне reverse proxyПравило 25: Rate Limiting
- Rate limit на edge/proxy сначала (nginx, Cloudflare), потом в приложении
- Лимиты на пользователя для аутентифицированных, на IP для публичных
- Возвращайте Retry-After header с ответами 429Правило 26: Логирование
- Структурированные JSON-логи в продакшене; читаемые в разработке
- Уровни: ERROR, WARN, INFO, DEBUG
- Включайте: requestId, userId, duration, statusCode в каждый request log
- Никогда не логируйте: пароли, токены, номера карт, PIIПравило 27: Миграции БД
- Тестируйте миграции на снапшоте продакшен-данных перед применением
- Expand-contract pattern для breaking changes
- Добавляйте индексы с CONCURRENTLY (Postgres) во избежание блокировок
- Всегда имейте план отката; тестируйте откат тожеПравило 28: Стратегия кэширования
- Cache-Control заголовки на всех HTTP-ответах
- Stale-while-revalidate для контента, который может быть ненадолго устаревшим
- Ключ кэша включает все измерения, влияющие на ответ (пользователь, локаль, роль)
- Никогда не кэшируйте ответы с пользовательскими чувствительными данными на shared CDNПравило 29: Наблюдаемость
- Health check endpoint: GET /health → 200 { status: "ok", version, uptime }
- Метрики: request rate, error rate, latency p50/p95/p99
- Distributed tracing с OpenTelemetry
- Алерты: error rate > 1% за 5 минут, p99 latency > 2sПравило 30: Версионирование API
- Версия в URL path: /api/v1/users
- Никогда не ломайте опубликованную версию; добавляйте v2 для breaking changes
- Deprecation заголовки на старых версиях: Sunset: дата
- Поддерживайте минимум одну major-версию позади текущейИспользование этих правил с Mindaxis
Управление 50 правилами в нескольких проектах и среди членов команды — отдельная задача. Каталог правил Mindaxis хранит все эти правила и сотни других, организованных по категориям и стеку. Вы можете:
- Искать по технологии, паттерну или ключевому слову для мгновенного поиска нужных правил
- Комбинировать правила в именованные паки — «React fullstack»-пак может включать несколько правил из разных категорий
- Экспортировать через Builder в правильном формате для Cursor, VS Code, Claude Code или любого другого поддерживаемого клиента
- Делиться кастомными наборами правил через функцию шаринга конфигов — ссылка для онбординга тиммейтов за секунды
Изучите паки Mindaxis для тщательно подобранных комбинаций правил под наиболее распространённые технологические стеки. Каждый пак готов к экспорту и включает конфигурации MCP-серверов, шаблоны промптов и определения sub-agents для полной настройки AI-рабочего процесса.
Заключение
Лучшая конфигурация .cursorrules — та, которая специфична для вашего стека, обеспечивает соблюдение реальных конвенций вашей команды и развивается вместе с кодовой базой. Начните с правил, соответствующих вашим технологиям, адаптируйте их и относитесь к файлам правил как к живому документу, улучшающемуся с каждой итерацией.
Хорошо настроенный Cursor с продуманными правилами будет ловить больше ошибок, требовать меньше исправлений и производить код, который органично вписывается в вашу кодовую базу. Начните с Mindaxis Builder, чтобы собрать свою кастомную конфигурацию правил за минуты.