You run a Wagtail site, and you have been letting an agent help with it. Some days it handles a page-tree change well. Other days it wades through instructions about things that have nothing to do with the task. You have also noticed that the more guidance you give it, the more crowded its working memory gets. So when the Wagtail project published its official agent skills, you wanted to know whether this would make that worse.
The project announced them in a post titled Agent-friendly documentation for your Wagtail tasks. There are five skills. The API skill covers what the project calls "our new API to automate common tasks." The others cover the backend, content modeling (the page tree and StreamField blocks), the frontend, and upgrades. The project says the skills "focus on the expert knowledge needed to complete tasks, not the way specific tasks should be done, we leave that to you." That suits you, because your team has its own conventions and you don't want them overwritten.
The speed claim is modest, and it is the project's own. "On average, we see tasks complete on the order of 30% faster with the skills compared to without," across models. A fuller benchmark is due at Wagtail Space in November. Until then, treat the figure as a vendor claim, not an independent measurement.
The installation advice matters more than the count. You might expect to install all five files and let the agent sort them out. The project recommends against that. It suggests one evergreen Wagtail skill plus the Wagtail CLI. That evergreen skill is short, and it "will only trigger if Wagtail is involved." Once it triggers, it decides whether to load the backend or frontend skill, pulling "pre-bundled skills files and live developer docs as needed." The stated reason is that the team wanted results "without having to manage a plethora of skills or having them pollute context on other work." If your agent also edits a billing service or a build script, a Wagtail skill that stays quiet until Wagtail is involved is what you want.
There is one more detail you may like. The maintainers say they expect to retire some of this. In their words: "we'll want to unpublish some of our skills as we see them becoming less relevant with newer generations of models." Few projects plan for their own guidance to expire, and it tells you not to treat these files as permanent fixtures in your setup.
Now the turn, which concerns the APIs.io catalog and not Wagtail. When the catalog looked at its own record for Wagtail, it found the thinnest record of any project covered this month. The provider page has one API page, the Wagtail API v2, the read-only content API that has shipped with Wagtail for years. The new API the first skill covers has no page. Agent skills is unlit, because the skills live in a GitHub repository the record does not yet point at.
The scores follow from that. The Kin Score is 12.9, in the emerging band, with discoverability at 66.1 and contract quality and governance both at 0.0. The Agent Readiness score is 0.6, human-only, with only the rate limit signal lit. The catalog is careful about what this means. For an open source framework, the number reflects how little it publishes as a hosted service, not how well it supports developers. The post itself is evidence of the latter.
The catalog's own fix is plain. A pointer to the skills repository and a page for the new API would move the record more than any of its existing pages. Wagtail has shown how to keep skills from crowding out context. The record has not yet been told the skills exist.
What you take away is practical. Install the one evergreen skill and the CLI, not all five files. Take the 30% figure as the project's own until the November benchmark arrives. Plan on trimming the setup as models improve. And if you rely on a catalog score to judge a project like this, check what the score measures first, because a low number here says more about the record than about Wagtail.
Read the original: https://apis.io/2026/10/21/wagtail-ships-five-skills-and-one-evergreen-skill-to-load-them/