Ваша IDE пишет не магия: как за 15 минут приручить Cursor правилами и перестать спорить о точках с запятой

Вы открываете Pull Request (запрос на слияние кода), а там снова чужой стиль: точки с запятой то есть, то нет, хуки названы кто во что горазд, а посреди бизнес-логики торчит console.log. Вы машете шашкой в ревью, автор извиняется, вы мержите (объединяете) код и надеетесь, что завтра будет лучше. Не будет. Ваш код пишет не магия. Модель читает контекст и угадывает стиль команды — пока вы не дадите ей шпаргалку.

Что происходит прямо сейчас: модель каждый раз заново гадает ваши вкусы

Когда вы просите нейросеть написать React-компонент в проекте на TypeScript (надстройка над JavaScript, которая добавляет строгие типы данных), она опирается только на текущий чат и общие знания интернета. Она не знает, что ваш тимлид ненавидит default export (экспорт по умолчанию), требует называть тесты файлами *.spec.ts и считает any (самый опасный тип, отключающий проверку типов) личным оскорблением. Без постоянных рамок ассистент приносит черновик, который технически работает, но ломает вашу культуру кода. В итоге тратится время фронтендера на ручной рефакторинг, а в git blame (истории изменений) вместо реальных задач остаются коммиты «fix lint» и «rename hook».

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

Как это чинится: создаём единый источник правды в .cursor/rules.txt

В редакторе Cursor есть функция «правила проекта». Это простой текстовый файл, который лежит в корне репозитория или в папке .cursor. По сути он делает то же самое, что CLAUDE.md для Claude Code: задаёт ассистенту постоянные рамки на весь диалог. Модель прочитывает его перед тем, как начать писать первый символ кода.

Что туда кладут: — Стиль кода: табы или пробелы, одинарные кавычки, лимит длины строки в 80 символов. Никаких мягких договорённостей — только императив (повелительное наклонение). Вместо «желательно использовать...» пишем «используй...». — Жёсткие запреты: никаких console.log в директории src/, запретить any без комментария // TODO-анализ типов, никакого default export для компонентов. — Подсказки: где искать глобальные типы (в папке @types), как называть тесты (*.spec.tsx), какой паттерн выбрать для асинхронных данных (обёртка useAsync + Suspense).

Пример из жизни студии КодоЦех. Мы устали объяснять джуниорам и модели разницу между именованным и дефолтным экспортом. Добавили одно правило: «Генерируй React-компоненты строго функционально, хуки называй префиксом useX, запрещаю default export. Используй двойные кавычки и точку с запятой в конце строк». В ревью исчезли споры об именах, а мерж-реквесты стали прилетать уже в нашем ESLint-стиле (линтере — программе, проверяющей код на ошибки форматирования). Время первого прохода по PR сократилось вдвое, потому что обсуждать стало нечего — остались только архитектурные вопросы.

Собираем свой файл: пошаговая сборка правил под стек Next.js + TypeScript

Хватит теории. Открываем терминал в корне вашего репозитория и делаем реальную работу. Нам понадобится одна папка и один файл.

Шаг 1. Создаем директорию и файл: mkdir -p .cursor touch .cursor/rules.txt

Шаг 2. Пишем каркас. Никакой воды, только факты о вашем проекте. Скопируйте этот блок:

Стайлгайд

Используй TypeScript со strict-режимом. Используй функциональные компоненты React. Никакого default export. Только именованный: export const Button. Именуй хуки префиксом use: useAuth, useFetch. Лимит строки — 80 символов. Одинарные кавычки, точка с запятой обязательна.

Запреты

Запрещено использовать any без комментария // TODO: анализ типов. Запрещены console.log, alert, prompt в директории src/. Запрещено писать новые классы в слое UI, используй композицию.

Подсказки

Типы лежат в папке src/@types/index.d.ts. Тесты создавай рядом с компонентом: Header.tsx -> Header.spec.tsx. Для запросов используй кастомный хук useApi().

Шаг 3. Адаптируем под реальность. Если у вас монорепозиторий (сразу несколько пакетов кода), добавьте строку: «Применяй эти правила только к пакетам packages/web/*». Если используете Prettier (форматтер кода), сошлитесь на него: «Следуй правилам .prettierrc». Главное правило этого файла — конкретика. Не пишите «код должен быть чистым». Пишите «функция длиннее 20 строк должна быть вынесена в отдельный хук».

Проверяем в бою: даём ассистенту задачу и смотрим на первый черновик

Закоммитьте файл (git add .cursor/rules.txt && git commit -m "chore: add cursor rules") и отправьте изменения в ветку. Теперь самое интересное. Задайте модели любую приземлённую задачу, например: «Напиши компонент ProductCard. Он принимает пропс product {id, title, price}, показывает картинку, название жирным и цену. При клике на кнопку Add to cart вызывает колбэк onAdd(id). Напиши для него тест на пустой объект».

На что смотреть в ответе: — Export: если видите export default function ProductCard — правила не сработали, проверьте путь к файлу. Должно быть строго export const ProductCard. — Console: если внутри кнопки висит console.log('clicked') — запрет проигнорирован. — Hooks: если логика загрузки уходит в componentDidMount — модель забыла про требование функциональных компонентов. — Типы: если цена объявлена просто price, а не price: number — строгий режим упал.

Если модель оступилась, не переписывайте руками. Дайте ссылку на нарушение: «Ты нарушил правило про отсутствие default export. Переделай согласно .cursor/rules.txt». Обычно со второго раза ассистент запоминает границы навсегда.

Что сделать завтра

Откройте свой рабочий репозиторий. Создайте в нём папку .cursor и файл rules.txt. Перенесите туда три главных боли вашей команды: запрет any без комментария, обязательное использование функциональных компонентов и схему именования тестов. Закоммьте файл и скиньте линк в общий чат разработчиков — пусть все ставят Cursor и подтягивают этот файл автоматически.

Задайте ассистенту первую утреннюю задачу: отрефакторить любой старый классовый компонент в функции по вашим новым правилам. Посмотрите, сколько комментариев в ревью вам НЕ придётся писать. Когда увидите чистый дифф (список изменений), где нужно исправить только логику, а не имена переменных — возвращайтесь в блог КодоЦеха и расскажите нам, какую строчку вы добавили первой. Именно из таких локальных побед собирается инженерная культура, которую не стыдно передавать дальше.