WordPress Just Released Official AI Agent Skills. Here's What It Means for Security.

The WordPress project has quietly published an official repository of AI coding-assistant skills at github.com/WordPress/agent-skills. It's a set of instruction bundles you can drop into Claude Code, Copilot, Cursor, Codex or any other assistant that supports project-level instructions, and it tells the assistant how to build WordPress the right way. Licensed GPL-2.0. Generated by GPT-5.2 Codex from official WordPress documentation, then reviewed by WordPress contributors. Roughly half of every "my WordPress site got hacked" story I've heard traces back to a vulnerable custom plugin, which is why the WordPress project publishing this matters here.

Short version, if you want it up front: this raises the floor for AI-written WordPress code, especially around nonces, capability checks, and input sanitisation. It does not remove the need for a human review of what the assistant produces, and it does not do anything for the plugins that are already on your site. It's a build-time tool, not a runtime one.

What it actually is

"Skills" in this context are portable instruction packs. Each one is a folder of markdown and a manifest that describes when the assistant should load it and what it should follow when it does. A skill is not a tool the assistant runs. It's a set of rules the assistant reads and then applies when it writes code for you.

The current line-up in the repo is:

wordpress-router - Classifies the repo you're working in and routes the assistant to the right skill for the job.
wp-project-triage - Auto-detects the project type, tooling, and WordPress and PHP versions.
wp-plugin-development - Plugin architecture, hooks, the settings API, security patterns.
wp-block-development - Gutenberg blocks, block.json, attributes, rendering, deprecations.
wp-block-themes - Block themes, theme.json, templates, patterns, style variations.
wp-rest-api - REST routes, endpoints, schema, authentication, response shapes.
wp-interactivity-api - Front-end interactivity with the data-wp-* directives.
wp-abilities-api - Capability-based permissions and REST authentication.
wp-wpcli-and-ops - WP-CLI commands, automation, multisite operations.
wp-performance - Profiling, caching, database optimisation.
wp-phpstan - PHPStan static analysis rules for WordPress projects.
wp-playground - WordPress Playground for local environments.
wp-plugin-directory-guidelines - Compliance with the plugin directory's rules.
wpds - The WordPress Design System.
blueprint - Playground blueprints for repeatable environments.

The router-plus-triage pattern is worth flagging. Instead of loading every skill on every request, the assistant runs wordpress-router first, works out whether you're in a plugin, a block theme, a Playground environment or something else, then loads only the skills that apply. In practice this means the model isn't wading through fifteen thousand tokens of block-theme guidance while you're fixing a REST endpoint.

Minimum requirements are WordPress 7.0 and PHP 7.4.0, which covers essentially every currently-supported site.

The security angle nobody's writing about

The single most common way a WordPress site gets compromised is a vulnerable plugin. I've said that in the WordPress vs Wix comparison, and it holds every time you look at the incident data. Not core. Not the host. A plugin.

There are two flavours of that failure. The first is plugins from other people, which is a supply-chain problem covered in a separate post on the plugin backdoor incident. The second is plugins built by you, or by a developer you hired, and this is the flavour agent-skills addresses.

AI-written WordPress code has a very consistent set of security bugs. If you've read enough of it, you know what they are before you open the file:

Direct $_POST reads with no sanitize_text_field() or wp_unslash() on the way in.
SQL built by string concatenation instead of $wpdb->prepare().
Form handlers with no wp_verify_nonce() on the incoming request.
Admin endpoints with no current_user_can() check gating them.
esc_html() and esc_attr() used inconsistently or not at all on the output.

These are not exotic bugs. They're the WordPress version of "did you remember to lock the front door". A senior WordPress developer would flag every one of them on a code review in seconds. But a general-purpose AI assistant, given the prompt "write me a plugin that lets users submit their email address to a form", will absolutely produce code with two or three of these problems. It looks reasonable. It works when you test it. Six months later you find out someone was using the endpoint to inject rows into your database.

The wp-plugin-development and wp-abilities-api skills push the assistant toward the correct patterns by default. They tell it to use prepared statements, verify nonces, check capabilities, and sanitise input before it writes the first line. That is a real floor-raise, and floor-raises matter more than ceiling-raises on a platform where most compromise is entry-level mistakes.

If you or a developer you're paying is writing plugin code with an AI assistant, and you haven't set this up, you are shipping worse code than you have to.

What it doesn't do

Agent-skills doesn't audit existing code. If you've got fifty plugins on a site already, this repo does nothing for you. It's build-time only. If you want to know whether your current plugins are safe, you're still looking at file permissions, database hygiene and monitoring, plus the plugin-audit techniques in the handbook.

It doesn't understand your specific threat model. The skills describe general good practice. They don't know that your form endpoint is public-facing and rate-limited by nothing, or that your custom REST route is called from an unauthenticated JavaScript widget on the front-end. Those are things the human doing the review has to notice.

It doesn't stop the assistant making a plausible-looking-but-wrong choice. Skills describe patterns, not proofs. If the assistant picks the wrong nonce action name, or applies current_user_can('read') where you meant current_user_can('manage_options'), the code will look correct. It will pass the skill's guidance. And it will still be wrong for your specific case.

The skills themselves were generated by an LLM from documentation, then reviewed by WordPress contributors. That's a genuine improvement over unreviewed AI output. It is not the same as being hand-written from scratch by a WordPress core security lead. The review is the thing carrying the credibility, not the fact that the WordPress org's name is on the repo. If a bug ships in a skill, the assistant will happily reproduce that bug in every project that loads it.

None of this is a reason not to use it. It's a reason to keep the human in the loop, which is the same thing you should have been doing anyway.

How to use it if you're security-conscious

Three practical points, in the order you'd actually do them.

Install it globally if you touch WordPress often, project-scoped if you're evaluating. Global lives at the assistant's user config; project-scoped drops the skills inside a specific repo. The repo README gives you both commands. If most of your work is WordPress, global is the right default and stops you forgetting to enable it on new projects.
Still run the code past a human who understands nonces and capabilities. Even with the skills loaded, review the specific decisions: is the nonce action name unique to this form, is the capability check the right one for who should be allowed in, is every input sanitised on the way in, is every output escaped on the way out. Agent-skills gets you a much better first draft. A human still ships the last mile.
Treat it as a starting posture, not the whole review. The skills describe good general practice. They don't know your project. Layer your own rules on top, in a project-specific instructions file if your assistant supports one, covering the things specific to what you're building. If you're not sure what those things are, the file-permissions and database post covers the classes of check a human reviewer should still be running.

If you're commissioning custom plugin work from a developer, "use the WordPress project's official agent-skills bundle if you're using AI assistance" is now a line you can put in the brief and expect them to actually be able to do.

Where this fits

The Protect My WP handbook is about running WordPress safely once it's built. Chapter 8 covers plugin and theme hygiene from the consumer side: how to vet plugins you install, how to spot the ownership transfers and abandonments that turn a safe plugin into a vulnerable one, and how to keep the ones you do have installed up to date. Agent-skills addresses the flip side, which is how plugins get built in the first place, and it's a genuinely welcome addition to that half of the picture.

If you're the person writing the plugin, or paying someone else to, the two halves fit together neatly. Build it with the right defaults using agent-skills. Vet, monitor and maintain it using the practices in the book. Neither half is a substitute for the other, and the whole point of a security posture is the layers.

If you're running WordPress and you want the specifics of how to keep it hardened rather than just "hardened enough", the book is where those specifics live. How to harden WordPress is the shorter free walkthrough if you're not ready for the full handbook yet.

Get the book for £19.