Theme development

When to use it

Build, debug or review classic, child, hybrid and block themes: template hierarchy and Site Editor overrides, theme.json versions and style layers, patterns and parts, fonts and images, classic-to-block migration. Not for block internals (block skill) or visual redesign (ui-design).

Boundaries and hand-offs

• Block registration, save , deprecations, Interactivity: wp-devkit-block-development .
• Visual redesign, journeys, tokens as design decisions: wp-devkit-ui-design .
• Plugin-owned behavior (CPTs, shortcodes, integrations): keep out of presentation changes.
• Escaping/authorization depth: wp-devkit-security-review ; WCAG conformance: wp-devkit-wcag-review .

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:theme-review <target-path>

The short form /wp-devkit:theme requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-theme-development
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• classic-to-block-migration.md : Classic, hybrid and block migration
• patterns-assets-and-i18n.md : Patterns, template parts, assets, images and i18n
• template-ownership-and-hierarchy.md : Template ownership and hierarchy
• theme-development-workbook.md : Theme development workbook
• theme-json-and-styles.md : theme.json, style layers and variations

How a review runs

1. Determine the theme type and resolve the request through the template hierarchy; check database overrides before editing a file ( references/template-ownership-and-hierarchy.md ).
2. Resolve styles across core, theme, child and user layers; match theme.json version and features to the oldest supported WordPress ( references/theme-json-and-styles.md ).
3. Inspect patterns, parts, enqueueing, images, fonts, i18n and RTL ( references/patterns-assets-and-i18n.md ). Keep plugin-owned behavior out of the theme.
4. For conversion, inventory templates, menus, widgets, shortcodes, Customizer mods and URLs, map each to a destination and keep a rollback ( references/classic-to-block-migration.md ).
5. Use rendered evidence (screens at several widths, keyboard, long translations, RTL). Report missing observations; do not edit templates or user styles during review. Read references/theme-development-workbook.md for the decision table, symptoms, false positives, severity and acceptance checks.

What you get back

Lead with the result and reviewed scope. Confirmed concern: file:line, actor, trigger, reachable path, impact, confidence, minimal fix, regression check. Keep candidates and "not established" items separate. Implementation: owner layer, changed files, commands with exit codes, widths/locales checked, unexecuted checks, rollback. A passing render at one width does not establish other widths, locales, plugins or saved user styles.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.