Generateblocks Layouts

---
name: generateblocks-layouts
description: Build and audit WordPress layouts with GenerateBlocks V2, including CSS Mode, responsive at-rules, dynamic data, Pro components, and recovery-safe block serialization. Use for new GB layouts, conversions, repairs, and hand-authored block markup.
metadata:
  compatibility: "Verified: free 2.5.0 + Pro 2.8.0 on WordPress 7.1.3/PHP 8.5 (live native editor, 2026-10-27). Design-system workflow first tested on 2.5.0-beta.1 + 2.8.0-beta.1. Older sites: free 2.4.x + Pro 2.7.x notes retained."
---

# GenerateBlocks layout builder

Build or repair GenerateBlocks V2 layouts using the installed plugin's native
serialization. This skill supports local styling, dynamic content, Pro blocks,
and explicitly requested shared systems.

**Use GenerateBlocks and core blocks only.** Keep styling in native block
`styles`/`css` and use native Pro blocks for interactions. Do not introduce
Scripts Manager, Page Block, Custom HTML/CSS/JS, another builder, or theme/plugin
code to complete a GenerateBlocks design. An external implementation requires
an explicit user request. Simplify unsupported effects within native blocks.

## Read only what the task needs

Before generating markup, read [authoring-contract.md](references/authoring-contract.md).
It owns the scope prompt, IDs, blocks, serialization, CSS parity, responsive
basics, and validation rules. Use [_index.md](references/_index.md) to select
additional references. Do not load the entire library or recovery catalog for
a routine static layout; the compact contract is sufficient for familiar
Element/Text layouts using ordinary states and native breakpoints.

**Local styles are the default.** Prompt once about shared Global Styles and
Design Tokens unless the user already chose. Add shared records or new shared
dependencies only after explicit opt-in; preserve existing references. The
contract contains the exact prompt; `styling-scope.md` covers edge cases.

## Workflow

1. Inspect the source/target, versions, and design guidance. Use the real post ID
   when available; otherwise use a random four-digit block-ID scope.
2. Select semantic blocks and preserve content/behavior. For new designs, read
   `design-quality.md`; for dynamic data, read `dynamic-tags.md` and its task guide.
3. Generate file output with the native serializer or `scripts/gb_serialize.py`.
   Keep editable `styles` and compiled `css` aligned.
4. Run `scripts/preflight.py FILE --id-scope SCOPE`, then validate unfamiliar output
   in the real editor. Check visible content and relevant responsive/interactivity
   behavior. Static preflight alone is not proof of editor validity.
5. For live writes, first read `mcp-publishing.md`; snapshot, splice, read back,
   and verify with `scripts/verify_roundtrip.py`.

Keep summaries short: what changed, output path, required Pro features, tests,
and any unverified behavior. Source conversion does not authorize publication.

## Examples and failures

Use examples as structural starting points; replace their IDs, URLs, and content.
Choose a relevant file in `examples/basic`, `compound`, `layouts`, or `svg` only
when needed. `examples/beta-design-system` is an opt-in shared-system example,
not the default starter.

For a recovery/preflight failure, open the matching topic in `recovery-rules.md`
or `troubleshooting.md`. For an unfamiliar attribute/tag, use `block-types.md`
or installed `block.json`. Reuse scripts rather than duplicating escape tables
or embedding another block manual here.