# Abilities API for Humans ## Lingering Questions - Does WordPress core reject or warn on a second registration attempt into an existing ability namespace, or does "namespace jacking" silently fail/overwrite? - What filter parameters does the reportedly-landed `WP get abilities()` discovery filtering actually expose, and do they cover ecosystem-level "which installed plugins have an ability that does X" discovery? - Will the Abilities API get an official, versioned deprecation/breaking-change policy at the schema level? ## Article Ideas - A "your first ability" walkthrough (CPT CRUD → ability → REST thin-wrapper) modeled on SkyVerge's stated one-week migration pattern. - An FAQ built from this talk's Q&A specifically on the security-layering confusion (ability permissions callback vs. REST/CLI-specific auth). ## Cross Reference - Directly extends the existing Abilities API note cluster: [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] (how an ability should be shaped), [[3. Resources/Permanent Notes/Caller Distance Determines the Right WordPress Interface]] (which layer to choose), and [[3. Resources/Permanent Notes/Agent-Readable Data Is Becoming the Default Plugin Integration Surface]] (adoption breadth) — this talk adds the *plugin-author's architecture pattern* once an ability layer is chosen: build once, thin-wrap per surface. ## Fiction & Worldbuilding - None. ## Vocabulary - **Ability**: a namespaced, four-part contract (name, input schema, output schema, callback) registered in a site-wide discoverable registry. - **Namespace jacking**: a plugin deliberately registering an ability into another plugin's namespace. - **Orchestrator plugin**: a plugin (e.g., Baton) that discovers and chains other plugins' abilities into workflows without custom integration code. ## Bib capsule Nick McLoughlin (SkyVerge; self-appointed Abilities API evangelist for WordPress Core AI), WordCamp US talk (YouTube, captured 2026-08-19). Argues WordPress 6.9's Abilities API is a general-purpose capability registry, not primarily an AI gateway, and demos "Baton," a workflow-orchestrator plugin chaining WooCommerce and SkyVerge abilities. ## Author's thesis **What is the talk about?** McLoughlin argues the Abilities API shipped in WordPress 6.9 is a general-purpose, discoverable capability registry for the whole platform, not an AI-specific side-quest — correcting what he identifies (via an audience show-of-hands) as the dominant misreading. **How does he develop it?** He walks through the spec (name, input schema, output schema, callback), names the problems in current plugin architecture it solves (monolithic plugins, "class drilling," duplicated per-interface logic, ambiguous public-method contracts), proposes a "new plugin architecture" pattern (write core logic once as an ability, expose thin adapters to REST/CLI/admin/MCP/LLM), and closes with a live demo of Baton — a prototype orchestrator that chains WooCommerce and SkyVerge abilities into two workflows with zero custom integration code, including two unscripted live failures he treats as evidence the schema validation and permissions actually enforce constraints. ## Key arguments - Abilities are a standardization layer, not new capability — the same category of agreement hooks already provide for data manipulation, abilities now provide for calling functions. - Abilities should become the "nucleus" of a plugin's business logic, with REST/CLI/admin/MCP/LLM built as thin, once-written adapters on top — not a parallel AI-specific integration layer. - The abilities layer only guarantees a per-ability permissions callback; REST/CLI-specific auth and other surface-specific security controls still have to be built separately at each layer. ### Abilities give WordPress a standard function-call interface > [!quote] ID:rw_atom1 > "abilities give us a standard agreed upon interface to call each other's functions" Mid-talk, the "hooks-to-abilities" analogy segment — the core conceptual claim the whole talk (new plugin architecture, Baton demo) is downstream of. ### The abilities layer only guarantees a permissions callback, not full security > [!quote] ID:rw_atom2 > "the abilities API is really focused on defining that core... but then those additional pieces kind of come at that layer" Q&A response to the audience question about whether abilities include REST-style security "for free." Corrects a plausible false assumption that registering an ability is sufficient security coverage on its own. ### Registering an ability does not auto-expose it to any surface > [!quote] ID:rw_atom3 > "it's not automatically in any of those places" Q&A exchange with Dave (Ultimate Multi-Site) confirming abilities are opt-in per access surface, with the MCP adapter plugin as a partial exception. Useful for anyone scoping an abilities migration. ## Permanent candidates - Atom 1 (abilities as the plugin's core nucleus, everything else a thin wrapper) warrants a Permanent Note — it's a distinct, prescriptive architecture-pattern claim (what to build once, and where) not already covered by the vault's existing Abilities API cluster, which covers ability *shape* (consumer-neutral design), *interface choice* (caller distance), and *adoption breadth* — none of which state this specific "core + thin adapters" pattern. - Atoms 2 and 3 are useful, concrete Q&A clarifications but read as documentation/implementation gotchas rather than durable, generalizable claims — not spun into separate Permanent Notes. ## Links - [[3. Resources/Permanent Notes/An Ability Is the Plugin's Core, Every Surface Is a Thin Wrapper]] — the permanent form of this talk's central architecture pattern: build the ability once, thin-wrap it per surface - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — how an ability should be shaped so it isn't just a REST endpoint in disguise - [[3. Resources/Permanent Notes/Caller Distance Determines the Right WordPress Interface]] — which layer to choose before you reach for an ability at all - [[3. Resources/Permanent Notes/Interface Surface Area Costs Selection Accuracy Not Just Tokens]] — the scaling limit this pattern runs into: every registered ability is surface an agent pays for and must choose among - [[3. Resources/Permanent Notes/A Declared Capability Costs You Every Turn Not Every Use]] — the token cost of a growing ability registry, which the "register everything, discover it later" model doesn't price - [[3. Resources/Readwise/Articles/The New MCP Roadmap|The New MCP Roadmap]] — the same discovery problem being solved one layer up, via progressive disclosure of a server's catalogue - [[3. Resources/Readwise/Articles/What’s New With Woo|What's New With Woo? (July 2026)]] — Woo extending MCP abilities across all its extensions, which is exactly the registry-growth case that makes discovery filtering load-bearing - [[3. Resources/MOCs/Events/WordCamp US 2026 MOC]] — applies-in: the MOC lists this note under 🤖 AI in Practice — Judgment Over Hype. ## Processing checklist - [ ] Look up the wordpress.org-listing Trac ticket for plugin abilities visibility referenced in this talk's Q&A. - [ ] Check WordPress 6.9+ changelog for the `WP get abilities()` discovery-filtering feature confirmed in Q&A. - [ ] Link Permanent Note into MOC(s) per orchestrator sweep.