wp-block-themes

À utiliser lors du développement de thèmes bloc WordPress : theme.json (paramètres/styles globaux), modèles et parties de modèles, motifs, variations de style, et l’éditeur de site…

npx skills add https://github.com/automattic/agent-skills --skill wp-block-themes

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

  1. Run triage:
    • node skills/wp-project-triage/scripts/detect_wp_project.mjs
  2. 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.json schema 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.json present
    • templates/ and/or parts/ 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.json shape/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.

Plus de skills de automattic

wp-phpstan
automattic
À utiliser lors de la configuration, de l'exécution ou de la correction de l'analyse statique PHPStan dans des projets WordPress (plugins/thèmes/sites) : configuration de phpstan.neon, baselines,…
official
wp-playground
automattic
Utiliser pour les workflows WordPress Playground : instances WP jetables rapides dans le navigateur ou localement via @wp-playground/cli (server, run-blueprint, build-snapshot),…
official
wp-plugin-development
automattic
À utiliser lors du développement de plugins WordPress : architecture et hooks, activation/désactivation/désinstallation, interface d'administration et API de réglages, stockage de données, cron/tâches, sécurité…
official
wp-project-triage
automattic
À utiliser lorsque vous avez besoin d'une inspection déterministe d'un dépôt WordPress (plugin/thème/thème de blocs/WP core/Gutenberg/site complet) incluant les outils/tests/versions…
official
wp-rest-api
automattic
À utiliser lors de la création, de l'extension ou du débogage des points de terminaison/routes de l'API REST WordPress : register_rest_route, classes WP_REST_Controller/controller, schéma/arguments…
official
wp-wpcli-and-ops
automattic
À utiliser lors du travail avec WP-CLI (wp) pour les opérations WordPress : recherche-remplacement sécurisé, export/import de base de données, gestion des plugins/thèmes/utilisateurs/contenu, cron, vidage du cache,…
official
wpds
automattic
À utiliser lors de la création d'interfaces utilisateur exploitant le WordPress Design System (WPDS) et ses composants, tokens, motifs, etc.
official
woocommerce-finalize
automattic
Audit de santé du code et de traçabilité en pré-libération pour les plugins WooCommerce. S'exécute après la revue de code -- se concentre sur le code mort, la duplication, la complexité structurelle, et…
official