FastAPI now has official skills for usage with an LLM. I’m not advocating that Django do that right now, but I do think having a public discussion/sharing of these is useful both within the community and for newcomers who are becoming more and more used to doing software this way.
For anyone new to Skills, it is just a Markdown file. Here is the FastAPI’s one.
Thoughts? I’m open to pushback here. I also want Django to be seen as the modern web framework that it is and not quickly cast aside by the masses for not having more public marketing around AI patterns.
These LLMs are already extensively trained on these well known frameworks, adding Django specific skills will only bloat the sessions with repeated information.
Skills would only make sense to shape LLM behaviour to ways that the code base owner decided, such as what Django features he wants to use and which ones they explicitly don’t, ADRs, delegations etc etc
As someone who’s been building with Django for over a decade and is now building a startup on it, I think Django should seriously consider this.
One question: are you envisioning Skills for using Django, or Skills for contributing to the Django project itself? My understanding is they’re primarily local to the project being worked on, so I’d expect them to be more about helping contributors navigate the Django codebase and follow project conventions.
Either way, I’d much rather see the Django community define canonical guidance than let every model piece it together from random blog posts and GitHub repos. It feels like a natural evolution of the project’s documentation, not chasing hype.
I wonder if some skills would be useful to counter some common footgun’s in Django, or a slightly more formal manner of some of the patterns that haven’t ever made it into the docs & code, but could perhaps have a place in Skills which could be iterated on more quickly?
This could be split for specific areas (eg deploying Django) or user types (beginners vs contributors) etc.
I guess I see Skills as a place for opinions to be codified, but this would likely be at odds with having these Skills in Django itself.
I’d like to see skills for building with Django. I know myself and a few colleagues have had a lot of success with it.
True, but there’s benefits from building a skill with opinions vs. the blast radius of what has been compiled from the Internet. I think Django beneftis from billions of conversations, examples, articles, lines of code, etc. which makes it exception to build with an LLM, but there is room for a good starting point of opinions imo.
In case it’s useful, the DSF Board approved/blessed the AI research working group which hasn’t quite gotten off the ground. If anyone has strong opinions, it might be the right WG to join and help get moving forward.
I agree it’s mainly about codifying opinions. I also think “if” there is some consensus beyond the best practices on djangoproject.com, having such a document would help future LLMs perform better.
It could be worth having some info on writing queries: In general favouring operations that return QuerySets, such as .filter over those that return a single item (like .get) keeps queries composable and avoids one of the default ways that database accesses become unoptimised ( .get in side a loop that is fed back into a query, resulting in ping-pong between python+database).
I’m in support of this. I feel like I’ve watched the Django community grow in recent years from people sharing opinions about best practices in Django that go beyond the documentation. Some of those are strong personal opinions based on one person’s experience, some of those are clearly shared collective best practices.
As a relative Django newcomer, I’m in hefty support of this. Django is “batteries included” and that should include the batteries to work in new agentic workflows. Reemphasizing best practice patterns as they change between versions would be a big win.
As well, for folks who seek to contribute to the library or introduce a new third party library this can reduce the barrier to entry for getting something even somewhat viable to reviewers’ eyes.
Who best to chart a skill than representatives of the community themselves?
Within my personal development experience, having even my local skills file has helped catch minor hiccups during rapid prototyping, so I can only imagine having a dedicated skill could only add to that refinement.
Django is a canonical framework and there should ideally be one way to do things, which includes having this. People can override/change it as they like, but it just adds some robustness and challenges us to even further define what good looks like.
The trouble with “official” is it’s waiting for somebody to do it, and that somebody doesn’t exist.
There are people in the community who are more involved in using AI than others. Those people need to put out theirs. (The people who are less involved are unlikely to do it.)
We need to see the blog posts, the gists, the packages even, if that’s the right scale for these things… — it might be a bit much for a markdown file.
To paraphrase Elvis, Less forum posts, more action!
Maybe this is all just me and @jeff by proxy saying, please write up and share how you are using skills with Django. We’d love to feature stuff in the Django News Newsletter (hint, hint).
So I went ahead and published a repo with Django Skills. Explicitly based on Django docs. Nothing really custom in here. It’s a first step. People are welcome to fork/tweak as they like.
I wonder if we should add a section on awesome-django or something for skills? Not that I’m eager to curate another thing, but someplace for skills with some community weight might be useful.
What do people think? @carltongibson close your eyes to this further discussion.
I think it’d be great to add. I suspect we could add a milktoast version by default, but have it use templating similar to how new projects can be configured to allow others to plug and play their preferences while still maintaining the basics.
I haven’t used it myself though since I typically just tailor the agent based on what I want via prompts and it picks up what the project already has done.
I like the idea of having an official starting point. Even a lightweight default would help people avoid repeating the same setup for every project, while still leaving room to customize it for different workflows and coding styles.
My hot (?) take as an individual whose team has both experienced and novice levels of experience when it comes to Django: the content of these skills should be largely confined to footguns (as @nanorepublica suggests) or outdated information. I think FastAPI’s is actually a useful reference in this regard:
Everything/anything else should be in the same surface that a human might digest (docs/readme/etc.) To wit, our language-specific skill for Django has been whittled down to two pointers:
I agree. I think if we make it very vanilla and small like FastAPI but at least have “something” it will help agents and developers used to skills-first development. Having nothing just speaks the marketing challenges Django already faces, imo.
