Making WordPress.org editing radically faster


It is Radical Speed Month at Automattic. As such, my co-workers and I have the ability to work on passion projects and things we feel will make a really large impact. Below is my project.

WordPress.org powers a huge chunk of the open web. It has been built and improved over more than two decades by hundreds of contributors, which means it has a lot of moving parts: multiple repositories, multiple deploy paths, sandboxes, and the kind of layered infrastructure that comes from a project that has been actively worked on for that long. Even folks who have been working on it for years can find some of it confusing.

That complexity creates real onboarding overhead for anyone trying to make a change. Recently, Matt Mullenweg assembled a trusted group of contributors to help overhaul WordPress.org. The work matters, and the people doing it should not be slowed down by setup time.

So I built a Claude skill called wordpress-org-editor that compresses the wp.org learning curve from weeks of part-time exploration into about 30 to 45 minutes of guided onboarding. After running through it once, anyone with a sandbox can ask Claude in plain English to ship a change to WordPress.org and get a working result the same day.

I was always a super mediocre developer. With Claude as my partner in crime, I am able to ship things to WordPress.org in minutes that used to take me days or weeks of bumbling. The first thing I shipped using the skill was an llms.txt file at wordpress.org/llms.txt to help AI crawlers and agentic browsers understand the site’s structure. It shows up on my WordPress.org profile as a real commit, which still feels a little surreal. I want everyone in the trusted group to have that capability.

How testing has gone

Seven people have helped get the skill to where it is, either by answering my questions and sharing their knowledge, running through the onboarding flow as friendly testers and finding bugs, or using it to ship real changes:

  • Dion Hulse has been instrumental in pointing me to the right documentation and helping me understand some of the very difficult parts of WordPress.org’s infrastructure. I am thankful for the time he has spent answering my questions and sharing his knowledge.
  • Barry Abrahamson shared his deep institutional knowledge generously, answered many of my questions, and helped me unblock several steps that were originally manual and are now fully automated in the skill.
  • Berislav Grgičak walked through the full onboarding and surfaced a series of issues (Composer audit failures, empty plugin directories, Docker build cache problems) that became the troubleshooting reference docs.
  • Anne McCarthy completed onboarding and provided steady edge-case feedback that sharpened the setup flow.
  • Rich Tabor completed onboarding and shipped a real PR (global header and top-nav menu updates) the same day he finished setup. That was the moment the skill went from “personal experiment” to “tool other people can use.”
  • Matt Mullenweg worked through onboarding, hit a stack of real bugs that became the rest of the troubleshooting reference, and shipped updates to the WordPress book page on April 17 using the skill.
  • Mary Hubbard shipped the May 6 content-editor sync for the Requirements page and, in the process, surfaced a documentation gap about the block-theme deploy flow that produced the most recent set of corrections to the skill.

I am grateful to every one of them.

Availability

I am making the skill available to members of the trusted group Matt has assembled. If you are in that group and want access, find me in the #meta-janitors channel on the WordPress Slack.

For everyone else, the skill requires a WordPress.org sandbox, so it is not generally installable. That said, if you have ideas about how AI tools could change developer onboarding for big open-source projects more broadly, I would love to hear them.

What’s next

The skill keeps improving as people use it. Each new bug becomes a fix in the canonical version. Each new contributor adds capability to the group.

Beyond WordPress.org, I am thinking a lot about how this pattern (encoding tribal knowledge into Claude skills so onboarding gets faster and the group gets bigger) could apply to all kinds of complex systems. WordPress.org is just my proof of concept. The real win is showing that small, focused skills can compress months of “you have to be here a while to figure this out” into a guided afternoon.

If that resonates with you, drop me a note. There is more to do.


One response to “Making WordPress.org editing radically faster”

  1. […] WordPress.org editing radically faster, by James […]

Leave a Reply

Discover more from James Grierson

Subscribe now to keep reading and get access to the full archive.

Continue reading