If you’ve used Claude, Cursor, or ChatGPT to build WordPress blocks, you know the moment: you point the AI at a button in the Block Editor and say “change this.” The AI sees a <button> with some CSS classes. It tries its best. It guesses wrong.

It has no idea whether that button lives in your block’s Edit component, a shared InspectorControls panel, or some nested InnerBlock three levels deep.

I kept hitting this in my work on the PDF Embedder plugin, so I built wp-block-grab — a dev tool that gives AI agents actual WordPress-aware context for whatever you click in the editor.

Agentation and react-grab both do a good job identifying React components and CSS selectors in standard React apps. Gutenberg is not a standard React app.

Generic tools don’t know which block.json an element belongs to. They can’t tell Edit from Save. Click a toggle in the Inspector Sidebar and they see a generic checkbox, not a PanelBody control tied to a specific attribute. The Site Editor and Post Editor also wrap content in iframes, which breaks most standard selectors.

So you end up manually grepping your codebase for file names, or burning several AI turns just to find the right place. At that point, what’s the AI actually saving you?

Instead of a CSS selector, it gives the AI a full WordPress-aware map of whatever you clicked.

A custom Babel plugin injects the source file and line number into your JSX elements during development, so the AI knows exactly which file to open. The tool also queries the internal core/block-editor data stores — so instead of seeing a div, it sees “the primary wrapper of the core/group block inside a my-plugin/hero block.” If you’re in the settings panel, it identifies the specific control and which attribute it maps to.

There’s also an intent field. Before copying, you type what you want changed — something like “Make this button’s background use the theme’s primary color” — and that gets bundled with all the technical context into one prompt.

Here’s actual output from the demo:

<source_context>
Intent: add a new number input field after this component called "Pages Gap" with a default value of 10
Location: plugins/pdf-embedder-premium/block/basic/src/slots/pages-scroll.js:10 (<TextControl>)
Component path: __WEBPACK_DEFAULT_EXPORT__ > PanelBody > TextControl > BaseControl > Styled(div)
Block: pdfemb/pdf-embedder-viewer
Panel: Pages & Scrolling
Control: Default Page (number, current: 1)
Clicked: div.components-base-control__field.ab--b-dce-aaae-1t5ousf.ej5x27r3
</source_context>

File, line, block hierarchy, sidebar context, and what you want changed. Paste that into your AI and skip explaining your project structure.

Install the library:

npm install wp-block-grab --save-dev

And replace your start script in package.json:

{
  "scripts": {
    "build": "wp-scripts build",
    "start": "wp-block-grab start"
  }
}

If you use wp-block-grab build command — it’s a clean pass-through to wp-scripts directly — no tracking code in production. The start command is where the magic happens.

In the Block Editor, hit Cmd+Shift+S (or Ctrl+Shift+S on Windows/Linux), click any element of your block, type what you want to change, and paste the output into your AI. That’s it.

I’ve been using this on a premium plugin that extends a free one via Slots — the kind of thing where the AI would normally spend three rounds just figuring out the file structure. This cuts that entirely.

You can find wp-block-grab here:

• GitHub: https://github.com/slaffik/wp-block-grab
• NPM: https://www.npmjs.com/package/wp-block-grab
• MCP via Context7: https://context7.com/slaffik/wp-block-grab

If you try it out, I’d love to hear what works and what doesn’t. This is still early, and feedback from real block development workflows is exactly what I need.