# Proposal to Expand Abilities in WordPress 7.1 Draws Pushback > [!question] Lingering Questions > - Once the 7.1 core ability schemas ship, do they end up meaningfully different from their REST equivalents — testing Levine's "too similar" objection. > - Does `read-*` or `get-*` naming win, and does the LLM-interpretability rationale actually hold up? > [!tip] Article Ideas > - A short DevRel explainer on the Abilities API opt-in model (`show_in_abilities`) before it ships more broadly. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — an existing permanent note already covers this article's primary design-principle claim. > - [[3. Resources/MOCs/Open Source Governance MOC]] — the decision-venue-legitimacy question is a general open-source governance pattern. > [!quote] Vocabulary > - **Abilities API** — a WordPress core layer exposing discrete, agent-callable capabilities distinct from the REST API. > - `show_in_abilities` — the proposed opt-in flag gating whether a setting or post type is visible to agents, modeled on `show_in_rest`. ## Bib capsule Automattic-sponsored core committer Jorge Costa proposed adding three read-only abilities (`core/read-settings`, `core/read-content`, `core/read-users`) to WordPress 7.1, slated for release August 19 at WordCamp US. rtCamp senior engineer and Abilities API component maintainer David Levine pushed back hard, arguing the abilities are untested and unready, and that a recent AI Team meeting had concluded they should bake in the AI plugin for a full release cycle first. ## Author's thesis The dispute over WordPress 7.1's first core abilities turns on two separable questions — whether the proposed abilities are *shaped* correctly as consumer-neutral primitives, and whether they're *tested* enough to ship — plus a procedural question about which venue (a contributor call vs. a formal merge proposal) actually has authority to decide. ## Key arguments (≤3) 1. **The capability gap is real** — existing AI integrations can call a model but can't reliably answer basic questions like what posts exist, motivating core read abilities. 2. **Shape matters as much as readiness** — abilities need to be functional primitives serving REST, CLI, and Command Palette alike, not a mirror of one interface. 3. **Decision-venue legitimacy is contested** — whether an informal contributor-call consensus counts as a real decision depends on who was in the room (authors, release squad, core committers). ## Claim atoms ### Core read abilities give agents queryable site basics > [!quote] ID:rw_01kx13d8pn0a1anwjj0w0m1e0y > "those integrations can call a model but cannot reliably answer basic questions such as what posts exist or which page is the front page" Costa's justification in the merge proposal — names the exact capability gap core read abilities close, the strongest "why core" argument. ### Core abilities should be primitives, not a REST mirror > [!quote] ID:rw_01kx13d8pn0a1anwjj0w0m1e0y > "Core Abilities need to be functional primitives that can serve the common denominator of needs for REST, CLI, Command Palette, etc etc." Levine's core design objection, distinct from the readiness complaint — the reusable principle: primitives serve many consumers; don't clone one interface. (Already promoted as [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]].) ### A contributor call is not a formal core decision > [!quote] ID:rw_01kx13d8pn0a1anwjj0w0m1e0y > "especially without those working on this feature in the room nor the release squad nor broader core committers" McCarthy's venue-quorum argument for why a merge proposal, not a call, decides — a governance principle reusable across WordPress decisions. ### Opt-in flag gates ability visibility like show_in_rest > [!quote] ID:rw_01kx13d8pn0a1anwjj0w0m1e0y > "settings and post types would need to opt in via a new show_in_abilities flag before agents can see them" The security/visibility mechanism for agent access — reuses a proven WordPress pattern (`show_in_rest`) for a new consumer class (agents). ## Permanent candidates - **Core API primitives lock in on backward-compat, so shape them before shipping** — already captured: [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]]. Not duplicated. - **Decision-venue legitimacy determines whether "consensus" binds** — not yet captured elsewhere. Promoted below. ## Processing checklist - [x] Port existing deep-read analysis into Konik Literature format - [x] Checked for existing permanent note before creating (found P1, promoted P2 only) - [x] Connect into the relevant MOC - [ ] Read the Make Core merge proposal comment thread in full and note resolved-vs-deferred objections - [ ] Diff the eventual 7.1 core ability schemas against REST equivalents once shipped ## Metadata - Source: [[3. Resources/Readwise/Articles/Proposal to Expand Abilities in WordPress 7.1 Draws Pushback From Component Maintainer Over Testing and Readiness]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — decision-venue legitimacy and merge-proposal process are direct governance-mechanism subject matter. - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — evidence-for: carries this article's design-principle claim already.