What this prompt does
This prompt frames the model as a senior Django engineer and demands working code and real config -- structured so you can drop it into a fresh repo, not pseudocode. You supply [resource], [auth_model], and [deploy_target], and it returns a full Django 5 + DRF project: environment-split settings, viewsets and serializers, auth with throttling and caching, pytest-django tests, Docker, and migrations.
The structure works because it forces the parts teams skip. [resource] defines the viewsets, serializers, and object-level permissions, so the API is built around your real domain. [auth_model] sets whether you get token or JWT auth and how scoping works. [deploy_target] shapes the Dockerfile, gunicorn, and whitenoise setup. By making throttling, env-based settings, and real tests explicit deliverables, the prompt produces a production shape rather than a tutorial CRUD app. The base/dev/prod settings split also keeps secrets out of code and lets you tune behaviour per environment without editing application logic.
When to use it
- You're starting a Python-first SaaS backend and want a production Django + DRF skeleton.
- You need environment-split settings reading secrets from env vars, not a single settings file.
- You want object-level permissions and per-user/per-anon throttling wired from the start.
- You need pytest-django tests for CRUD, auth failures, permission denials, and throttle limits.
- You want a Dockerfile, gunicorn, whitenoise, and docker-compose for local Postgres.
- You need migrations, a seed command, and a README of run commands ready to go.
- You need a seed command and a README of run commands so a teammate can boot it fast.
Example output
You get a file tree first, then the contents of each key file in fenced code blocks: the split settings, the DRF viewsets/serializers/permissions for your resource, the auth and throttling config, the pytest-django tests, the Dockerfile and docker-compose, and the seed command plus README. It's organized so you can recreate the repo file by file and run it locally, rather than stitch fragments together from an outline.
Pro tips
- Describe
[resource]with its relations (blog posts with authors and tags) so the serializers and permissions model the real shape. - Pick
[auth_model]deliberately -- token vs JWT changes the auth flow and the scoping the prompt generates. - Set
[deploy_target]accurately (Docker on a single VPS behind Nginx) so the Dockerfile and gunicorn config fit where it runs. - Wire throttling and its test (deliverables 3 and 4) first; it's the cheapest insurance against abuse on a public API.
- Ask the model to apply caching only where it's safe so you don't accidentally cache per-user responses globally.
- Run the generated pytest suite immediately; failing auth and throttle tests surface misconfiguration before deploy.
- Keep the seed command idempotent so re-running it against local Postgres doesn't duplicate fixture rows.
