Find the block types you can use on this site

ContentBeginner~5 min

Before you start

Plugin version 1.10.0 or newer, which adds both block type reads. Both are off until you switch them on in the Abilities tab, like every ability. The connected user needs the edit-posts capability. Nothing here writes.

Every WordPress site has its own set of blocks. Core ships a long list, your theme adds a few, and plugins add more: a form plugin’s form block, a shop’s product grid, the custom ACF blocks a developer built for you. When you ask an agent to build a page, it should use the blocks this site actually has, not the ones it remembers from somewhere else.

This prompt is the inventory. It lists what is registered, sorts it into something you can read, and opens the specific blocks you care about so you can see what each one accepts.

The prompt
Before we build anything, show me which blocks this site has. Read only,
change nothing.
List the block types registered on the site [only the ones from the theme
and plugins, skip core]. Group them by where they come from, and mark which
ones are ACF blocks and which render on the server.
Then open these blocks and, for each, give me a short summary of its
attributes, what it supports (colors, spacing, alignment and so on), its
style variations, and whether it only works inside a parent block:
[core/group, core/columns, the pricing table block].
Finish with a short list of the blocks you would use for [a landing page
with a hero, three features and a call to action], using only names from
the list you just read.

Why this is safe to run

Both abilities are reads. Listing the registered block types and opening one of them returns the definition the block editor already shows a user who can edit posts, and nothing on the site changes. If one of the two is still switched off, the agent simply does not have it, and the prompt stops at what it can read.

The value is in the last step. A block name that is not registered on your site becomes content that does not render as that block, and an attribute the block does not declare is ignored. Reading the list first means any later write uses real block names with the attributes they accept. When you are ready to change a page, swap one block on a page uses the same reads before it writes.

Already connected? Skip the paste. Ask your agent for the “find the block types you can use” recipe, or just ask which blocks your site has, and it runs the same reads on your own install.

How it works

  1. List every block type registered on the site, filtered by namespace or a search word if you give one.
  2. Group the results by where they come from: core, the theme, or a plugin, with ACF blocks marked.
  3. Open each block you name and summarize its attributes, supports and style variations.
  4. Point out blocks that only work inside a parent block, and blocks that render on the server.

Questions

Is this the same as listing synced blocks?
No. Block types are the kinds of block the editor can insert, like core/group or a plugin's pricing table. Synced blocks are saved pieces of content you reuse across pages, and the List blocks ability covers those.
Why would an agent need this?
An agent that writes a page with a block your site does not have gets a block that will not render as that block. Reading the registered list first means it builds only with blocks that exist, and with the attributes they really accept.