Four Claude Code Workflows for WordPress Developers
Most articles about AI coding assistants for WordPress are written by people who have never shipped a plugin. You can tell because the examples are always "build a Hello World shortcode" or "generate a custom post type." Nobody actually pays you to do that. They pay you when checkout breaks at 2 AM on Black Friday, and the staging environment doesn't reproduce it.
I've been using Claude Code in production since the start of 2025, mostly on WordPress and WooCommerce work for consulting clients, and on my own plugin WP-AutoInsight. What follows are four workflows I actually run, with the prompts I actually use.
If you haven't set up Claude Code yet, start here. Terminal setup matters more than people admit, and I'm not going to repeat that post.
1. Plugin scaffolding that looks modern
Every WordPress plugin author has a private template they paste into new projects. Mine was getting old. PHP 8 typed properties, namespaces, autoloading, modern hook patterns. The kind of stuff you keep meaning to update and never do because the existing template still works.
The prompt I use:
Read the structure of WP-AutoInsight at ~/projects/wp-autoinsight
and use it as a reference for code style, but generate a fresh plugin scaffold for
[plugin name and one-line description]. Use PHP 8.1+, namespaces, PSR-4 autoloading
via Composer, a Singleton main class, and separate files for admin UI,
REST endpoints, and hooks. Include readme.txt with the WordPress.org format.
Do not invent functionality. Stop at empty class shells with proper docblocks.
The "do not invent functionality" line is load-bearing. Without it, Claude Code will build you a fully working plugin for something you didn't ask for, and you'll spend an hour deleting code instead of writing it.
The output is a directory I can immediately git init and start working in. Roughly fifteen minutes of cleanup compared to forty minutes of starting from scratch.
What's the catch? Claude Code can sometimes generate code in a slightly outdated format. Always check against the current plugin readme spec before submitting.
2. WP-CLI script generation for one-off client tasks
Half my consulting work involves a sentence like "we need to migrate 4,000 products from this old taxonomy to this new one without breaking SEO”, and the best approach is “let’s create a WP-CLI script," but we are not getting paid to create a script; we are getting paid to deliver the migration.
The prompt:
Generate a WP-CLI command class for [task]. The class should: register
a custom command, accept --dry-run and --verbose flags, batch operations
in groups of 200 with WP_CLI::log progress output, handle errors per item
without aborting the whole run, and write a CSV log file to wp-content/uploads/.
Use $wpdb only when WP_Query/WP_Term_Query is the wrong fit.
No external composer dependencies.
The constraints in that prompt come from things that have gone wrong before. --dry-run because we need to ensure it will run on the client’s side without errors. Per-item error handling because a single corrupted row will otherwise abort an hour-long migration. CSV log because somebody is going to ask "which products failed?" three days later, and “we don’t know” isn’t an answer.
That's the value of using Claude Code over a generic ChatGPT prompt. The model has the whole project structure available. It knows what classes exist, what naming convention you use, and where you put scripts. The script comes back, fitting your repo.
3. Theme migration sanity checks
I don't do many theme migrations anymore. They're tedious, high-risk, low-margin work. But sometimes a long-term client asks and, well, you say yes.
What Claude Code does well here is the boring part: comparing two theme directories and telling you what's actually different versus what's just whitespace and renamed variables.
Compare ~/projects/client-old-theme and ~/projects/client-new-theme.
List, in priority order:
(1) template files in the old theme that have no equivalent in the new theme,
(2) functions registered in the old theme's functions.php that are not registered
or differently named in the new one,
(3) hooks added/removed,
(4) enqueued scripts and styles that changed handles or paths.
Ignore whitespace, comments, and version numbers. Output as a markdown table.
What this saves: roughly four hours of manual diff scanning per migration. What it does not replace: running the new theme on staging with real content and clicking around. Claude Code can tell you the structural diff, but you still need to test. The difference is that now the migration starts from a sane place.
4. Plugin security audit before client handoff
This is the workflow that earns its keep.
When I hand off a plugin to a client, either one I built or one they're inheriting from a previous developer, I run a security pass. Manually, this can take some time, and is the kind of work where you make mistakes when you're tired. Claude Code makes the mistakes for me, which I prefer.
Audit the plugin at ~/projects/[plugin-path] for the following, in this order:
1. SQL queries not using $wpdb->prepare()
2. $_GET, $_POST, $_REQUEST values used without sanitization functions
3. Output not escaped with esc_html, esc_attr, esc_url, or wp_kses
4. AJAX endpoints missing nonce verification
5. capability checks missing on admin actions
6. file_get_contents or wp_remote_get on user-supplied URLs without validation
For each finding, output: file path, line number, the offending code,
and the WordPress function that should be used instead.
Also, check if the codebase is WPCS-compliant and report any new errors or warnings that you didn't catch
Do not fix anything yet. Report only.
"Do not fix anything yet" matters. Claude Code is enthusiastic. If you don’t specify, he’ll start trying to fix things for you, even before you decide if it’s OK to spend tokens and time on that fix. Find first. Fix later, one finding at a time, with you reviewing each change.
Also, the WPCS line is important. Any WordPress dev should have phpcs running globally, with updated WPCS rules.
What these workflows have in common
Every prompt above includes a constraint that stops Claude Code from doing the wrong thing. "Do not invent functionality." "Report only." "Stop at empty class shells." The model is helpful, but helpful in the wrong direction is worse than unhelpful. I learned this the expensive way, on a real client project.
Claude Code is the best AI tool I've used for WordPress work, and I've tested most of them inside WP-AutoInsight. It's also the one that requires the most discipline. The prompts above aren't impressive. They're boring. That's the point.
If your team is stuck at the prototype stage with AI tools and can't figure out how to get them into production safely, that's literally what I do for a living. Drop a line.