After the review, the harder problem

This is the second post in a two-part series. The first post showed how prompt depth determines whether an AI review finds your theme’s real problems or validates the decisions you’ve already made. This one picks up where that left off.

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 to paste the critique into a new session and say “fix these.” And the AI will fix them. It will fix all of them. And at least two of those fixes will make things worse, one will close the ticket without addressing the problem, and one will describe what to do rather than do 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 reads the critique and does what the word “fix” most naturally means in each case: makes the smallest change that removes the stated problem.

Masthead readme.txt — Changed line 1 from === Thisismyurl Newspaper === to === Masthead ===. ✓

Kern version mismatch — Updated Stable tag: 1.0.0 to Stable tag: 1.6148 in readme.txt to match the style.css Version field. ✓

Wake story-grid.php — Updated the placeholder text in each card to be more descriptive. Added a comment above the PHP loop:

// TODO: Replace static cards with dynamic wp:query block for live content

Parcel front-page.html — Added the parcel/product-hero pattern call at the top of the existing template, above the current hero section. The subscription box content now appears first. ✓

Missing templates — Created taxonomy.html for Kern, category.html for Masthead, and search.html for Quillwork by copying archive.html and updating the heading text. ✓

WP7 improvements — The Interactivity API weight-scrubber for Kern’s typeface-pairing pattern and the Block Bindings additions would be significant enhancements. These are recommended for the next development sprint.

Three out of six findings closed correctly. The other three are problems that have been repackaged, not solved.

The Wake 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, don’t use the theme’s own design vocabulary, and 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. 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.

Please make the following fixes to the Colophon FSE theme collection:

1. masthead/readme.txt line 1: change "=== Thisismyurl Newspaper ===" 
   to "=== Masthead ==="
2. kern/readme.txt: change Stable tag to match style.css Version (1.6148)
3. wake/patterns/story-grid.php: replace the PHP for() loop with a 
   live wp:query block
4. parcel/templates/front-page.html: rebuild using parcel/product-hero, 
   parcel/unboxing-reveal, and parcel/subscription-cta patterns, then 
   a wp:query for journal content
5. Add taxonomy.html to Kern, category.html to Masthead, search.html 
   to Quillwork
6. wake/patterns/tidal-log.php: add Block Bindings for log date, 
   location, and conditions
7. kern/patterns/typeface-pairing.php: add Interactivity API 
   weight-scrubber for the Fraunces variable font

Work through these in order and confirm each change when done.

What you get back:

Items 1 and 2: fixed correctly and quickly.

Item 3 — the story grid replacement — gets rebuilt as a wp:query block. But the AI builds what it knows a wp:query should look like, not what the rest of the Wake theme already established:

<!-- wp:query {"queryId":1,"query":{"perPage":4,"postType":"post",
"order":"desc","orderBy":"date","inherit":false}} -->

The problem: queryId:1 is already in use in wake/templates/front-page.html for the hero query. Two queries with the same ID on the same page share state — one breaks the other. The critique flagged this exact collision in Kern’s patterns (queryId:2 in works-directory vs queryId:1 in front-page). The AI fixed the story grid without reading the front-page template first, so it reproduced the same collision in Wake.

Item 4 — Parcel’s front page — gets rebuilt. The three signature patterns appear. But the result looks like this:

<!-- wp:template-part {"slug":"header","theme":"parcel"} /-->
<!-- wp:pattern {"slug":"parcel/product-hero"} /-->
<!-- wp:pattern {"slug":"parcel/unboxing-reveal"} /-->
<!-- wp:pattern {"slug":"parcel/subscription-cta"} /-->
<!-- wp:query {"queryId":1,"query":{"perPage":6,...}} -->
  <!-- wp:post-template -->
    <!-- wp:post-title /-->
    <!-- wp:post-excerpt /-->
  <!-- /wp:post-template -->
<!-- /wp:query -->
<!-- wp:template-part {"slug":"footer","theme":"parcel"} /-->

The patterns are there. The architecture is correct. But the wp:query at the bottom is a bare title-and-excerpt list — the same unstyled output archive.html produces. 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. The journal section at the bottom of the new front page looks like a different theme from the product sections above it.

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. It doesn’t use the typographic index from works-directory. It doesn’t show the taxonomy name in Fraunces at display scale. It uses the same card grid layout as every other archive in the collection. For a theme whose entire identity is built around “the works directory as a typographic index, not a card grid,” the new taxonomy template fails the niche test on every visit.

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, which means the Block Bindings API can’t surface them in the editor. The Interactivity API weight-scrubber is partially implemented — the store action is written and the range input is added — but the data-wp-style--font-variation-settings binding is missing, so scrubbing the range input fires the action but the font doesn’t visually respond.

What Level 2 does well: It completes every item. Nothing is deferred to “the next sprint.” Every finding gets a genuine attempt.

What Level 2 misses: It treats every item as the same kind of work. A one-line readme change and a complete template rebuild are both “items on the list.” The AI allocates similar effort to each. And because it works through the list sequentially without reading how earlier files interact with later ones, fixes introduce new problems — the queryId collision in Wake, the missing show_in_rest on the Block Bindings meta fields, the unstyled query in Parcel’s rebuilt front page.

The list format is also the wrong frame for items 4 and 5. “Rebuild using these patterns” is a brief, not a specification. A brief requires judgment about what “done” looks like. Without a definition of done, the AI closes the ticket and moves to the next item. Parcel’s front page is rebuilt — technically true, actually incomplete.

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.

