I pasted the critique into a new session and typed “fix these.” The Artificial intelligence (AI) fixed all of them and reported a clean run. At least two of the fixes made the themes worse than before I asked.
This is the second post in a two-part series. The first post was about how prompt depth determines whether an AI review finds your theme’s real problems or just validates the decisions you’ve already made. This one is about what happens after, when the findings are in hand and you have to turn them into working code.
The review is done. You have a list of findings. The Masthead readme says the wrong name. Kern’s version numbers don’t match. Wake’s story grid generates static placeholder cards instead of pulling live posts. Parcel’s front page is Wake’s template with CSS class names renamed.
Now comes the part most people get wrong.
The instinct, reasonable, understandable, is exactly what I did: paste the critique into a new session and say “fix these.” And the AI did fix them, all of them, and the tally was two fixes that made things worse, one that closed the ticket without addressing the problem, and one that described what to do rather than doing it.
The improvement prompt has the same problem as the review prompt: the quality of what gets built is determined before the AI types a single line of code. This is the post about that.
The same theme, the same findings, three different outcomes
The findings below come from the Colophon FSE collection critique from the previous post. Every prompt in this post starts from the same place: a complete list of issues, all seven themes available on disk, and an AI with full file access.
What changes is how we ask.
Level 1: “fix these”
The simplest improvement prompt mirrors the simplest review prompt. You paste the critique, you say fix it.
The critique below identified several issues with my WordPress theme collection. Please fix them.What you get back:
The AI returned a clean log: the Masthead readme was fixed, Kern’s version matched, the Wake story grid was addressed with a TODO comment, the Parcel front page was patched, the missing templates were created by copying archive.html, and the WP7 improvements were flagged as a recommendation for the next sprint.
Two of the six findings closed cleanly. The other four are problems that have been repackaged, not solved.
Wake’s fix added a comment calling for future work, the static PHP loop is still there. The Parcel fix stacked a product-hero pattern on top of a photography blog hero, now the front page starts with a DTC product section and immediately contradicts itself with a magazine story grid below it. The new taxonomy templates are archive.html with different heading text, which means they don’t inherit section accent colors or use the theme’s own design vocabulary; they exist only to tick a completeness box.
The WP7 improvements became a recommendation for “the next sprint.” They were not attempted.
Why this happens: the word “fix” signals minimal intervention. It is the same as telling a plumber to “fix the leak” and coming home to find the brown stain painted over on the ceiling, the complaint gone from the spot where you could see it while the pipe behind the drywall has not moved an inch. The AI’s default behaviour when fixing is to make the smallest change that removes the stated problem. A TODO comment removes the “static cards” problem by acknowledging it. Stacking a pattern on top of an existing template removes the “wrong front page” problem by adding the right thing without removing the wrong thing. These aren’t mistakes, they’re exactly what the Level 1 prompt asks for.
Level 2: the numbered list
More experienced users reach for a checklist. If the AI needs direction, give it a list. Number each item. Be specific about what to change.
What you get back:
Items 1 and 2: fixed correctly and quickly.
Item 4, Parcel’s front page, gets rebuilt. The three signature patterns appear. But the wp:query at the bottom is a bare title-and-excerpt list. Parcel has a parcel/features-row pattern that already handles styled post cards. The rebuild added a query but didn’t use the theme’s established post-display vocabulary.
Item 5, the missing templates, gets created. They exist. They pass a completeness check. But taxonomy.html for Kern is archive.html with the H1 text changed to the taxonomy name.
Items 6 and 7, the WP7 improvements, get written. The Block Bindings addition for the tidal log is technically correct in structure, but the meta fields are registered without show_in_rest: true. The Interactivity API weight-scrubber is partially implemented, the store action is written but the data-wp-style–font-variation-settings binding is missing.
What Level 2 does well: It completes every item. Nothing is deferred to “the next sprint.” What Level 2 misses: It treats every item as the same kind of work. And because it works through the list sequentially without reading how earlier files interact with later ones, fixes introduce new problems.
Level 3: the tiered execution prompt
The Level 3 prompt changes three things: it enforces an execution order based on impact, it defines what “done” looks like for each category of change, and it requires the AI to read before it writes.
Tier 1, Blocking issues: The Masthead and Kern fixes land correctly. For the Kern version fix, the AI found a changelog observation that wasn’t in the critique: “this also means any existing installs are showing ‘update available’ with a version jump from 1.0.0 to 1.6148. If this theme has active installs, that jump warrants a changelog entry explaining what changed.”
For Wake’s story grid, the prompt instructed the AI to read front-page.html first. It used queryId:2 to avoid collision with the existing queryId:1. It also added offset:1 to exclude the sticky post already shown in the hero, which Level 2 missed entirely.
For Parcel’s front page, the prompt required a test before marking it done: “could this template exist as Wake?” The test forced the AI to verify the template was unique to Parcel’s identity.
For the missing templates, the prompt set a quality bar instead of completeness: Kern’s taxonomy.html uses the typographic index layout from works-directory rather than copying archive.html’s card grid.
Tier 3, WP7 improvements: The Block Bindings addition includes show_in_rest: true because the prompt specified “an editor who uses this pattern can update the log from the post meta panel.” The Interactivity API weight-scrubber is fully built, the data-wp-style–font-variation-settings binding is present, the store is registered in inc/skin.php.
The three runs, side by side.
| Finding | Level 1: “fix these” | Level 2: numbered list | Level 3: tiered prompt |
|---|---|---|---|
| Masthead readme | Fixed | Fixed | Fixed |
| Kern version numbers | Fixed | Fixed | Fixed, plus a changelog note on the 1.0.0 to 1.6148 jump |
| Wake story grid | TODO comment; static loop still there | Sticky hero post repeats in the grid (no offset) | Live query, queryId:2, offset:1 |
| Parcel front page | Product hero stacked on top of the blog hero | Rebuilt, but the post list ignores parcel/features-row | Rebuilt and tested against “could this exist as Wake?” |
| Missing templates | archive.html copied with new heading text | Created; Kern’s taxonomy.html is archive.html with the H1 changed | Kern’s taxonomy.html uses the works-directory index layout |
| Block Bindings (tidal log) | Deferred to “the next sprint” | Written without show_in_rest: true | Written with show_in_rest: true |
| Interactivity API weight-scrubber | Deferred to “the next sprint” | Store action written, font-variation binding missing | Fully built, store registered in inc/skin.php |
What separates level 3 from level 2
Three things.
Read before write
Catches the queryId collision in Wake, the missing show_in_rest in the Block Bindings registration, and the version-jump changelog observation in Kern. None of those are findable from the critique alone.
Done means unrepeatable
The prompt defines “done” as a theme that could not be swapped with any other theme in the collection. That’s a harder test than “the finding is addressed.”
Execution order as judgment
Tier 1 before Tier 2 before Tier 3 reflects the actual dependency chain. A numbered list treats every item as independent. The tiered structure makes the dependencies explicit.
The Level 1 output had one line that sums up the whole problem: “These are recommended for the next development sprint.”
The Interactivity API weight-scrubber for Kern’s typeface-pairing specimen is the single change that moves Kern from “excellent WP.org theme” to the theme I build to demonstrate live at a technical talk. Level 1 deferred it. Level 2 attempted it and got the binding wrong. Level 3 built it.
Both posts in this series use the Colophon FSE theme collection as the real example, because a theme with all the right files and all the wrong implementations is as unsubmittable as one with the wrong readme. The prompts are templates, swap in your theme name, file paths and findings, and the tier structure applies to any theme and any review. If you want to see one of the themes in use, meet Quillwork, a free typography-first theme, or read how eight themes went to full site editing. For where AI belongs in a WordPress workflow at all, see the WordPress AI layer needs your judgment.
The same review-then-execute discipline is what my audit engagements are for, when the codebase is yours instead of a theme directory’s: a WordPress site audit exists to turn findings into safe, working changes rather than a confident mess. If AI is already writing code in your shop and you are not sure the fixes are net-positive, book a call and we will pressure-test the process as well as the output.
Leave a reply