Skills in a WordPress admin context

[swissspidy]

It's all about skills these days: modular capabilities that can be passed as context ad-hoc. Great for domain-specific task and repetitive workflows. Let's discuss how they could fit into WordPress.

Off the top of my head, a Command Palette integration would be quite obvious: Just as you search for "Add New Post," you can trigger skills like /audit-accessibility or /rewrite-for-experts.

How would an agency set up reusable skills for clients? How would plugins provide skills? How could a user create their own?

Related:

• Abilities & Workflows Overview gutenberg#70710
• Agent Skills in Claude Code
• Even Chrome now supports skills
• Content Guidelines experiment

[justlevine]

I'd love to explore this. There's a lot of both conceptual and technical considerations that would need to be sorted out.

First one that comes to mind: What sort of skills are we talking? If it's just reusable prompts, or even context lakes, then it's doable even if Skills as a spec isnt the ideal tool for the job. Bundling scripts for tool use (where Skills really shine) would probably be a blocker, and if you can already write abilities, then you probably prefer something more deterministic like a Workflow than a prompt.

Also, if you do mean actual (agent) skills and not just reusable prompts

a Command Palette integration would be quite obvious: Just as you search for "Add New Post," you can trigger skills like /audit-accessibility or /rewrite-for-experts.

For vanilla CP, I think it might make sense to just show a semantic name of the reusable prompt/skill instead of a slash command e.g. "Audit Accessibility" . Prefix symbols are to identify and capture commands in text, so IMO it only makes sense if CP gets a chat mode, especially if it's just a reusable prompt library and not real, harnessable skills.

[swissspidy]

Yeah we probably need to separate the two. Plugins/Devs could define full-fledged agent skills with script execution, users could just save reusable prompts/workflows/context. Could even treat skills as a type of plugin that can be installed from the directory etc.

[gsarig]

I wonder if there should be some kind of a "skills linter", to prevent creating poorly written skills (e.g. set some specific standards) or prompts that doesn't make much sense to be considered as skills, or even skills that conflict with other, already enabled skills from core or 3rd-party plugins.

[swissspidy]

Totally. Ideally ever skill is accompanied by an eval to verify its effectiveness.

[jeryj]

I'm poking around on what's possible with WP AI right now. One issue I ran into is adding site-specific scripts. For example, I might build a plugin that has some bundled skills, but I need a user level skill on top of it to fine tune the results. At the moment, I don't see a way to add my own site-level script.

[derseitenschneider]

Sharing a small experiment that might be useful as a data point for the "reusable prompts" end of this discussion: Skill Blocks.

It's a Gutenberg plugin where a "skill" is a CPT-stored prompt with a scope:

Block scope
Runs from the block toolbar against the selected block (e.g. "Polish this paragraph"). Result shows in a popover with Insert/Close.

Post scope
Runs from a "Skills" panel in the document sidebar against the whole post, in one of three modes:

• rewrite_blocks — model returns a JSON envelope of {id, text} per rewriteable block, user reviews a per-block word-level diff and applies selected changes (single-undo).
• set_title / set_excerpt — sidecar review (current vs. new), Accept/Reject.

Each skill registers as a WP Ability (skill-blocks/{slug} and/or skill-blocks/{slug}-post) and dispatches through wp_ai_client_prompt(), so the plugin itself never touches providers or keys — that's all delegated to the AI plugin + Connectors.

A note on the local-model pathway
The first cut of this plugin actually didn't go through providers at all — it ran inference entirely in the browser via Transformers.js (Qwen2.5-1.5B-Instruct, then Gemma 4 E2B once that landed in April with day-one Transformers.js + WebGPU support). The pivot to the WP AI Client was pragmatic: today's small models are fast and free, but the ~1.5 GB download, WebGPU-only baseline (no usable WASM fallback yet), and quality gap on rewrite tasks made it the wrong default for a v1 user-facing plugin. Notes from that exploration are in docs/research/gemma-models.md.

But the trajectory is obvious: models keep getting smaller and better, browsers are catching up on WebGPU/WebNN, and the day a 500 MB-class model can run a "polish this paragraph" skill at acceptable latency on a mid-range laptop is probably closer than it looks. When that day arrives, a "skill" that's really just (prompt + scope + structured output schema) is exactly the kind of shape that can transparently swap a Connector for a local provider — which feels like a useful design constraint to bake in now. A local-model provider as a sibling to the OpenAI/Google/Anthropic Connectors (registering as a custom WP AI Client provider) seems like the right seam, rather than something baked into the skill UI itself.

