Feature request for product/service
Chat
Describe the request
When the Cursor agent creates database migrations, it often writes migration files manually with invented, rounded timestamps (e.g. 20260611120000, 2024_01_15_120000) instead of running the framework CLI.
Affected frameworks (same pattern)
Rails: db/migrate/YYYYMMDDHHMMSS_.rb — agent often uses 120000 (noon placeholder)
Laravel: database/migrations/YYYY_MM_DD_HHMMSS_.php — same issue in my experience
Django: python manage.py makemigrations should be preferred over hand-written migration files
Why this hurts teams
Migration order is determined by the timestamp prefix. When multiple developers or agent sessions work in parallel:
duplicate or conflicting migration order on merge
manual renames and deleted/recreated files
migrations running in wrong order across environments
The agent has shell access and could run rails generate migration, php artisan make:migration, or makemigrations — each produces a unique, precise timestamp. It often doesn’t.
Expected behavior
Detect the framework and run the appropriate generator CLI
Never hand-write migration file paths with invented timestamps
Never use round placeholders (120000, 000000, HH0000)
If multiple migrations are needed, generate them one at a time so timestamps stay monotonic