What this prompt does
This prompt makes the AI a senior WordPress engineer that builds a custom Gutenberg block and returns working plugin code, not pseudocode. You provide the [block_name], the [attributes], and the [render_mode], with tooling fixed to @wordpress/scripts using block.json and JSX, and it returns the full file tree followed by each key file - PHP bootstrap, block.json, edit.js, and render.php - in its own code block.
The six deliverables produce a clean, installable block: a block.json declaring your [attributes], supports, and the render callback; a React-based editor UI in edit.js with a live preview of the attributes; a dynamic server-side render in PHP that outputs the saved attributes via your [render_mode]; InspectorControls in the sidebar for every editable setting; block transforms to and from a core block plus at least one registered block pattern; and the plugin bootstrap file and folder structure so it installs cleanly. The structure works because custom blocks are where you escape page-builder bloat, and dynamic server render keeps data-driven content from shipping as stale static HTML.
When to use it
- You want a custom Gutenberg block instead of page-builder bloat.
- Your block is data-driven - pricing, listings - and must render fresh on the server.
- You need a React editor UI with live preview and sidebar InspectorControls.
- You want block transforms to and from a core block plus a registered pattern.
- You need a clean plugin bootstrap and folder structure that installs without fuss.
Example output
You get the full file tree, then each key file in its own block: the PHP bootstrap that registers the plugin, a block.json declaring your [attributes], supports, and render callback, an edit.js React editor UI with live preview and InspectorControls for every setting, and a render.php that outputs the saved attributes via your [render_mode] - plus block transforms and at least one registered pattern.
Pro tips
- Choose dynamic server-side render for anything data-driven like pricing or listings, so editors never ship stale static HTML.
- Define
[attributes]precisely - their types in block.json drive both the editor controls and what render.php receives. - Keep InspectorControls covering every editable setting so editors do not have to touch markup.
- Set
[block_name]to a clear, namespaced value so it does not collide with core or other plugin blocks. - Use the block transforms to let editors convert from a core block, smoothing migration off existing content.
- Match the
[render_mode]to the data: static render is fine for fixed content, but dynamic is essential when the output changes. - Register at least one block pattern so editors start from a sensible default layout instead of an empty block they have to configure from scratch.
- Build with @wordpress/scripts as specified rather than hand-rolling the bundler, so block.json and the JSX editor build stay aligned with current WordPress conventions.
