An agent skill to start new Django projects or extend existing ones. One sentence in, a running project out. It wires packages together, splits dev and prod settings, and adds CI.
/seedkit SaaS landing + waitlist, GDPR-friendly stack (mail, analytics, error reporting), VPS deploy
/seedkit add proper auth — magic link, lockout on brute force, optional 2FA
/seedkit look at our repo and tell us what's worth adding next
LLMs write Django from memory. That memory is a year or two old. Think deprecated auth settings and last version's Stripe webhooks. Or database ports open to the local network. seedkit keeps that knowledge in maintained reference files instead. We build the files from package docs. We test them end-to-end and fix every failure. The model types.
What you get:
- Current APIs, not model memory. References come from package docs; version pins re-resolve at generation time. Nothing goes stale the way an unmaintained starter template does.
- Tested output. Nine end-to-end scenarios: generate, boot, smoke-check, audit by a second LLM (see the outputs). We fix every failure back into the skill.
- Works on the project you already have. Generators only start from zero.
/seedkit add [feature]wires a new package into a live repo: deps, settings,.envexample, the CI step. - Your exact stack, not a preset. 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.
- Plain Django, no lock-in. The output is a normal Django project you own. No wrapper library, no runtime dependency on seedkit, nothing extra to upgrade later.
- Skip the generate–boot–fix grind. The references distill 100+ hours of those cycles, so scaffolding runs clean on mid-tier Sonnet. Your frontier-model hours go to the code only you can write.
Helps you with:
- Setup & config: Python deps & venvs, settings for dev vs prod, custom user model.
- Auth: social & password login, passwordless magic-link login, brute-force protection.
- APIs: typed REST endpoints, Rust-powered high-RPS APIs, CORS headers.
- Billing: Stripe payments & subscriptions.
- Async & caching: background jobs, scheduled tasks, async views, WebSockets, Redis caching.
- Storage & email: S3 for static & media, outbound email.
- Frontend & SEO: Tailwind without Node, meta tags & sitemap, translations, GDPR-safe analytics.
- Security: security headers, CSP headers, production 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.
One prompt like the first produces 07-vps-sqlite-saas: Docker + Caddy deploy, Sentry, Litestream backups, CI.
/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:
/seedkit
Each failure the test scenarios surface becomes a reference fix, so each release scaffolds better than the last.
Verification runs on Claude Sonnet today. Other models (Opus, Haiku, GPT, Gemini) and the production 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.
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.
- Run it on another model. We verify on Claude Sonnet. Point
train/run-tests.shat Opus, Haiku, GPT, or Gemini and share the logs; cross-model coverage is what we need most. - Read the output before you trust it. It boots and passes smoke checks, but hasn't seen production. Your review is part of the loop.
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?
