An agent skill to start new Django projects, or extend the one you already have.
A skill that gives your coding agent current Django knowledge. Tell it what you are building; it asks a few questions, then writes the project. Packages are wired together, dev and prod settings are split, and CI is 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 5 + seedkit | Fable 5, no skill |
|---|---|---|
| 01-minimal-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-orbit-demo | 8/8 | 3/8 |
| 06-silk-lab | 8/8 | 6/8 |
| 07-vps-sqlite-saas | 8/8 | 7/8 |
| 08-fly-app | 8/8 | 7/8 |
| 09-ssh-deploy | 8/8 | 7/8 |
| total | 72/72 | 54/72 |
The other two control arms cover part of the set: Sonnet 5 with no skill scored 33/48 on six cases, Opus 5 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.
The results above come from Claude Sonnet 5, Opus 5 and Fable 5. The test harness now targets Sonnet 5.5, Opus 5.5 and Gemini 3.8 Flash, and the numbers will be re-measured on them. Other models (Haiku, GPT) and the deploy targets (VPS, Fly, GitHub-SSH) are wired up but less traveled.
- Hit a bug or something odd? Open an issue. Even a one-line "this broke" helps. A report goes into a reference file, and every later run gets the fix.
- Run it on another model. Cross-model coverage is what we need most. Point
train/run-tests.shat Haiku, GPT, or another Gemini and share the logs. - Anything bigger: open an issue first so we can talk it through. A full test cycle takes a couple of hours, so it is worth saving each other a wasted run.
Recent changes are in the CHANGELOG.
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?