I build WordPress plugins on my own, and I started using Claude Code for the obvious reason: to write code faster. Six months later, the part it actually saved me wasn't the code at all. It was everything around the code.
Every release, I ran the same small gauntlet. Bump the version, update the readme, write the changelog, check the translation files for gaps, draft the announcement. None of it is hard. All of it is fiddly, and every one of those chores pulled me out of the part of my brain that was actually building the thing. By the time I'd finished the release ritual and came back to code, I had to reload the whole mental context I'd just dropped.
That reload is the real cost, and it took me a while to see it. The chores don't just eat their own time. They evict the code from your head, and you pay again to bring it back. So I started handing the chores to Claude Code instead of the code, and that was the version that worked.
The chore that breaks releases silently
The one I least wanted to get wrong is version mismatch. In a WordPress plugin, the displayed version comes from the Version header in the main PHP file, but the readme's Stable tag points at which tagged version is "stable." They are two separate fields with two separate jobs, and when they disagree, updates can reach users wrong. No error fires. You find out from a bug report.
This is a perfect chore to hand off, because it's pure checking, no judgment. I keep the steps in a file and have Claude Code run them before every release:
- does the main file
Versionmatch the intended release - does the readme
Stable tagpoint at the right thing - is the top changelog entry actually this version
- is
Tested up totracking the current stable WordPress, and not set higher than it should be
The important half is the instruction I attach to it: surface mismatches, don't fix them. Show me the file and line, and let me make the call. I don't want the convenience of auto-correction on the one step where a wrong guess ships to users.
I stopped writing the prompt and made it a command
The version check is identical every single time, so writing the prompt by hand each release was its own small chore. I moved it into a reusable command.
Worth knowing if you're on a recent Claude Code: custom slash commands got merged into Skills back in the April update. The old .claude/commands/ files still work, but the current home is .claude/skills/<name>/SKILL.md, which gets you the same /name invocation plus the option of Claude calling it on its own when the context fits.
Mine looks roughly like this:
---
name: release-check
description: "Check a WordPress plugin's version and readme consistency before release. Use right before shipping."
allowed-tools: Read, Grep, Bash(grep:*)
---
# Release check
Verify before release:
1. main PHP Version header vs readme Stable tag
2. top changelog entry is this version
3. Tested up to tracks current stable, not above RC
Report mismatches as file + line. Do not edit. The human decides.
Two things earn their place here. The allowed-tools line scopes it to reading and grep, so a check can't quietly turn into an edit. And the description says when to use it in plain terms, which is what lets Claude reach for it at the right moment instead of guessing. Now the whole thing is /release-check and I never retype it.
Turning developer noise into user-facing notes
The other recurring time sink is the readme and changelog. WordPress readmes use their own markdown subset with a fixed shape, so turning a pile of commits into the right section is well-suited to a model, as long as you keep it honest.
I hand it the commit range and ask for a draft:
git log --oneline v1.9.2..HEAD
Then: rewrite these as a user-facing changelog, keep the format, and where a number or detail isn't certain, write (to confirm) instead of guessing. That last rule matters more than it looks. Left alone, a model fills every gap smoothly, and smooth is exactly what hides the spot you needed to check. Forcing it to leave the uncertain parts visibly blank means I catch them.
The translation step works the same way: I have it diff the .pot against each .po and list only the untranslated strings, no translating yet. See the gap first, decide second. Same shape as the version check: show me the state, don't act on it.
One small landmine I hit once: WordPress readmes don't render tables, and if the file grows past about 10KB the parser starts misbehaving. So when the changelog gets long, I have Claude move the old entries into a separate changelog.txt, as a pure move, no rewriting. The rule there is explicit: relocate, don't summarize, or you lose the history.
Where I draw the line
I keep all of this at half-automation on purpose. Three things stay manual: hitting the release button, the wording that users actually see, and merging code. Everything Claude produces arrives as a draft or a check result, never as a done deal.
That isn't caution for its own sake. Hand the whole thing over and you end up shipping text to users that nobody read first, and for a plugin that's a trust problem, not a time problem. The allowed-tools scoping and the forced (to confirm) markers are both just mechanisms for holding that line: let the machine do the fetching and the diffing, keep the judgment with me.
The part I didn't expect
I went in wanting Claude Code to make the coding faster. What it actually did was give me the coding back, by clearing the rubble around it.
The chores were never the expensive part on their own. The expensive part was what they did to focus: each small task knocked the code out of my head, and the reload was the tax. Moving the chores off my plate didn't just save their minutes. It let me stay in the build instead of climbing back into it five times a release. If you're reaching for an AI agent to write more code, it's worth checking whether the thing actually slowing you down is the code at all, or the ring of small jobs around it that keep breaking your attention. For me it was the ring, and that's the part worth handing off first.
I build WordPress plugins and write about AI tooling and security at https://raplsworks.com/.
Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.