Things that might be worth pulling forward
Picking up on @justlevine's distinction: this lands firmly in the "reusable prompt library" bucket, not full agent skills with scripts. But it's been interesting to see how much you can get out of just (prompt + scope + structured output schema + diff review UI) — particularly the per-block diff for whole-post rewrites, which lets users keep the model on a leash without having to trust it wholesale.

A few things that might be worth pulling forward into a core design:

1. Scope as a first-class concept. A skill that makes sense on a paragraph rarely makes sense on a whole post - having block_types / post_types as part of the skill record makes the UI surfacing trivial.
2. Structured output + review UI as part of the skill contract. For anything destructive (rewriting blocks, replacing the title), a diff/sidecar review beats raw insertion every time.
3. Per-skill capabilities. Each ability gets its own permission_callback, so an agency can ship locked-down skills for specific roles.
4. Provider-agnosticism by construction. Going through the AI Client meant the same skill works against OpenAI, Google, Anthropic — and will work against an in-browser provider the moment one ships, with zero changes to the skill itself.

Happy to chat more if any of this is useful — and curious whether the eventual core design wants to keep "reusable prompts" and "agent skills with scripts" under one umbrella or split them, per the thread above.

[gziolo]

I'm actively working on evolving Guidelines CPT to support skills:

• Guidelines built on Knowledge in WordPress 7.1 gutenberg#77230

Initial refactoring that adds support for custom guideline types:

• Guidelines: Extract initial public API methods gutenberg#77643

Off the top of my head, a Command Palette integration would be quite obvious: Just as you search for "Add New Post," you can trigger skills like /audit-accessibility or /rewrite-for-experts.

Skills seem to be very similar to workflows. Maybe it's even easier at this point to go the route you are proposing, as it's closer to how AI usage looks. We can start simple and offer skills that provide instructions, but in practice, this could quickly evolve into more sophisticated system:

• plugins could list available functions that can be referenced in skills
• WP AI Client supports tool calling, so skills could reference abilities/tools, too
• with sandboxed execution, you could even allow running arbitrary code linked to the skill

[gziolo]

One more related thought after I saw the Guidelines integration demo in the AI plugin in What’s new in AI 0.8.0 (23 APR 2026)? post:

https://videopress.com/embed/tOyQJvXa

Looking into how @saarnilauri implemented it, I have two observations:

• "Site" guideline is always loaded, so it can be treated like AGENTS.md in projects or instructions in AI clients.
• "Copy" and "Images" guidelines are loaded only in a specific context, so they can be treated like Skills.

[justlevine]

Scope as a first-class concept. A skill that makes sense on a paragraph rarely makes sense on a whole post - having block_types / post_types as part of the skill record makes the UI surfacing trivial.

Not entirely sold on this one part, but mostly because I'm having trouble visualizing what such an abstraction would look like - and how it could scale - on the API level. Conceptually our "Agent Skills" inspo deals with telling LLMs how to do something like call a specific ability to handle certain tasks, so it seems more naturally that scope lives on the ability, whereas our version of skills would more hold visibility and permissions, on top of the usual o11y

Skills seem to be very similar to WordPress/gutenberg#70710. Maybe it's even easier at this point to go the route you are proposing, as it's closer to how AI usage looks.

FWIW the way I've been devsplaining this issue is as "natural language workflows", hoping it would obviate the need for something like 👆

I've raised my apprehensions elsewhere (not sure where, can't ever seem to track anything once it crosses streams with the GB repo) about how visual workflow building is sooo far beyond the scope of anything and everything in WP, so should be relegated into its own plugin (and not even as a GB experiment). So I may be a little biased. But this does seem to serve the same need, feel like a natural extension of the Core AI work we're trying to do, and more natural compliment to a core CMS than visual workflow automation.

• "Site" guideline is always loaded, so it can be treated like AGENTS.md in projects or instructions in AI clients.
• "Copy" and "Images" guidelines are loaded only in a specific context, so they can be treated like Skills.

(Confirming the "like AGENTS.md" and "like Skills`" is intentional and because we recognize they are not necessarily technically identical, just serving similar needs. I don't think this needs clarifying with the folks currently on this ticket, but as we're losing the broader organizational battle for LLM literacy i want to be extra sure).