django-seedkit

How this skill works

Two paths:

• New project (empty dir, only .git/ or stub README): run §2 → §8 in order.
• Existing project (has pyproject.toml and Django code): skip §2–§4. Read references/existing-project.md for the inventory workflow, then jump to §5/§6 and ask only about missing components.

Before either path, run uv --version to confirm uv is installed (references/uv.md).

Every question below names the reference that answers it — read that one file before applying the step, and no others.

For every question that involves a third-party package: 1–2 sentences from the reference's intro on what it adds beyond stock Django, then ask. none (or no) is always a valid answer.

Use answers already given. Before asking any question, scan the user's initial request (and anything they've said since) for the answer. If it's there — explicit ("use PostgreSQL", "with Celery", "no auth") or unambiguous from context — take it as given, note the decision in one line, and move on. Don't re-ask to confirm. Only ask when the answer is genuinely missing or ambiguous.

Preflight — read these before the first tool call of a new-project run: references/new-project.md, references/database.md, and references/conventions.md (the cross-file contract: env var names, Redis DB map, prod compose service shape, SameSite rule, Python pins).

Instructions

1. Open the conversation

Name the groups you'll walk through — Project Foundation (§2), then Developer Experience, Auth & Accounts, Data & Storage, Background & Email, Frontend & Site Basics, SaaS / Product, Real-time (§5.1–5.7), then Production & Deploy (§6) — one sentence each. For existing projects: first follow references/existing-project.md and note what's already detected per group. Invite the user to begin.

2. Project Foundation — new projects only, one question at a time, in order

1. Project name + one-line purpose (the explicit two-answer pair).
2. Settings layout: single settings.py or split base/local/production. → references/new-project.md
3. Database: SQLite or PostgreSQL. → references/database.md
4. Request handling: wsgi / asgi / asgi+channels. Default wsgi. Decide now — Dockerfile CMD, server choice, and the manage.py/wsgi.py/asgi.py settings defaults all hinge on this; switching later means rewriting deploy artefacts. See references/async.md (and references/realtime.md for the channels mode).
5. If Postgres: host Postgres or Postgres-in-Docker (docker-compose.yml for the local services). SQLite users skip. → references/docker.md
6. If the project has a docker-compose.yml (from step 5): dev loop — manage.py on the host via uv run, or in a web container via docker compose. Default host. → references/docker.md
7. Custom user model: yes / no — decide now (see references/custom-user.md).