Evidence record · captured 2026-10-11

WordPress Block Development

A procedure for Gutenberg block work: run the repo triage script, locate blocks, then handle block.json metadata, registration, attributes and serialization, supports, dynamic rendering (render.php / render_callback), deprecations and migrations, viewScriptModule vs viewScript, and @wordpress/scripts / create-block build and test workflows, each backed by a reference file.

Official publisherUnverifiedSource reviewedBehavior not tested

Source review

Editorial assessment

This is a source-only assessment. It does not claim runtime or security testing.

What it does

Turns Gutenberg block work into a numbered procedure that starts with a deterministic block.json scan. Each concern (registration, serialization, deprecations) routes to its own reference file, so the agent edits blocks without breaking saved content.

Best for

Changing a block's saved markup or attributes without triggering "Invalid block" on existing posts
Migrating blocks from apiVersion 2 to 3 ahead of the iframed post editor
Scaffolding a new block with @wordpress/create-block and wiring PHP registration from metadata

Strengths in the source

Tells the agent to run list_blocks.mjs, a read-only walk that skips node_modules, vendor and dist, to identify the exact block root before editing.
Requires a deprecated entry (newest to oldest) with save and optional migrate whenever saved markup or attributes change.
Explains why apiVersion 3 matters for the iframed editor and lists the migration caveats: style handles in block.json and window-scoped scripts.
Names the wrapper helpers per context: useBlockProps, useBlockProps.save and get_block_wrapper_attributes for PHP render.

Limitations

Step 0 runs detect_wp_project.mjs from the sibling wp-project-triage skill, so installing this skill alone leaves the triage step without its script.
Per the repository README, the WordPress skills were generated with an AI model and then reviewed by WordPress contributors.
Targets WordPress 7.0+ per its compatibility field; most depth lives in ten reference files rather than in SKILL.md itself.

When not to use it

Work centered on data-wp-* directives and stores, which the skill hands off to the separate wp-interactivity-api skill.
Theme-level styling through theme.json, templates or patterns rather than block code.

Reviewed by Retenta editorial on 2026-10-11; scope: source only.

Files included in this review

skills/wp-block-development/SKILL.md

Evidence and boundaries

Execution · not tested

Retenta has not executed this skill.

Security · not tested

Bundles 1 script (scripts/list_blocks.mjs) that the agent may run. Retenta has not run them or scanned them.

Pinned publisher source: skills/wp-block-development/SKILL.md
Revision: 3cf7f6f701300d80166cc0b7e6ebc667501c353d
License evidence: GPL-2.0-or-laterRetenta preserves the license text captured with this immutable upstream snapshot; no independent legal or security review is claimed.
Last source change: 2026-07-08
Independent verification: Published by WordPress (WordPress.org contributors), but not independently verified by a third-party reviewer.
Upstream repository: Open publisher repository