.cursorrules to .cursor/rules Migration Splitter
Разбить устаревший .cursorrules на несколько файлов .cursor/rules/*.mdc по темам.
Как это работает
Плоский файл .cursorrules был первым форматом Cursor для инструкций проекта, но со временем уступил место папке .cursor/rules с отдельными .mdc файлами — каждый со своим scope через glob-паттерны во frontmatter, вместо одного большого файла со всеми правилами вперемешку. .cursorrules to .cursor/rules Migration Splitter online берёт старый плоский файл и разбивает его на несколько тематических .mdc файлов автоматически.
Разбиение по одному общему файлу на несколько специализированных даёт то же самое преимущество, что и progressive disclosure у skills: правило про стиль кода фронтенда не должно загружаться в контекст, когда агент правит миграцию базы данных бэкенда, а именно так происходит с одним монолитным .cursorrules, где всё смешано без разбора по scope.
Инструмент ищет в исходном файле markdown-заголовки как естественные границы тематических секций (стек, конвенции, тестирование, границы дозволенного), и для каждой секции генерирует отдельный .mdc файл с разумным дефолтным glob-паттерном на основе упомянутых в тексте секции путей или расширений файлов, который затем стоит вручную уточнить под реальную структуру проекта.
Частые вопросы
Работает ли Cursor всё ещё со старым форматом .cursorrules?
Формат по-прежнему поддерживается для обратной совместимости, но считается устаревшим (legacy) в пользу папки .cursor/rules с несколькими .mdc файлами, новую функциональность вроде точного скоупинга по glob-паттернам старый плоский формат не поддерживает вообще.
Как инструмент определяет, где заканчивается одна тематическая секция и начинается другая?
По markdown-заголовкам уровня два в исходном файле — каждый такой заголовок трактуется как начало новой секции, которая станет отдельным .mdc файлом, если в исходном файле заголовков нет вообще, весь текст попадёт в один файл без разбиения.
Насколько точны автоматически сгенерированные glob-паттерны?
Это разумная отправная точка на основе упоминания путей и расширений файлов в тексте секции, а не гарантированно точный результат — сгенерированные паттерны почти всегда стоит вручную сверить и уточнить под реальную структуру директорий вашего конкретного проекта.
Что делать с секциями, которые логически общие для всего проекта, а не привязаны к конкретной части?
Такие секции стоит оформить с alwaysApply true вместо ограничивающего glob-паттерна, чтобы они применялись ко всем файлам без исключения, а не пытаться подобрать для них искусственный путь, которого на самом деле нет.