WordPress Agent Skills: From Figma Design to Block

An AI assistant can write decent WordPress code, but without guidance it often writes generic code. WordPress agent skills fix that. They are small sets of instructions that tell the assistant how WordPress developers actually work. This week I added the official ones to my setup and mapped out how I use them to turn a Figma design into a WordPress block.

Here is what I learned, including one thing that tripped me up.

1. What WordPress agent skills actually are

A skill is a folder. Inside is a SKILL.md file that says when to use the skill, what inputs it needs, the steps to follow, and how to check the result. Many skills also have a references folder with short guides and a scripts folder with small helper tools.

The WordPress project publishes an official set in the WordPress agent-skills repository on GitHub. It covers blocks, block themes, plugins, the REST API, the Interactivity API, performance, WP-CLI and WordPress Playground. The block development skill in that repo targets WordPress 7.0 and PHP 7.4.

2. Copy the whole folder, not just SKILL.md

This was my mistake. I first tried adding skills by saving only the SKILL.md text. That works, but the references and scripts folders get left behind. The main file keeps pointing to guides that are no longer there, so you get a thinner skill.

You have two options, and each has a cost:

• Copy the whole folder. You keep every guide and script. You need a place that loads full folders.
• Merge the key guides into one file. It is easy to save and share. You lose the helper scripts and some detail.

My rule is simple. If a skill runs scripts, like the project triage and router skills, I keep the full folder. If a skill is mostly advice, I fold the short guides into one file.

I also stopped using my old local copies. They targeted WordPress 6.9. The official repo had already moved on to 7.0. Pulling from the source keeps the advice current.

3. Which skills to use for Figma to block

Order matters here. I use four skills, one after the other:

1. A Figma design-to-code skill. It reads the design: layout, spacing, colors and type. The result is a reference, not final code.
2. The block development skill. It turns that reference into a real block. It covers block.json, apiVersion 3, static versus dynamic blocks, attributes and inner blocks.
3. The block themes skill. If the design is a full section or page, colors, fonts and spacing go into theme.json. Layouts become patterns or templates.
4. The Interactivity API skill. Only for sliders, tabs, accordions and other moving parts.

Each skill has one job. That keeps the assistant from guessing, and it keeps me from re-explaining the same rules in every chat.

4. The workflow, step by step

This is the flow I follow. It builds on my Figma to WordPress front-end workflow.

1. Share the Figma link with the exact frame selected. The assistant pulls the design details and a screenshot.
2. Treat the output as a reference. It is not code to paste. I adapt it to the site's own tokens and components.
3. Pick the block type. Fixed content is a static block. Content that changes, like a post list, is a dynamic block with render.php. Anything that moves needs the Interactivity API.
4. Scaffold, don't hand-roll. I start with @wordpress/create-block. It sets up the folder structure the right way.
5. Move brand values into theme.json. Colors, type scale and spacing live there, not inside the block.
6. Verify. Insert the block, save the post, reload the editor and confirm there is no "Invalid block" message. Then check the front end.

For a real example of the design side, see my Figma to WordPress with Elementor case study.

One more tip: after each step, ask the assistant to name the file it changed and why. It is a quick way to catch a wrong guess before it spreads.

5. Pattern or custom block?

This is the tradeoff I think about most.

A custom block gives you full control over the markup and behavior. It also costs more to build and to maintain. You must handle updates and keep old content valid.

A pattern built from core blocks is much faster. Your client can edit it with no code, and there is less to break.

For most client sites I start with patterns. I only build a custom block when core blocks cannot do the job, such as a layout that reads live data or needs special logic.

6. Mistakes to avoid

• Changing a block's name. Treat the name as a fixed ID. Renaming it breaks existing content.
• Changing saved markup with no deprecated entry. This causes the "Invalid block" error on old posts.
• Staying on apiVersion 2. Use version 3 so the block works in the iframe editor.
• Hardcoding colors and fonts. Put them in theme.json so the whole site stays consistent.
• Forgetting that user edits win. If your theme.json change seems ignored, a saved Site Editor customization may be overriding it.

Want this kind of workflow on your site?

If you want a design turned into clean, editable WordPress, see my WordPress development services. I also set up AI-assisted development and automation to speed up builds like this. When you are ready, get in touch and tell me about your project.