| name | wp-block-themes |
| description | Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching). |
| compatibility | Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node. Some workflows require WP-CLI. |
WP Block Themes
When to use
Use this skill for block theme work such as:
- editing
theme.json(presets, settings, styles, per-block styles) - adding or changing templates (
templates/*.html) and template parts (parts/*.html) - adding patterns (
patterns/*.php) and controlling what appears in the inserter - adding style variations (
styles/*.json) - debugging “styles not applying” / “editor doesn’t reflect theme.json”
Inputs required
- Repo root and which theme is targeted (theme directory if multiple exist).
- Target WordPress version range (theme.json version and features vary by core version).
- Where the issue manifests: Site Editor, post editor, frontend, or all.
Procedure
0) Triage and locate block theme roots
- Run triage:
node skills/wp-project-triage/scripts/detect_wp_project.mjs
- Detect theme roots + key folders:
node skills/wp-block-themes/scripts/detect_block_themes.mjs
If multiple themes exist, pick one and scope all changes to that theme root.
1) Create a new block theme (if needed)
If you are creating a new block theme from scratch (or converting a classic theme):
- Prefer starting from a known-good scaffold (or exporting from a WP environment) rather than guessing file layout.
- Be explicit about the minimum supported WordPress version because
theme.jsonschema versions differ.
Read:
references/creating-new-block-theme.md
After creating the theme root, re-run detect_block_themes and continue below.
2) Confirm theme type and override expectations
- Block theme indicators:
theme.jsonpresenttemplates/and/orparts/present
- Remember the style hierarchy:
- core defaults → theme.json → child theme → user customizations
- user customizations can make theme.json edits appear “ignored”
Read:
references/debugging.md(style hierarchy + fastest checks)
3) Make theme.json changes safely
Decide whether you are changing:
- settings (what the UI allows): presets, typography scale, colors, layout, spacing
- styles (how it looks by default): CSS-like rules for elements/blocks
Read:
references/theme-json.md
4) Templates and template parts
- Templates live under
templates/and are HTML. - Template parts live under
parts/and must not be nested in subdirectories.
Read:
references/templates-and-parts.md
5) Patterns
Prefer filesystem patterns under patterns/ when you want theme-owned patterns.
Read:
references/patterns.md
6) Style variations
Style variations are JSON files under styles/. Note: once a user picks a style variation, that selection is stored in the DB, so changing the file may not “update what the user sees” automatically.
Read:
references/style-variations.md
Verification
- Site Editor reflects changes where expected (Styles UI, templates, patterns).
- Frontend renders with expected styles.
- If styles aren’t changing, confirm whether user customizations override theme defaults.
- Run the repo’s build/lint scripts if assets are involved (fonts, custom JS/CSS build).
Failure modes / debugging
Start with:
references/debugging.md
Common issues:
- wrong theme root (editing an inactive theme)
- user customizations override your defaults
- invalid
theme.jsonshape/typos prevent application - templates/parts in wrong folders (or nested parts)
Escalation
If upstream behavior is unclear, consult canonical docs:
- Theme Handbook and Block Editor Handbook for
theme.json, templates, patterns, and style variations.