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.
AI Place Hub
44
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
It works as .cursorrules, as a Copilot instructions file, or pasted into a project system prompt. Only the filename changes. The query-in-a-loop line catches the N+1 problem that assistants write over and over in Django templates.
For information only, not professional advice. You use it at your own risk and we are not liable for any loss or damage. See the disclaimer.
Tagged