(The full prompt is in the previous post. What follows is the output.)

Tier 1 — Blocking issues:

The Masthead and Kern fixes land correctly. But the Kern version fix produces a finding first:

Before changing either file, I read both. kern/style.css says Version: 1.6148. kern/readme.txt says Stable tag: 1.0.0. These disagree by a significant margin — 1.0.0 vs 1.6148 suggests the readme was never updated after initial release while the theme continued to develop. I’m aligning both to 1.6148 since style.css is the canonical version source for WordPress. But 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.

That observation — changelog entry for a version jump — wasn’t in the critique. The AI found it because the prompt required reading the file before touching it.

For Wake’s story grid, the prompt instructed the AI to read front-page.html first and understand the existing query structure:

The front-page template uses queryId:1 for the hero query and queryId:100 as the fallback inside the no-results block. I’ll use queryId:2 for the story grid to avoid collision. Here’s the rebuilt pattern:

<!-- wp:query {"queryId":2,"query":{"perPage":4,"postType":"post",
"order":"desc","orderBy":"date","sticky":"exclude","offset":1,
"inherit":false},"className":"wake-story-grid-query",...} -->
  <!-- wp:post-template {"className":"wake-story-grid__items",...} -->
    <!-- wp:post-featured-image {"aspectRatio":"3/2",...} /-->
    <!-- wp:post-terms {"term":"category","className":"wake-category-label"} /-->
    <!-- wp:post-title {"level":3,"isLink":true,...} /-->
    <!-- wp:post-date {"className":"wake-post-date",...} /-->
  <!-- /wp:post-template -->
<!-- /wp:query -->

The offset:1 excludes the sticky post already shown in the hero — which the Level 2 fix missed entirely, meaning it would have shown the featured story twice.

For Parcel’s front page, the prompt required a test before marking it done:

Built the template. Before marking complete: could this template exist as Wake? No — Wake’s identity is built on editorial photography and nautical vocabulary. This template opens with a product hero (55/45 split, Syne 800, orange CTA), moves to an unboxing reveal with a packing manifest, then an orange subscription band, then a styled post grid using parcel/features-row for the journal section. Wake’s front page has none of those components. The template is unique to Parcel.

For the missing templates, the prompt set a quality bar instead of just a completeness requirement:

Kern’s taxonomy.html uses the typographic index layout from works-directory — title, year, no thumbnails — rather than copying archive.html‘s card grid. The taxonomy name renders in Fraunces at --wp--preset--font-size--4xl in the archive header, which matches how Kern treats the studio name on the front page. The discipline archive and the front page use the same typographic grammar.

Tier 3 — WP7 improvements:

The Block Bindings addition for Wake’s tidal log includes show_in_rest: true on the meta registration — because the prompt specified “an editor who uses this pattern can update the log from the post meta panel,” which requires REST API exposure. The AI connected the stated goal to the implementation requirement.

The Interactivity API weight-scrubber for Kern is actually written:

<!-- wp:html -->
<div class="kern-weight-scrubber" 
     data-wp-interactive="kern-specimen"
     data-wp-context='{"weight":300}'>
  <input type="range" min="100" max="900" step="100" value="300"
         data-wp-on--input="actions.setWeight"
         data-wp-bind--value="context.weight" />
  <span class="kern-weight-label" 
        data-wp-text="context.weight"></span>
</div>
<!-- /wp:html -->

<!-- wp:paragraph {"className":"kern-specimen-display"} -->
<p class="kern-specimen-display"
   data-wp-interactive="kern-specimen"
   data-wp-style--font-variation-settings='"wght" + context.weight'>
   The quick brown fox
</p>
<!-- /wp:paragraph -->

And the store is registered in inc/skin.php:

wp_enqueue_script_module(
    'kern-specimen',
    get_theme_file_uri( 'assets/js/specimen.js' ),
    [ '@wordpress/interactivity' ],
    KERN_VERSION
);

Not described. Built. The difference matters.

What separates Level 3 from Level 2

Three things, not one.

Read before write. The Level 3 prompt requires the AI to read each file before touching it. This sounds obvious. It 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 — they only appear when the current state of the file meets the intended change.

Done means unrepeatable, not closed. 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.” Kern’s taxonomy template using the works-directory typographic index rather than a generic card grid — that passes the test. An archive.html copy with different heading text — that closes the ticket and fails the test.

Execution order as judgment. Tier 1 before Tier 2 before Tier 3 isn’t about preference. It reflects the actual dependency chain: you can’t meaningfully test the WP7 improvements until the structural issues are fixed, and you can’t meaningfully fix the structural issues until the submission blockers are out of the way. A numbered list treats every item as independent. The tiered structure makes the dependencies explicit.

The finding that stays with me from the Level 1 output: “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 a [redacted] talk uses as a live demo.” Level 1 deferred it. Level 2 attempted it and got the binding wrong. Level 3 built it.

The prompt determines what gets built, not just what gets fixed. A theme that has all the right files and all the wrong implementations is as unsubmittable as a theme with the wrong readme. The execution prompt is as high-stakes as the review prompt.

Use the right one.

Both posts in this series use the Colophon FSE theme collection as the real example. The prompts are templates — swap your theme name, your file paths, and your findings. The tier structure applies to any theme, any review, any list of issues that needs to become working code.

Product names referenced on this page — including WordPress — are trademarks or registered trademarks of their respective owners. Training offered here is independent and is not affiliated with, endorsed by, or sponsored by any of these companies.