Repository navigation
Skills in a WordPress admin context #430
Description
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:
Activity
justlevine commentedon Apr 15, 2026
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
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 commentedon Apr 15, 2026
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 commentedon Apr 16, 2026
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 commentedon Apr 16, 2026
Totally. Ideally ever skill is accompanied by an eval to verify its effectiveness.
jeryj commentedon Apr 17, 2026
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 commentedon Apr 27, 2026
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/orskill-blocks/{slug}-post) and dispatches throughwp_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:
block_types/post_typesas part of the skill record makes the UI surfacing trivial.permission_callback, so an agency can ship locked-down skills for specific roles.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 commentedon Apr 27, 2026
I'm actively working on evolving Guidelines CPT to support skills:
Initial refactoring that adds support for custom guideline types:
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:
gziolo commentedon Apr 27, 2026
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:
AGENTS.mdin projects orinstructionsin AI clients.justlevine commentedon Apr 27, 2026
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
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.
(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).