🇬🇧 I stopped using AI as a chatbot. Here's the system I built instead for Drupal teams.
I kept seeing the same mistakes in code reviews.
Dependency injection done wrong. \Drupal::service() called inside classes. No cache tags. SQL concatenated directly into queries. Hook implementations still written the old procedural way — function mymodule_node_presave() — when Drupal 11 introduced OOP hooks with the #[Hook] PHP attribute. The same patterns, the same anti-patterns — review after review.
The developers weren’t careless. They were using AI coding agents to move faster. The agents just didn’t know Drupal well enough. They were trained on older patterns, outdated documentation, and codebases that hadn’t caught up with Drupal 11.
That’s when I realized the real problem wasn’t the AI. It was the lack of structure around it.
What I found in the Drupal community
When I started looking at how other Drupal teams were approaching this, I found exactly what I expected: everyone doing it differently.
Some teams had a massive single prompt they’d paste at the start of every session. Others had nothing — just vibes and hope. A few had started building something more structured.
Two projects stood out.
skills.sh/madsnorgaard/drupal-expert — impressive in scope, genuinely well thought out. But the problem is size. When a coding agent picks up a skill that large, it consumes a massive amount of tokens on every invocation. That’s not sustainable on real projects. You’re paying for context you don’t always need.
skills.sh/grasmash/drupal-claude-skills — great concept, the right instinct. But the documentation wasn’t being maintained. Drupal moves fast. Drupal 11 has OOP hooks with the #[Hook] attribute. Standards evolve. Outdated skills produce outdated code.
Both pointed in the right direction. Neither was the system I needed on production projects.
The gap I couldn’t ignore
Here’s what I noticed beyond those two projects: Drupal’s own coding standards, Doxygen documentation, and core examples weren’t keeping up with how agentic tools actually work.
No one had built a series of skills that were:
- Focused and modular — small enough to load only what you need
- Up to date — reflecting Drupal 11 patterns, not Drupal 7 muscle memory
- Tested — not just written, but actually verified by running the prompts against Claude Code and confirming the skill gets picked up correctly
- Human-readable — with a proper README that explains not just what the skill does but when to use it and why
That last point matters more than people think. A skill that only makes sense to the person who wrote it isn’t a team asset — it’s a personal shortcut.
So I decided to build the first series of Drupal AI skills designed from the ground up for this. Modular. Current. Tested with real prompts against Claude Code Opus. Documented for humans.
How it grew
I started with skills. Thirty-plus of them, each covering a specific domain: dependency injection, caching, security, entity API, hooks, migrations, Twig, testing, routing, queries.
Then I asked myself: skills tell the AI what to know. But what about how to behave?
That’s where rules came in. Files that enforce non-negotiable standards: prefer DI over \Drupal::service(), use phpcs.xml as the source of truth, no SQL concatenation, document hook implementations with @see references. Not suggestions — constraints. Applied automatically to every task.
Then commands. Because a lot of what senior Drupal devs spend time on isn’t writing code — it’s the workflow around it. PR reviews. Updating status in GitHub. Syncing with Jira. I built commands to automate that layer too.
And then someone pointed out the obvious: not everyone uses Claude Code. Some teams use Codex.
So I added .codex support. Created the structure, documented the manual steps to set up a symbolic link, tested it — and it worked. Codex picked up the skills the same way.
The system had grown into something I hadn’t planned from the start. That’s usually a sign you’re building something real.
Why I believe this matters
I’ve spent a lot of time thinking about this and my position is clear:
AI multiplies delivery — but only when code quality is at its highest standard.
A fast AI that produces mediocre code doesn’t make your team faster. It makes your tech debt faster. The velocity is real, but so is the cost if you don’t have guardrails.
That’s why I took the time to do this properly. Not to ship something quickly, but to build a foundation the Drupal community can actually rely on.
I’ve seen developers use these tools to contribute to open source projects. To deliver client work. To move fast on features that used to take days. The code coming out of those sessions is only as good as what the agent was given to work with. With Drupal AI, the idea is that by the time a PR lands for review, the common mistakes are already gone — because the agent that wrote it already knew not to make them.
What I’m building toward
The vision I keep coming back to is simple: a single prompt that builds an entire Drupal site. Agents that do the architecture, the module structure, the configuration, the tests — without requiring a human to supervise every step. And the output is still the best Drupal code possible, following every standard, every best practice.
We’re not there yet. But the path goes through exactly this kind of work — building the knowledge layer that makes agents trustworthy enough to run unsupervised.
Drupal AI is an open contribution to that path.
Explore it
Everything is open source and available now.
👉 See the full project architecture at eduardotelaya.com/drupal-ai
👉 Browse the skills, agents, rules, and commands on GitHub
Use it. Fork it. Adapt it to your project. Or just use it as a reference for building your own system.
And if you’re working on something similar in the Drupal space — I’d genuinely like to know. The community benefits more when these efforts connect than when they stay isolated.
