Gutenberg blocks

When to use it

Build, debug or review Gutenberg blocks: block.json registration, invalid-content errors and deprecations, dynamic render.php, InnerBlocks, Interactivity API, Block Bindings, iframe editor. Not for theme.json/templates (theme skill) or generic plugin code.

Boundaries and hand-offs

• Theme templates, theme.json , patterns files: hand off to wp-devkit-theme-development .
• Admin screens, settings pages, REST routes, plugin lifecycle: wp-devkit-plugin-development , wp-devkit-rest-api-development , wp-devkit-admin-ui-development .
• Escaping or authorization questions beyond the block renderer: wp-devkit-security-review .
• Editor/visual polish decisions: wp-devkit-ui-design .

Ask Claude

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

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

The short form /wp-devkit:block 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-block-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:

• bindings-and-php-only-blocks.md : Block Bindings and PHP-only blocks
• block-development-workbook.md : Block development workbook
• dynamic-rendering-and-security.md : Dynamic rendering, escaping and caching
• editor-and-iframe-compat.md : Editor behavior, data and the iframe editor
• interactivity-api.md : Interactivity API
• metadata-registration-and-build.md : Block metadata, registration and build output
• saved-content-and-deprecations.md : Saved content, validation and deprecations

How a review runs

1. Follow metadata from source to build output to server and client registration ( references/metadata-registration-and-build.md ). Check asset field types, file: paths, *.asset.php , and the apiVersion against the supported range.
2. Trace each attribute from control to stored form (comment JSON or markup source ) to render. Decide static vs dynamic from freshness and storage needs.
3. Compare each historical fixture with the current save and attribute definitions ( references/saved-content-and-deprecations.md ). Check nested blocks.
4. For dynamic output, trace attributes and context to the escaped sink ( references/dynamic-rendering-and-security.md ); confirm wrapper attributes and empty states.
5. Check editor behavior under the iframe, data loading, effects and errors ( references/editor-and-iframe-compat.md ).
6. For interactive blocks, check state vs context, server initialization and event handling ( references/interactivity-api.md ). For bindings or PHP-only blocks, read references/bindings-and-php-only-blocks.md .
7. Report the failing boundary with the old/new content checks needed. Do not rebuild assets or rewrite saved content during review. Read references/block-development-workbook.md for the decision table, symptom table, false positives, severity guidance 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. List candidates and missing evidence separately; use "not established" when the fixture, build output or version is unavailable. Implementation: changed boundaries, deprecations added, commands with exit codes, fixtures, unexecuted checks, residual risk. A passing build or editor test does not prove old-content safety, frontend rendering or cross-version support.

Where to go next

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