Abilities API for Humans  🔗 **Source:** [Abilities API for Humans](https://www.youtube.com/watch?v=vSbdtpAhROs#transcript) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > tags: [wordpress-abilities-api, plugin-architecture, developer-tools, woocommerce, wordcamp-us] > author: Nick McLoughlin (SkyVerge) > source: WordCamp US (YouTube) > reference: https://www.youtube.com/watch?v=vSbdtpAhROs > date created: 2026-08-19 > > # 🏷️ Title: Abilities API for Humans > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WordPress 6.9 Abilities API](https://make.wordpress.org/core/) — the platform feature this talk is built on - Baton (Nick McLoughlin's workflow-orchestrator plugin) — referenced as "just on GitHub," no direct URL given in-talk - WooCommerce Order Query and Add Order Note abilities — referenced by name, no URL given - SkyVerge Print Invoices & Packing Lists extension — referenced by name, no URL given ## 📝 Summary - **What happened.** Nick McLoughlin (SkyVerge; self-appointed Abilities API evangelist for the WordPress Core AI team) gave a WordCamp US talk arguing the Abilities API shipped in WordPress 6.9 is not primarily an "AI gateway" but a general-purpose, discoverable capability registry for the whole platform. He walked through the spec (name, input schema, output schema, callback), the problems it solves in current plugin architecture (monolithic plugins, "class drilling," duplicated per-interface logic), proposed a "new plugin architecture" pattern (write core logic once as an ability, expose thin adapters to REST/CLI/admin/MCP/LLM), showed a slide of companies/plugins already adopting it, and closed with a live demo of Baton, a prototype workflow-orchestrator plugin that chains WooCommerce and SkyVerge abilities (query orders → filter → add order note; query orders → filter → send pick-list email) without writing any custom integration code between the plugins. - **Why it matters.** WordPress plugins today routinely duplicate business logic across REST endpoints, CLI commands, and admin UI, and third-party integrations require reverse-engineering undocumented public methods or brittle class chains. A standardized, self-describing, namespaced ability registry — enforced by JSON Schema input/output validation and a required permissions callback — turns "read the code to guess the contract" into "call `WP get abilities()` and inspect the schema." That is a structural, ecosystem-level change to how WordPress plugins interoperate, not just a convenience for AI agents. - **Key stakeholders.** WordPress Core AI team (drove initial development); plugin/theme developers (SkyVerge, Leaky Paywall, Ultimate Multi-Site were named or asked questions from the audience); WooCommerce (supplies read and write abilities Baton consumes); Abilities API core maintainers (David, audience member, confirmed a discoverability-filtering feature request is already landed); WordPress.org Plugin Directory / Meta team (a Trac ticket exists, per McLoughlin, for surfacing a plugin's registered abilities on its .org listing page, though it doesn't exist yet); end users/merchants (ultimate beneficiaries of cross-plugin workflows like Baton's WooCommerce automation). - **Risks and tradeoffs.** (1) Adoption dependency — the ecosystem-level payoff (McLoughlin's "seamless interoperability") only materializes if plugins and themes actually register abilities; today the barrier is explicitly named as adoption, not the API's readiness. (2) Security is layered, not centralized — McLoughlin was direct in Q&A that the abilities layer only guarantees a per-ability permissions callback; REST-specific auth, nonces, and other surface-specific security controls still have to be implemented separately at each access layer, which is a common point of confusion he flagged. (3) Namespace collision risk — abilities are namespaced per plugin, so accidental duplicate registration is unlikely, but McLoughlin acknowledged a plugin could deliberately target another's namespace ("namespace jacking"), which he characterized as hostile-actor territory rather than a solved problem. (4) Discoverability gaps at the ecosystem level — no way today to see what abilities a plugin registers before installing it (a Trac ticket exists but is unshipped), so evaluating "does this plugin have the abilities I need" still requires installing it first. (5) The demo itself failed once live (invalid JSON from a stray comma) and once more the second demo transaction was blocked by WooCommerce's own "store not live" safeguard — presented candidly as evidence the tooling enforces its own schema validation rather than as an embarrassment. - **Bottom line.** The Abilities API is positioned as WordPress's new default "plugin atom" — the standardized, inspectable core that every access surface (REST, CLI, admin UI, MCP, LLM) should be built as a thin wrapper around, rather than one more parallel integration layer bolted onto AI use cases specifically. McLoughlin's practical advice to builders: start by turning your plugin's custom-post-type CRUD and any bespoke cross-service workflows (e.g., calling an external API with order data) into abilities, because the same core functions can then power your REST API, CLI, and any future MCP/agent surface without rewriting logic per surface. ## 📖 Main Content - **Core definition.** The Abilities API provides "a central registry on every WordPress site where the site's capabilities are registered" — discoverable and interoperable, sourced from plugins, themes, snippets, or core itself, all in one standard place. WordPress 6.9 shipped it. Each ability has exactly four parts: a name, an input schema, an output schema, and a callback function. - **Not fundamentally new — a standardization layer.** McLoughlin is explicit that abilities don't introduce new capability; WordPress developers already call each other's functions and APIs constantly. What's new is a shared, ecosystem-wide agreement on what "well-formed" exposure looks like — the same category of standardization hooks already provide for data manipulation and side effects, abilities now provide for calling functions. - **Problems in the pre-abilities status quo.** He frames current plugins as effectively "monolithic": each one embeds unique architectural decisions a newcomer has to reverse-engineer. Symptoms named specifically: repeated core logic rewritten per interface (REST, CLI, admin); "class drilling" through long singleton chains just to reach one public method; and ambiguous public function signatures (is this parameter an object or an ID? does this return an array or a string?) that force developers to read source rather than a contract. - **The fix, mechanically.** Consumption is three pieces: `WP get abilities()` (discover all), `WP get ability()` (retrieve one), and an execution method on each ability whose inputs/outputs are validated against its JSON Schema automatically, plus a required permissions callback that runs on every execution. McLoughlin calls this "a cable management standard for our spaghetti code." - **The "new plugin architecture" pattern.** His central prescriptive claim: abilities should become the nucleus of a plugin's business logic, with REST, CLI, admin, MCP, and LLM access all built as thin adapters on top of that same core — "write once, expose to REST/CLI/admin/MCP." He explicitly warns against treating abilities as "just another REST API" or "just another CLI" bolted on for AI — that framing misses that abilities are meant to be the thing those surfaces point to, not a peer layer alongside them. - **Ecosystem-level payoff (aspirational, adoption-gated).** At full adoption, McLoughlin argues WordPress moves toward "seamless interoperability" — plugins and themes able to discover and consume each other's functionality via explicit, versioned contracts, replacing today's undocumented public-method archaeology. He frames the current 40-plugin WordPress site as "spoiled for functionality" but poorly integrated, and abilities as the mechanism for actually stringing that installed functionality together. - **Adoption evidence.** He showed (without naming all attendees or providing a source list in the transcript) a slide of companies/plugins he says are already building on the Abilities API, stating he is not sponsored by any of them and is actively soliciting more examples at the WordCamp "Core AI prompt bar." - **Demo: Baton.** A self-built, GitHub-hosted, prototype "workflow orchestrator" admin UI plugin. It pulls every registered ability on the site (grouped by namespace/source), lets the user chain them into steps with a data-filter layer to reshape one ability's output into the next ability's input, and loop over arrays. Two workflows demoed: (1) WooCommerce order query (filtered to "processing" status) → filter to order IDs → WooCommerce add-order-note ability, looped over each ID; (2) the same order query → filtered output → SkyVerge's Print Invoices and Packing Lists extension's "send document by email" ability, looped to email pick lists to a warehouse address. The first run failed on invalid JSON (a stray comma) and succeeded on retry; the second was blocked by WooCommerce's own "store not live" (coming-soon mode) safeguard, which McLoughlin treated as further proof the abilities and their consuming plugins enforce real validation, not just a hollow demo. - **Q&A themes** (see Notes below for per-question detail): prioritization heuristics for which functionality to expose as an ability; where security/auth responsibility sits relative to the ability layer; the Abilities API core team's own roadmap wishlist (discovery filtering — confirmed already shipped per an audience exchange with a named core maintainer, "David"); whether/when plugin abilities will be visible on the WordPress.org plugin directory listing (not yet, but a Trac ticket exists); whether abilities can collide across plugins (namespaced, so only deliberate namespace-targeting is a real risk); whether registering an ability auto-exposes it to REST/CLI (no — opt-in per surface, MCP adapter plugin being a partial exception); and whether existing full-CRUD REST endpoints should be rewritten to consume abilities underneath (yes, per SkyVerge's own migration of their memberships REST API). ### 🗒️ Notes #### ⏱️ Opening / framing - McLoughlin's role: support engineer, product manager, general manager at SkyVerge; self-appointed Abilities API evangelist for the Core AI team; runs "Plugin Jam," a WordPress-builder hackathon. - Audience show-of-hands suggested most attendees who'd heard of the Abilities API associate it with AI in WordPress specifically — which he identifies as the framing he's trying to correct/expand in this talk. #### ⏱️ Definitions and mechanics - Central registry: discoverable, interoperable, sourced from any WordPress code (plugins, themes, snippets, core). - Four-part ability: name, input schema, output schema, callback. - Consumption API: `WP get abilities()`, `WP get ability()`, per-ability execution method with schema validation and mandatory permissions callback. - Analogy offered: abilities are to function-calling what hooks are to data manipulation/side effects — a standard, agreed interface layered onto something WordPress developers already do informally. #### ⏱️ Problems with current architecture - "Monolithic" plugins: idiosyncratic internal architecture a newcomer must reverse-engineer. - Duplicated logic across REST/CLI/admin interfaces within a single plugin. - "Class drilling": long singleton chains to reach one public method — his joke: "how many singleton instances does it take to get to the center of a public method." - Ambiguous public method contracts (object vs. ID; array vs. string return) discoverable only by reading source. #### ⏱️ New plugin architecture - Abilities as the core "nucleus" of business logic; REST/CLI/admin/MCP/LLM as thin adapters written once against that core. - Explicit warning against treating abilities as "another REST API" or "another CLI... made for AI" — that's the wrong mental model per McLoughlin. - Practical dividend cited: SkyVerge shipped a REST API integration for one plugin "the same week" as its Abilities API upgrade because the REST layer only needed a thin bridge/translation class over already-defined abilities. #### ⏱️ Ecosystem view and adoption - Interoperability contracts are explicit — breaking changes to an ability's schema are visible/breaking by design, unlike a forgotten public method silently changing underneath a dependent plugin. - Adoption is named as the current bottleneck to ecosystem-level payoff, not technical readiness. - Adoption evidence: an unnamed slide of companies/products already building on the API; McLoughlin states no sponsorship relationship and is actively gathering more real-world adopters. #### ⏱️ Demo — Baton - Baton: prototype workflow-orchestrator admin UI plugin, hosted on GitHub (no .org release yet; a partial .org submission exists per McLoughlin). - Workflow 1: WooCommerce order-query ability filtered to "processing" status → data-filter step extracts order IDs → WooCommerce add-order-note ability, looped per ID with a fixed note string. Failed first run on malformed JSON (stray comma), succeeded on retry; confirmed via the WooCommerce orders screen showing the new note. - Workflow 2 ("send processing to fulfillment"): same order query → filtered IDs → SkyVerge's Print Invoices and Packing Lists ability (document type: pick list) → send-document-by-email ability targeting a warehouse address. Blocked by WooCommerce's own "coming soon / store not live" email-sending safeguard — treated as a real validation success, not a demo failure. - Framing point repeated twice: none of this required writing a custom integration between WooCommerce and SkyVerge's extension — Baton discovers and consumes both plugins' abilities generically, the same way it would for a plugin it had "never seen." #### ⏱️ Q&A — Jeremy (Leaky Paywall developer): what's worth exposing as an ability? - SkyVerge's own heuristic: start with the custom-post-type-based domain model (e.g., for their memberships extension: create/read membership plans — CRUD on the plugin's core CPT). - Second heuristic: custom cross-service workflows unique to the plugin (his example: a shipping-rates extension that takes order data and calls an external API — that data-flow is a strong ability candidate). #### ⏱️ Q&A — anonymous attendee: does the Abilities API include security/auth the way REST does? - Answer is layered, not blanket: abilities define a permissions callback (is this user allowed to run this ability), but REST-specific, CLI-specific, or admin-specific security/privacy requirements are still implemented at those individual access layers — the ability layer is "the core," additional surface-specific controls "come at that layer," and developers should expect differentiation between what a REST call vs. an admin UI vs. a CLI command is allowed to do even against the same underlying ability. #### ⏱️ Q&A — David (named Abilities API core maintainer): what's missing/on the roadmap? - McLoughlin's stated wishlist item: filtering/query parameters on `WP get abilities()` for discovery (today it returns every registered ability unfiltered). In the exchange, David indicates this is already landed/in progress ("it's in ... we love it"). - McLoughlin frames this as thinking "from the platform level," and says he doesn't have a strong plugin-level wishlist item ready off the top of his head. #### ⏱️ Q&A — audience: will plugin abilities be visible on the WordPress.org plugin directory listing before install? - Does not exist today. McLoughlin strongly endorses the idea (compares it to how registered blocks are surfaced on .org listings) and confirms, prompted by an audience member, that a Trac ticket already exists for it. #### ⏱️ Q&A — audience: can two plugins' abilities conflict (e.g., two SEO plugins registering the "same" ability)? - Abilities are namespaced per plugin/source, so accidental collision is unlikely; the only real conflict scenario named is a plugin deliberately registering into another plugin's namespace ("namespace jacking"), which McLoughlin calls hostile and expects to simply break rather than silently overwrite. #### ⏱️ Q&A — Dave (Ultimate Multi-Site developer, has already added abilities to his plugin) - Confirms and McLoughlin agrees: registering an ability does NOT automatically expose it to REST, CLI, or any other surface — each surface integration is opt-in and must be built (reusing the same core code), with the MCP adapter plugin cited as a partial exception where using it does expose abilities, though even there a given ability can be excluded from exposure at definition time. - Follow-up: should an existing full-CRUD REST implementation be rewritten to route through abilities? McLoughlin: yes, per SkyVerge's own migration pattern with their memberships extension — the database read/write logic moves into the ability, and the REST integration becomes a thin wrapper/translation layer on top. #### ⏱️ Q&A — Rob: how would abilities help a function that renders a graph inside a block? - McLoughlin's answer: rendering stays tied to the block (the view layer); the ability is the right home for the underlying data-processing/aggregation logic if that same processed data needs to reach multiple surfaces (block, CLI printout, page display, etc.) — write the data logic once as an ability, then consume it from whatever presentation layer is needed. #### ⏱️ Q&A — final question: how do you handle consuming another plugin's ability that might not be installed? - Answer: use the discoverability layer proactively — query for the ability before relying on it, and branch (skip the feature, or fall back to an older/less-structured integration method such as a known public method) if it's not registered, e.g., because the dependency is on an older, pre-abilities version. ## 📚 References - WordPress 6.9 Abilities API (core feature this talk documents) — no specific make.wordpress.org post URL was cited verbally in the transcript - Baton (McLoughlin's demo plugin) — described as GitHub-hosted with a partial .org submission in progress; no URL given - WooCommerce Order Query / Add Order Note abilities — named, no URL given - SkyVerge Print Invoices and Packing Lists extension — named, no URL given - WordPress.org Plugin Directory abilities-listing Trac ticket — referenced as existing by an audience member and confirmed by McLoughlin; no ticket number given in the transcript ## 🗣️ Paraphrase - Opening/framing: McLoughlin (SkyVerge; self-styled Abilities API evangelist for Core AI) argues most people who've heard of the Abilities API think of it purely as AI plumbing, and sets out to reframe it as a general WordPress platform primitive. - Definitions: an ability is a namespaced, four-part contract (name, input schema, output schema, callback) registered in a site-wide discoverable registry; consuming code calls `WP get abilities()`/`WP get ability()` and gets automatic schema validation plus a mandatory permissions check on execution. - Problem statement: today's plugins duplicate logic across REST/CLI/admin surfaces and bury reusable functionality behind undocumented public methods and deep singleton chains, forcing every integrator to read source code to infer a contract. - Proposed fix: treat abilities as the core "nucleus" of a plugin, with every access surface (REST, CLI, admin, MCP, LLM) built as a thin, once-written wrapper on top — not as a parallel AI-specific integration layer. - Ecosystem claim: full adoption would let plugins/themes discover and safely integrate with each other's functionality via explicit, breaking-change-visible contracts, addressing WordPress's long-standing "installed but not actually interoperable" plugin sprawl problem; the current blocker is adoption, not the spec. - Demo: Baton, a prototype orchestrator plugin, chains WooCommerce and SkyVerge abilities into two live workflows (bulk order-noting; bulk pick-list emailing) with zero custom integration code between the two vendors' plugins, including a live, unscripted schema-validation failure and a live WooCommerce safety-block, both of which McLoughlin treats as demonstrations of real enforcement rather than demo flaws. - Q&A: covers prioritization heuristics (CPT-based CRUD, custom cross-service workflows), the layered (not centralized) nature of ability-level security, a confirmed in-progress discovery-filtering feature, an unshipped-but-ticketed request to surface plugin abilities on wordpress.org listings, namespace-based (not content-based) conflict resolution, opt-in (not automatic) surface exposure, a stated preference for migrating existing REST CRUD to sit atop abilities, and a fallback pattern for consuming an ability that may not exist on an older dependency version. ## 📰 Newsletter **WordPress plugin devs: your next plugin architecture decision just got a default answer.** At WordCamp US, SkyVerge's Nick McLoughlin — self-appointed Abilities API evangelist and general troublemaker at the Core AI prompt bar — made the case that WordPress 6.9's Abilities API isn't an AI side-quest, it's the new home for your plugin's core business logic. His pitch: stop writing the same order-lookup logic three times for your REST endpoint, your WP-CLI command, and your admin screen. Write it once as an ability (name + input schema + output schema + callback), register it in the site-wide registry, and let REST/CLI/admin/MCP/LLM access it through thin wrappers. He backed it up with a live demo of "Baton," a workflow-orchestrator prototype that strings together WooCommerce and SkyVerge abilities — bulk-adding order notes, bulk-emailing pick lists — without a single custom integration between the two plugins. It broke once (a stray JSON comma) and got blocked once (WooCommerce correctly refusing to send email from a coming-soon store), and honestly, watching it recover live was more convincing than a clean run would have been. Q&A got refreshingly specific: security lives at the ability's permissions callback plus whatever REST/CLI-specific layer you still have to build yourself (abilities aren't a free security blanket); ability names are namespaced so plugin conflicts require deliberate bad behavior; registering an ability does NOT auto-expose it anywhere — that's still opt-in per surface. If you're a plugin developer sitting on custom-post-type CRUD or a bespoke "call an external API with order data" workflow, that's McLoughlin's suggested starting point for your first abilities. Bonus: there's apparently already a Trac ticket asking for plugin abilities to show up on your .org listing page, the way blocks do — worth a "+1" if that's useful to you. ## ✅ Action Items #### DevRel - Developer advocacy: build a short "your first ability" walkthrough (CPT CRUD → ability → REST thin-wrapper) modeled on SkyVerge's stated one-week migration pattern, since it's a concrete, repeatable on-ramp story. - Education: turn this talk's Q&A (security layering, namespace collision, opt-in exposure) into an FAQ — these were the exact points of live audience confusion. - Developer experience: request/track example code for the data-filter pattern Baton uses to reshape one ability's output schema into another ability's input schema — this is the most fiddly part of chaining abilities and wasn't covered by slides. - Developer marketing: source and publish the "who's already building on this" adoption list McLoughlin referenced but did not name in the talk, since it's currently only visible to people who attended in person or catch him at the Core AI prompt bar. - Community management: none identified from this source specifically. - Internal/external/cross-project: coordinate with the WooCommerce and SkyVerge teams already shipping abilities to document their design decisions as reference implementations. #### OSPO - Policy & Governance: none identified from this source specifically. - License Compliance: none identified from this source specifically. - Security Management: clarify and publish guidance on what security guarantees the Abilities API does vs. does not provide (permissions callback only; REST/CLI-specific auth remains the developer's responsibility) — this was a live point of audience confusion. - Software Inventory: none identified from this source specifically. - Developer Support: none identified from this source specifically. - Community Engagement: none identified from this source specifically. - Strategic Alignment: none identified from this source specifically. #### Community - Maintainers: track and prioritize the WP get abilities() discovery-filtering feature David confirmed is in progress/landed, and communicate its ship status broadly (it wasn't clear even to the presenter at Q&A time). - Contributors: the "namespace jacking" risk raised in Q&A suggests a lightweight contributor-facing guideline on responsible ability namespacing would preempt confusion. - Sponsors: none identified from this source specifically. - Ecosystem: encourage more plugin authors (per McLoughlin's open call at the Core AI prompt bar) to share adoption case studies. #### WordPress - Core: none beyond what's tracked below. - Core Performance: none identified from this source specifically. - Core AI: this talk is effectively Core AI team messaging in the wild — worth cross-referencing against the team's own official Abilities API documentation for consistency. - **Core Program Team:** none identified from this source specifically. - Mobile: none identified from this source specifically. - Playground: an Abilities API demo/sandbox (à la Baton, simplified) inside WordPress Playground could lower the exploration barrier McLoughlin's show-of-hands suggests still exists. - Community: none beyond what's tracked below. - Training: build a training module around the "new plugin architecture" pattern (core ability + thin per-surface wrapper) as a named, teachable pattern rather than leaving it to conference-talk osmosis. - Marketing: none beyond the Newsletter blurb above. - Support: none identified from this source specifically. - Design: none identified from this source specifically. - Documentation: prioritize the audience's most confused Q&A topic — where ability-level permissions end and surface-specific (REST/CLI) auth begins — as a documentation gap to close. - Photos: not applicable to this source. - TV: consider indexing/captioning this WordCamp US session if not already done, since it's a strong reference talk. - Polyglots: not applicable to this source. - Accessibility: not applicable to this source beyond the general talk-captioning note above. - Meta: track/prioritize the Trac ticket (referenced but not numbered in-talk) to surface a plugin's registered abilities on its wordpress.org listing page — a real, if small, discoverability win. - CLI: WP-CLI abilities examples/smoke tests would reinforce the "write once, expose to CLI too" claim with concrete tooling. - Hosting: not applicable to this source. - Tide: not applicable to this source. - Openverse: not applicable to this source. - Themes: reinforce in documentation that abilities are not plugin-only — McLoughlin explicitly said themes and snippets can register them too, but the entire talk uses plugin examples. - Plugins: encourage more third-party plugin reviewers/liaisons to check for ability-namespace hygiene per the "namespace jacking" risk raised in Q&A. #### The WPOCC - Programs: not applicable to this source — talk doesn't reference The WPOCC. - Projects: not applicable to this source. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: not applicable to this source — talk doesn't reference FAIR. - Policies and covenants: not applicable to this source. - Productized governance artifacts: not applicable to this source. ## 🧪 Hypotheses - H1: Plugins that migrate existing REST CRUD endpoints to consume a shared ability layer will ship new access surfaces (CLI, MCP) measurably faster than plugins that keep per-surface logic duplicated (SkyVerge's "same week" REST rollout is the anecdotal seed for this). - H2: Ability adoption will correlate with plugin category — CPT-heavy plugins (memberships, bookings, custom directories) will adopt abilities faster than utility/security plugins, because the CRUD-on-a-custom-post-type heuristic McLoughlin gave maps directly onto that category. - H3: Without a wordpress.org-listing surface for registered abilities (the still-unshipped Trac ticket), cross-plugin ability discovery will remain dominated by developers who already know each other or attend the same events (e.g., McLoughlin's Core AI prompt bar conversations), slowing organic ecosystem-level interoperability relative to McLoughlin's stated aspiration. - H4: Security confusion (ability permissions callback vs. REST/CLI-specific auth) will recur as a support burden as more non-core-team developers adopt the API, based on it being the most detailed clarifying exchange in this Q&A. - H5: Orchestrator-style consumer plugins like Baton will proliferate once a critical mass of common plugins (WooCommerce plus a handful of major extensions) expose abilities, because the marginal cost of adding a new "recipe" step is low once the underlying discovery/schema infrastructure exists. ### 📊 Methodology - H1/H2 testable via a survey or GitHub/SVN mining study of plugins that added `wp_register_ability()` (or equivalent) calls, correlating time-to-new-surface-shipped and plugin category with abilities adoption date. - H3 testable by tracking the actual resolution date/status of the referenced (but unnumbered in-transcript) wordpress.org-listing Trac ticket and measuring ability-discovery behavior (e.g., support forum questions, Slack #core-ai discussion volume) before and after it ships. - H4 testable via a lightweight audit of WordPress support forum and Make Core AI blog comment threads for recurring "does the Abilities API include security?" style questions post-6.9. - H5 testable by tracking the count and diversity of orchestrator/workflow plugins (Baton-like tools) appearing in the plugin directory or on GitHub over the 12 months following this talk, against the count of major plugins (WooCommerce extensions, form plugins, SEO plugins) that have shipped abilities. ### ❓ Questions - Will the Abilities API get an official, versioned deprecation/breaking-change policy at the schema level, given McLoughlin frames "changes to contracts are obviously breaking changes" as a benefit but doesn't describe an enforcement mechanism? - What does McLoughlin's "namespace jacking" scenario actually do today — does WordPress core reject or warn on a second registration attempt into an existing namespace, or does it silently fail/overwrite? - Now that discovery filtering on `WP get abilities()` is reportedly landed (per the David exchange), what filter parameters does it actually expose, and do they cover the ecosystem-level "which installed plugins have an ability that does X" use case McLoughlin says is still missing? - Is there any planned parity between the not-yet-shipped .org-listing ability visibility and the existing block-directory visibility McLoughlin analogizes to? - How does the MCP adapter plugin decide default exposure of abilities, and what's the opt-out mechanism McLoughlin references ("you can still choose in the ability definition to not expose it")? ### 🔮 Future Research - A structured audit of how many WordPress.org plugins have shipped abilities in the first 6-12 months post-6.9, segmented by category, to test the adoption-bottleneck claim directly. - Case study interviews with the "already building on this" adopters McLoughlin references but doesn't name in the talk — their actual migration friction points would sharpen the DevRel education backlog above. - A security-focused review of real-world abilities in the wild to check whether developers are correctly separating ability-level permissions from REST/CLI-specific auth, or whether the confusion raised in Q&A is showing up as actual vulnerabilities. - Investigation into whether orchestrator plugins like Baton, once matured beyond prototype, introduce new attack surface (e.g., an admin-facing tool that can chain write-abilities across plugins) that needs its own capability/permission model distinct from the abilities it consumes. ### 💡 Implications - **Practice.** Plugin architecture guidance shifts from "build a REST API, then maybe a CLI" toward "build an ability first, then thin-wrap it everywhere" — a genuine reordering of where developers should invest first-pass design effort. - **Policy.** If the wordpress.org-listing Trac ticket ships, plugin review/directory policy will need criteria for what's shown (all abilities? only "public" ones?) and how that interacts with security disclosure norms for abilities that expose write access. - **Security.** The layered model (ability permissions callback + surface-specific auth) needs clearer, earlier documentation to prevent developers from assuming ability registration alone is "secure by default," per the live Q&A confusion. - **Education.** The "new plugin architecture" pattern is teachable as a named pattern (core ability + thin adapters) and would benefit from being folded into official plugin-development training rather than left to individual conference talks and evangelism. - **Funding models.** Orchestrator tools like Baton hint at a plausible new plugin category (workflow automation across third-party abilities) that doesn't require the tool author to have any relationship with the plugins it orchestrates — a low-friction product category worth watching for funding/incubation interest. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 9-10 for this notes document (technical vocabulary — "namespaced," "JSON Schema," "singleton" — raises grade level above the plain conversational register of the raw transcript, which itself runs closer to grade 7-8 due to spoken-language patterns, filler words, and short sentences). #### 👀 Visual learners - Present: McLoughlin explicitly references on-screen code slides and an architecture diagram ("lines going everywhere") during the talk, though neither is captured in the transcript/notes. - Improve: this notes document would benefit from a simple diagram of the "core ability → REST/CLI/admin/MCP thin wrappers" pattern, and a second diagram showing Baton's two demoed workflows as flowcharts (order query → filter → add note; order query → filter → send email). #### 🔊 Aural learners - Present: the source itself is a spoken conference talk with live audience Q&A, which serves aural learners directly if they consume the original video/audio rather than this text. - Improve: a 2-3 minute audio summary distilling the "new plugin architecture" thesis and the two demo workflows would serve aural learners who only have this notes document, not the video. #### 🗣️ Verbal learners - Present: McLoughlin uses concrete analogies throughout ("cable management standard for spaghetti code," "how many singleton instances does it take to get to the center of a public method"). - Improve: a short glossary (ability, namespace, permissions callback, schema validation, orchestrator plugin) would help verbal learners anchor the technical vocabulary faster than reading the full Notes section. #### 🧩 Kinesthetic learners - Present: the talk itself is a live coding/UI demo (Baton), which is inherently kinesthetic-friendly for those watching the source video. - Improve: a step-by-step reproducible mini-lab ("register a two-field ability, call it via `WP get ability()`, validate the schema error path") would let kinesthetic learners rebuild the demo's core mechanic hands-on from this notes document alone. #### 🧠 Logical learners - Present: the Notes section above is organized as a clear problem → mechanism → pattern → evidence → Q&A sequence, which suits logical learners. - Improve: a compact decision table ("if your plugin has X, expose ability of type Y") derived from the two Q&A heuristics (CPT CRUD; custom cross-service workflows) would make the prioritization logic more scannable. #### 🧑‍🤝‍🧑 Social learners - Present: the Q&A section is inherently social/dialogic and is preserved in full in the Notes above. - Improve: a discussion-prompt version of this notes document (e.g., "which of your plugin's public methods would you turn into an ability first, and why?") would give social learners a structured way to work through this material in a study group or Slack thread. #### 🧘‍♀️ Solitary learners - Present: the structured Summary/Paraphrase/Notes breakdown supports self-paced, independent reading. - Improve: a short self-check quiz (e.g., "what does an ability guarantee about security, and what does it not guarantee?") would let solitary learners verify their own comprehension of the talk's most-missed point (the security layering nuance) without needing a study partner. #### 🌿 Naturalistic learners - Present: not directly addressed by the source — this is a software-architecture talk with no ecosystem/environmental framing. - Improve: the "ecosystem" language McLoughlin already uses (plugin ecosystem, interoperability) could be extended with an explicit systems-thinking framing (abilities as a shared "nutrient cycle" for functionality across a WordPress site) to give naturalistic learners a more resonant hook, though this would be an added framing not present in the source. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: this notes document uses consistent heading levels (H1 title, H2 top sections, H3/H4 sub-sections) that map to logical landmarks. - Improve: if published as HTML, ensure emoji-prefixed headings retain readable text alternatives (screen readers should announce "Summary," not stumble on the emoji glyph) — verify the Reader/Obsidian rendering pipeline handles this correctly. #### Keyboard navigation - Present: not directly applicable — this is a text document, not an interactive interface. - Improve: not applicable to this source (no forms, no interactive controls in the notes themselves). #### Contrast and readability - Present: plain Markdown/plain-text rendering defers contrast to the reading application (Reader, Obsidian), which generally meets 4.5:1 by default. - Improve: no action needed from this document; contrast is a platform-level, not content-level, concern here. #### Text resizing and reflow - Present: Markdown/plain-text content reflows natively at any zoom level in standard readers. - Improve: not applicable to this source. #### Media and captions - Present: the source is a YouTube conference talk; captions/auto-subtitles were the actual data source for this transcript (fetched via vidIQ, since the standard Readwise scrape path had failed for this video). - Improve: verify official WordCamp US captions (if/when published) are more accurate than the auto-generated transcript used here — several transcription artifacts are visible (e.g., "Mclofflin" for McLoughlin, "payw wall" for Paywall, "Woo Commerce" split as two words throughout), and a downloadable transcript/audio-description track from the official WordCamp.tv publication would improve on this source. #### Forms and interactions - Present: not applicable — no forms in this source or these notes. - Improve: not applicable to this source. #### Standards reference - Gaps mapped to WCAG 2.2 AA: primarily 1.2.2 (Captions, Prerecorded) — this analysis had to fall back to a third-party transcript tool because the primary source's own captions weren't accessible to the pipeline at time of processing; and 2.4.6 (Headings and Labels) — addressed directly by this document's heading structure. ### 🌍 DEIB Assessment #### Cultural breadth - Present: none specifically — the talk is a single US conference session (WordCamp US) with no multi-region examples or case studies. - Improve: pair this talk with international WordCamp sessions covering the same feature (if any exist) to broaden the case-study base beyond a single US-centric plugin vendor's (SkyVerge's) examples. #### Inclusive language - Present: the talk uses plain, jargon-defined technical language ("here's what even is the abilities API") and is generally casual/inclusive in tone rather than gatekeeping. - Improve: a few insider-audience references (naming specific attendees like "David," referencing "the Core AI prompt bar" without explaining what that is) assume conference-context knowledge that a video-only or notes-only audience won't have; a brief glossary/context note would help. #### Neurodiversity support - Present: the Notes section's consistent, chunked, timestamp-labeled structure (even though exact timestamps weren't available from this transcript source, thematic labels serve the same function) supports predictable navigation. - Improve: the raw talk itself is unstructured live speech with tangents (demo troubleshooting, audience banter); this notes document's restructuring into discrete sections is itself the accessibility improvement over consuming the raw video/transcript directly. #### Representation - Present: the Q&A surfaces a range of plugin developers (Leaky Paywall, Ultimate Multi-Site) and a core maintainer (David), giving multiple practitioner perspectives beyond the single presenter. - Improve: no demographic or identity information is available from the transcript to assess representation further; this source doesn't provide grounds for a stronger finding either way. #### Psychological safety - Present: the talk explicitly frames the live demo failures (invalid JSON, WooCommerce email block) as normal and even instructive rather than something to be embarrassed about, modeling a low-pressure, learning-oriented tone for the audience. - Improve: none identified — this is already a strength of the source material. ### ✅ Logical Validity #### Strong reasoning - Inductive support for the "abilities reduce duplication" claim: McLoughlin backs the general claim with a specific, falsifiable anecdote (SkyVerge shipping a REST integration "the same week" as an abilities upgrade because only a thin bridge class was needed) — this is a concrete, checkable data point rather than a bare assertion, located in the main talk body and the Q&A response to Jeremy. - Analogical reasoning: the hooks-to-abilities analogy ("just like hooks give us a standard way to manipulate data... abilities give us a standard agreed interface to call each other's functions") is apt because it maps a genuinely structurally similar WordPress precedent (a standardized interception/extension point) onto a new standardized call-interface point, helping WordPress-native audiences generalize from known territory. - Live falsifiability: the demo's two real failures (invalid JSON; WooCommerce email block) function as unplanned but genuine evidence that the schema validation and permissions systems described actually enforce constraints, strengthening the credibility of the abstract claims made earlier in the talk. #### Fallacies - **Hasty generalization (mild), located in the "Adoption evidence" segment.** McLoughlin asserts "we're seeing adoption... a lot of the biggest players in the space... are already building" but the transcript gives no names, counts, or verifiable list — the claim is asserted on the presenter's authority ("this is people I've talked to") without independently checkable evidence. Fix: cite specific, named, checkable examples (plugin slugs, changelog entries, or public repos) rather than an unlisted slide referenced only verbally. - **Appeal to authority (mild), located in the Q&A response to the "what's missing" question from David.** McLoughlin defers to "I need to update myself on this" and treats a fellow presenter's in-room confirmation ("it's in... we love it") as sufficient evidence a feature has shipped, without stating a release version or changelog reference. Fix: verify and cite the actual WordPress version/changeset where discovery filtering landed rather than relying on an unverified in-room exchange. - **False dilemma risk (very mild, self-corrected), located in "Yes... but also no... but also yes" framing of the security Q&A.** McLoughlin's phrasing briefly sets up security support as a binary (does the API give you security or not) before immediately complicating it into the accurate layered answer — the fallacy risk is present in the setup but resolved in the same breath, so it's a rhetorical device rather than a real reasoning error. No fix needed; flagged for completeness only. #### Tone of voice - Conversational, self-deprecating, and enthusiastic — McLoughlin repeatedly jokes about his "self-appointed" evangelist title, narrates his own live demo failures good-naturedly ("so it failed, which is great for a demo, right?"), and frames audience questions as opportunities ("please let me know what you don't get") rather than as challenges to defend against. The tone is pedagogical and low-ego throughout, consistent with a practitioner sharing hard-won patterns rather than a vendor pitching a product. ### 🛡️ DARVO Analysis - Not applicable to this source — this is a technical conference talk with no accusation, conflict, or interpersonal dispute present; there is no deny/attack/reverse-victim-offender pattern to analyze. The closest analog (candidly narrating live demo failures rather than deflecting blame) is the opposite of DARVO behavior. ## 🎯 Conclusion - **Bottom line.** WordPress 6.9's Abilities API is presented not as an AI-specific feature but as a general-purpose, standardized, discoverable capability registry meant to become the default architectural core of WordPress plugins — replacing duplicated per-surface logic and undocumented public-method archaeology with a single, schema-validated, permission-checked contract that any surface (REST, CLI, admin, MCP, LLM) can consume. The live Baton demo is the talk's strongest evidence: a generic orchestrator plugin chaining WooCommerce and SkyVerge abilities with zero custom integration code, including two unscripted failures that ended up reinforcing rather than undermining the core claim. - **Practical next steps for readers/builders.** (1) Audit your plugin for CPT-based CRUD and any bespoke cross-service data workflow — both are the concrete starting points McLoughlin gave in Q&A for "what to turn into an ability first." (2) Do not assume ability registration alone provides REST/CLI-level security — budget separate implementation time for surface-specific auth, per the Q&A clarification. (3) Track the still-unshipped wordpress.org-listing Trac ticket if plugin discoverability matters to your roadmap. (4) If you maintain existing full-CRUD REST endpoints, evaluate SkyVerge's stated migration pattern (rewrite the core logic as an ability, demote the REST layer to a thin wrapper) as a refactor target. ## 🔄 Refactor Appendix — Abilities API for Humans > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Abilities give WordPress a standard function-call interface > [!quote] ID:transcript_h1 > abilities give us a standard agreed upon interface to call each other's functions **Context & use**: - Mid-talk, the "hooks-to-abilities" analogy segment. - Core conceptual claim of the whole talk — everything else (new plugin architecture, Baton demo) is downstream of this framing. **Tags**: #xref **Highlight**: [view highlight](readwise://document/01m0czzmd35wrxxyjgbrh8f876) <!-- atomicity: 1 idea ✓ --> #### [H2] The abilities layer only guarantees a permissions callback, not full security > [!quote] ID:transcript_h2 > the abilities API is really focused on defining that core... but then those additional pieces kind of come at that layer **Context & use**: - Q&A response to the audience question about REST-style security "for free." - Directly relevant to any WordPress security or plugin-audit work — corrects a plausible false assumption that registering an ability is sufficient security coverage. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://document/01m0czzmd35wrxxyjgbrh8f876) <!-- atomicity: 1 idea ✓ --> #### [H3] Registering an ability does not auto-expose it to any surface > [!quote] ID:transcript_h3 > it's not automatically in any of those places **Context & use**: - Q&A exchange with Dave (Ultimate Multi-Site) confirming abilities are opt-in per access surface (REST, CLI, admin), with the MCP adapter plugin as a partial exception. - Corrects a second plausible misconception (that abilities are automatically "everywhere" once registered) — useful for anyone scoping an abilities migration. **Tags**: #xref **Highlight**: [view highlight](readwise://document/01m0czzmd35wrxxyjgbrh8f876) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Abilities are the new default nucleus of WordPress plugin architecture **Claim** (one sentence, Courtney's voice): Plugin business logic should live once in a schema-validated ability, with every access surface — REST, CLI, admin, MCP — built as a thin wrapper around that same core rather than duplicated per surface. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for plugins with meaningful custom logic (CPT CRUD, cross-service workflows) reused across multiple surfaces; less relevant for trivial single-surface plugins with no reuse need. **Links** (≥1 with annotation): - [[WordPress plugin architecture]] — because extends - [[REST API design patterns]] — because contrasts on where core logic should live **Optional**: status: seedling <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Track the wordpress.org plugin-directory Trac ticket for surfacing registered abilities on plugin listing pages — no ticket number captured from this source, needs lookup. #fleeting #inbox - [F2] Verify current shipped status of `WP get abilities()` discovery/filter parameters (David's Q&A exchange implies landed, but no version number was stated). #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Look up the wordpress.org-listing Trac ticket for plugin abilities visibility referenced in this talk's Q&A — #things - [ ] Check WordPress 6.9+ changelog for the `WP get abilities()` discovery-filtering feature confirmed in Q&A — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Abilities API for Humans.md|Abilities API for Humans by Nick McLoughlin (SkyVerge)]] ## Highlights - Uh, so what does abilities API do about this? Uh the abilities API gives us the opportunity to standardize these patterns of exposure and interoperability uh between our packages, plugins, themes, core, wherever. Um and also within the individual package itself, within your plug-in, you can standardize how that's structured and and and meet the standard that's set at the ecosystem level. And then you can carry out that same functionality across multiple contexts, your REST API, your CLI, what have you. Um, you know, command pallet as that's growing in adoption, right? And now you don't have to rethink the logic of how that works. You can build that thin layer of integration just for that surface. Um, so I think of this as like a a cable management standard for our spaghetti code um of how we can kind of bring these things into one place uh and and make a little bit less of a mess while we're at it. Um so we get a standardized way to declare abilities uh which are then recorded in a centralized discoverable registry uh and then can be written once and consumed anywhere within the WordPress context with just like a minimal access layer based on where you need to consume that functionality. ([View Highlight](https://read.readwise.io/read/01m0d0dynw84emy06t95ajfry0)) - Note: Core standardization pitch — "cable management standard for our spaghetti code." - Tags: atom/literature/h1, wordpress-abilities-api - So again, I mentioned this before. Uh, we're not doing fundamentally new things here. Um, there's there's maybe some new concepts or names depending on like your development background, but I don't want this to sound too foreign. Uh, as WordPress developers, we're already doing a lot of this. An ability is essentially a well-formed public function call. Uh, and the difference now is that we have a standard model in the ecosystem of for what well-formed means. um that we can all build toward together. It also it fits into the the pantheon of other ways that we have to interact with each other's code already. Um so just like hooks give us a standard way to manipulate data or run side effects and kind of the event-based system, abilities give us a standard agreed upon interface to call each other's functions. ([View Highlight](https://read.readwise.io/read/01m0d0e2tvrskqbzbcej41pw57)) - Note: The hooks-to-abilities analogy — abilities as a standard function-call interface, not a new capability. - Tags: atom/literature/h2, wordpress-abilities-api - So the main unlock I'll say here for developers is uh what I'm here now labeling the new plug-in architecture. Um and I I think the 'the' is important there because it's the the idea here is that this is the standard. It's not a random new way that somebody else should be doing it. It's established as the standard way of doing this. that abilities live as the core of your sort of uh plug-in atom model uh the core nucleus of your business logic that then gets exposed to all of these other surfaces. Um I think this is mostly like a a mental unlock. There is like I said a lightweight API of registering and consuming abilities but largely it's a a mental shift in how we construct our code. Um, a lot of the folks that I see talking about abilities API or trying to process and wrestle with how to use it kind of put it on this outer ring of, well, it's another REST API. It's another CLI. Uh, it just happens to be made for AI for some reason, but also needs an extra MCP layer on top of that. Um, and that should be your clue that like we're not adding layers to add layers to add layers. This is the new standard that then you can point the rest of those to. So from that core bundle of abilities, you can expose the functionality that you write once to the REST API, the CLI, the admin, yes, MCP, yes, LLMs through that as well. ([View Highlight](https://read.readwise.io/read/01m0d0e862gt08vpezmfrjmv95)) - Note: Central prescriptive claim: abilities as the plugin's core nucleus, everything else a thin wrapper. - Tags: new-plugin-architecture, atom/literature/h1 - >> Um, this is really interesting to me. I I do a lot of sharing um methods and variables across plugins that I've created using public static classes and stuff like that. >> Yeah. Yeah. >> So, I can see the benefit of this. Let me um ask you like if I make a REST endpoint, you get all kinds of WordPress security and methods and all kinds of stuff for free just by using the WordPress REST methods. Does the abilities API come with like authentication security that kind of those kind of methods that that you can then pull gives you added benefit as well. >> Yes. Yeah. I h Yes. but but also no [laughter] or no but also yes uh so the idea of the abilities is that they'll be uh I don't want to give you a full it depends right [laughter] uh is that the the abilities are defining the the core functionality you do have a permissions callback that you can define there as far as is the user allowed to run this ability um but if you're looking at like exposing to those external integrations the security and privacy or whatever pieces that you need on top top of that kind of come in at those layers of how do I expose this to the rest API and then I'll leverage you know we have to you still have to define the rest API endpoint you can't just like you know have the ability there so you still get to define that layer and can implement those at that at in that place um because you'll want those to be different for a REST API call versus just the admin interface versus a CLI maybe that has has more access or something right um so the abilities API is really focused on defining that core that central core and then the the addition there is some permissioning there but then those additional uh pieces kind of come at that layer. So I think that's maybe the biggest thing if you're starting to look into this is starting to wrap your head around where those pieces live um and at what layer do I need to enforce that um and what's particular to this you know REST API integration versus the core logic of the plugin. Um so there's there's room for differentiation there now. >> Thank you. Yeah. ([View Highlight](https://read.readwise.io/read/01m0d0eh3f9t4bh81r1599dktg)) - Note: Q&A: abilities only guarantee a permissions callback — REST/CLI-specific auth is a separate, developer-owned layer. - Tags: wordpress-security, atom/literature/h2 - >> Hi, um, I'm Dave. I make Ultimate Multi-Site and I added abilities recently. >> You could go back to the slide that had all the complicated lines. >> Yeah. Add multi-sight onto this. seems misleading when I look at it because if you create an ability, unless I'm understanding incorrectly, it doesn't automatically make it available to those other items. It won't make it in the CLI, it won't make it in the REST, >> but you can and if you want to like >> use the same code when you're registering your REST endpoints and your CLI ability. >> Yeah. Yeah. Exactly. Yeah. Yeah. Yeah. I didn't uh I didn't draw lines between like within the circle like these are all the lines come from outside. I felt like there was enough lines on the slide actually. Um [laughter] but uh but you're right that those are all kind of like optional right is like when you have the ability itself it's not automatically in any of those places. Um the I guess like the MCP adapter plugin would maybe be the exception there where using that it does expose those abilities but you can still choose in the ability definition to not expose it to that. Um, so you you still have that that optionality at any point to integrate with a new surface. It just makes it that much easier when you need to. >> My my next question is like >> I like I have this I had a rest before which had like a full CRUD setup you could use creating any of the objects uh my plug-in managed. Would you is there a reason not to expose the same kind of CRUD functionalities in an ability? Um I mean it's going to be use case specific obviously but uh in general like I would say the like in the and this is the model that we've followed like with memberships which already had a rest api uh integration um was that we we rewrote those to consume the abilities underneath. Um so that the the portion that's just that core functionality of you know get this thing from the database or you know write an update to this thing that's in the database that that's all handled by the ability and then the rest API integration becomes that like more of a thin wrapper that just exposes it um that way and you know can add layers to it. It can get, you know, pretty heavy too, but [laughter] um yeah. Yeah, it's uh I would say putting the abilities at the center of that though is is the idea here. >> Very good. Thank you. >> Yeah, thanks. Got like three minutes left, so we're we're in good shape. ([View Highlight](https://read.readwise.io/read/01m0d0epe23p4jkqd6nxp5g57x)) - Note: Q&A: ability registration is opt-in per surface (not automatic); SkyVerge migrated existing REST CRUD to sit atop abilities. - Tags: atom/literature/h3, new-plugin-architecture