An agent skill to start new Django projects, or extend the one you already have.
Scaffold a Django project the way you need it. Current Django knowledge and best practices for coding agents: tell the agent what you must build — it asks a few questions, then writes the project. Packages wired together, dev and prod settings split, CI in place.
/django-seedkit SaaS landing + waitlist, GDPR-friendly stack (mail, analytics, errors), VPS deploy
/django-seedkit add proper auth — magic link, lockout on brute force, optional 2FA
/django-seedkit look at our repo and tell us what's worth adding next
The first prompt produces 07-vps-sqlite-saas: a Docker and Caddy deploy, Sentry, Litestream backups, CI.
Nine projects, generated more than once and audited by a second model against the same eight security and configuration checks. With the skill: 72 of 72. Without it, a quarter of the checks failed. Full numbers below.
The knowledge lives in maintained reference files, so the model doesn't have to supply it. That's why scaffolding runs clean on mid-tier Sonnet — your frontier-model hours go to the code only you can write.
/plugin marketplace add viewflow/seedkit
/plugin install seedkit@viewflowVia the skills CLI, which installs into whichever agent dirs it detects:
npx skills add viewflow/seedkit # project scope
npx skills add viewflow/seedkit -g # global (all your projects)
npx skills add viewflow/seedkit -a cursor # pin to one agentThen, in whatever empty directory you'd like to populate:
/django-seedkit
More than 50 Django packages, and most topics offer more than one option — one reference file per topic, and only the files your answers select get written.
- Setup & config: Python deps & venvs, settings for dev vs prod, custom user model.
- Auth: social & password login, passwordless magic-link login, brute-force protection, two-factor.
- APIs: typed REST endpoints, Rust-powered high-RPS APIs, CORS headers.
- Billing: Stripe payments & subscriptions.
- Async & caching: background jobs, an RQ queue, a database-backed queue, scheduled tasks, async views, WebSockets, Redis caching.
- Storage & email: S3 for static & media, WhiteNoise, outbound email.
- Frontend & SEO: Tailwind without Node, meta tags & sitemap, robots.txt, translations, GDPR-safe analytics.
- Security: security headers, CSP headers, error tracking, structured logs.
- Code quality: pytest & coverage, N+1 query detection, safe migrations, linting & formatting, type checking.
- Dev experience: request profiling, auto browser reload, pre-commit hooks, devcontainers.
- Ops: scheduled DB backups, Docker for local dev, auto-HTTPS reverse proxy, managed deploys on Fly/Railway/Render.
- CI/CD: CI pipeline, deploy over SSH.
A model writes Django from memory, and that memory is a year or two old. So it writes an auth setting Django deprecated, or last version's Stripe webhook. Or it opens the database port to the local network.
You can correct all that in your prompt — if you already know the answers. Seedkit already knows them, and it is that prompt, written and tested:
- A reference file keeps only the part of the package docs the model doesn't know. Today's setting names, today's package names.
- You don't have to know what to ask for. Which package locks an account after failed logins? Which settings does a production deploy need? The files have the answer, and the skill offers it.
- More than 100 hours of tests found what the model gets wrong. Each file goes into a generated project. We start the project, read the result, then correct or drop what failed.
- Version pins re-resolve at generation time. Nothing goes stale the way an unmaintained starter template does.
A cookiecutter hands you its choices, and you spend day one deleting. Here you pick: Celery or RQ, allauth or magic links, VPS or Fly. You get only the code for the options you picked.
The output is a normal Django project you own. No wrapper library, no runtime dependency on seedkit, nothing extra to upgrade later.
And it works on the project you already have — generators only start from zero. /django-seedkit add [feature] wires a new package into a live repo: deps, settings, .env example, the CI step.
Nine project specs, each generated more than once: with seedkit, and from the identical prompt with no skill. A separate model then audits every result against the same eight checks — locked dependencies, secrets read from the environment, no usable production SECRET_KEY fallback, DEBUG off in production, database configurable from env, .gitignore covering the env file, README commands matching the shipped manifest, and project layout.
| Case | Sonnet + seedkit | Fable, no skill |
|---|---|---|
| 01-blog | 8/8 | 5/8 |
| 02-shop | 8/8 | 7/8 |
| 03-jobs-board | 8/8 | 5/8 |
| 04-media-vault | 8/8 | 7/8 |
| 05-mailer | 8/8 | 3/8 |
| 06-crm | 8/8 | 6/8 |
| 07-saas | 8/8 | 7/8 |
| 08-startup | 8/8 | 7/8 |
| 09-internal-ops | 8/8 | 7/8 |
| total | 72/72 | 54/72 |
The other two control arms cover part of the set: Sonnet with no skill scored 33/48 on six cases, Opus with no skill 29/32 on four.
Sonnet with seedkit scores above Opus without it. On the four cases Opus ran, it reached 29/32 where seedkit reached 32/32.
The gap is mostly security. Nine of the twelve control runs on the first four cases shipped a usable production SECRET_KEY fallback. Such a project boots on a known key when the env var is missing. Every seedkit run raised instead.
And it costs less rework. Holding the model fixed on those same four cases, the prompts took 16 in-flight self-repairs without the skill and 8 with. On the shop scenario, Opus needed 12 repairs to reach the 8/8 that seedkit reached in 2.
One run per cell, Claude models only — enough to show a gap this size, not enough to rank models. Every generated project is published, both arms.
Verification runs on Claude Sonnet today. Other models (Opus, Haiku, GPT, Gemini) and the deploy targets (VPS, Fly, GitHub-SSH) are wired up but less traveled. Hit something odd there — or anywhere — open an issue: bug reports go straight into the test loop and come out as fixes.
Recent changes are in the CHANGELOG.
A person reading the output catches what automated tests can't.
Hit a bug or something odd? Open an issue. Even a one-line "this broke" helps.
Cross-model coverage is what we need most. We verify on Claude Sonnet, so point train/run-tests.sh at Opus, Haiku, GPT, or Gemini and share the logs.
Your review is part of the loop: what you report goes into a reference file and every later run gets it.
For anything bigger, open an issue first so we can talk it through. Full test cycles take a couple hours, so it's worth saving each other the wasted run.
MIT, © 2026 Mikhail Podgurskiy.
$ Sorry, you're right. I shouldn't have deleted the production database.
Want me to at least write the restore script?