Building new modules using AI
I am setting up a playground to experiment with AI. My last post discussed developing and contributing a new Entity/Field Labels module to Drupal using AI. I look forward to seeing what I can create next. Before moving forward, I want to pause and explore how AI can assist me in managing and maintaining my existing contributed modules.
Maintaining my contributed modules using AI
Over the past decade, I’ve created and managed numerous contributed modules. I'm not sure how many there are, and it's been challenging to keep them all up to date. In the long run, I believe an AI agent with the right skills could help me manage my overwhelming list of modules. First, I need to clone my modules into my local development environment.
Cloning my contributed modules via Composer
It's unrealistic for me to manually clone each module's repository. Fortunately, Composer supports Git repositories. However, setting up and testing each module's Git repository using Composer can still be very time-consuming. Since AI excels at repetitive, predictable tasks, this is a perfect opportunity for me to let my AI assistant step in and make my life easier.
Using Agent skills to make things easier
Since cloning a Drupal repository for local development is quite straightforward, this presents a great opportunity to develop a custom agent skill. As with many AI-related tasks, it's best to seek help from the AI. Therefore, I prompted Claude to assist me in planning my drupalorg-project-clone skill.
Here is the front matter description of my new drupalorg-project-clone skill, which was generated by Claude Code and Codex.
Clone a single Drupal.org project by machine name (module, theme, or recipe) as a git repository into composer.json or composer.sandbox.json for local contribution work. Use when you already know the project machine name. Fetches Drupal.org git-instructions to determine the correct branch, resolves project type before installing, follows the local repo's Composer conventions, and swaps packaged releases to git-backed dev branches when needed.
Adding a dozen repositories to one's composer.json file makes it harder for humans to review dependencies. Of course, AIs have no trouble tracking a large composer.json file. To help humans manage a big composer.json that may include dozens of git repositories for modules, recipes, and libraries, I've found that the Composer Merge Plugin is an ideal tool for splitting a project's composer.json into multiple sub-files.
Organizing my composer dependencies using the composer merge plugin
I started using the Composer Merge Plugin to isolate the Webform module's external libraries in a dedicated composer.libraries.json file. Over the years, I've added a few other composer sub-files to my local Drupal development environment. I use composer sub-files to organize dependencies by type (libraries, recipes, and sandbox) and by status (deprecated or lenient).
Below is a complete list of the composer sub-files I am currently using.
`composer.recipes.json`: Used to store Drupal recipes.
Generally, this file keeps track of the recipes that have been installed.
`composer.sandbox.json`: Used to store contributed modules I'm working on.
These modules are being cloned and developed in my local environment. All listed modules are cloned to the /web/module/sandbox and /web/themes/sandbox directories.
`composer.deprecated.json`: Used to track custom modules that have been uninstalled from Drupal and should now be removed from Composer.
Fully removing a module involves two steps: first, the module is uninstalled during a deployment, and once uninstalled, its Composer dependency can be deleted. For projects with bi-weekly releases, this file ensures we don't forget to remove the dependency after uninstalling a module.
`composer.lenient.json`: Used to track modules that need to be upgraded to the next version of Drupal.
What I like about this file is that I can start a major Drupal version upgrade, track which modules haven't been upgraded, and use `mglaman/composer-drupal-lenient` with a patch from Drupal.org to monitor and test the module's upgrade status. If I am not ready to completely switch to the next version of Drupal, I will simply remove the reference to this file from my `composer.json`.
Crafting a skill that saves me a massive amount of manual work
My new drupalorg-project-clone skill only clones one repository at a time. I really want to clone the repositories for every project I'm actively maintaining. Instead of assuming a single custom prompt can clone every repository, it's safer to ask the AI to show its plan before executing. I created a second skill, drupalorg-projects-clone, to find all projects for a given Drupal.org user, ask which projects should be cloned, and then clone all related projects.
Using two agents is better than one
I'm not yet confident that Claude Code will successfully clone all my contributed modules. From my past experience, I learned that I don't have to rely solely on Claude Code; I can also use Codex as an alternative coding assistant or code reviewer. Claude Code has developed a fully functional skill, and I wanted to see if Codex could help improve it. As I expected, by leveraging two very capable junior developers, Codex identified some discrepancies and added clarity to both skills.
Adding modules to my playground
I'm increasingly less surprised by what AI can do, but I still had an aha moment when Claude returned the list of every module I've contributed to Drupal.
I've spent a whole post explaining how I cloned and organized my contributed modules. Next, I need to start using AI to help me maintain them. I am optimistic that AI can immediately improve test coverage, documentation, deprecation fixing, and planning for most of my modules.
I also hammered Drupal.org with some additional bot traffic
It is definitely worth noting that my drupalorg-project-clone skill repeatedly accessed Drupal.org's API and webpages to retrieve metadata. As I observed Claude working, I expected Drupal.org's CDN to block the persistent traffic through rate limiting. Surprisingly, Drupal.org managed the extra load without any issues. If the Drupal.org infrastructure were to become overwhelmed, I would prompt Claude to update the skill to throttle requests and respect rate limits.
Truth be told, I see more value in the ability to clone a single project by name than in cloning all a user's projects. At the same time, I think it is important to promote the tools on Drupal.org that help people see the potential of agent skills.
Help the Drupal community create agent skills
There is a lot of activity in the Drupal community around AI, and after DrupalCon Chicago, the AI Best Practices for Drupal project was launched. Everyone is at different stages of their AI journey. If you've developed some skills that you think the Drupal community could benefit from, get involved. If you're curious to see what skills the community is building, please give them a try.
It's completely okay to develop personal skills from the ground up or build on existing ones as starting points. It definitely feels a bit like the wild west or Star Trek, depending on your view of AI. Still, writing this section reminded me to make sure my Drupal (AI) Playground includes my GNU `LICENSE.txt`, so feel free to use my drupalorg-project-clone skill to clone the ai_best_practices repository and contribute something back to the community.
Takeaways
AI is a tool to assist with coding, just as Composer is a tool for managing PHP packages. In this post, I hope readers find my method for organizing and managing Drupal projects with the Composer Merge Plugin useful. Developing skills is definitely worthwhile, both individually and within our community, as we navigate working with AI.