Editor rules for a Django project
A rules file that pins the Django and Python versions, the app layout and the things an assistant should never regenerate.
Django 5.0, Python 3.12, PostgreSQL. Poetry for dependencies.
Layout: apps live in apps/<name>/ with models.py, views.py, serializers.py, urls.py. Shared code in core/.
Rules:
- Use Django ORM. Raw SQL only where the ORM genuinely cannot express the query, and add a comment saying why.
- Every model change needs a migration. Generate it, never hand-edit an applied one.
- Views are class-based and thin. Business logic goes in apps/<name>/services.py.
- Settings come from environment variables through django-environ. Never hardcode a secret, a host or a key.
- Use select_related and prefetch_related where a template iterates a relation. Flag any query inside a loop.
- Tests with pytest-django in apps/<name>/tests/. A new endpoint needs a test.
Do not:
- Add DRF viewsets to an app that does not already use them.
- Change settings/base.py without saying so explicitly.
- Introduce Celery, Redis or a cache layer without asking.Notes from the author
Works as .cursorrules, as a Copilot instructions file or pasted into a project system prompt - the format is only a filename. The query-inside-a-loop line catches the N+1 problem that assistants generate constantly in Django templates.
Tagged