Most people’s take on this will be that AI agents are about to run your store. The WooCommerce developer blog published the roundup: read-only abilities landing across more than twenty extensions, from Subscriptions and WooPayments down to the Australia Post and Royal Mail shipping plugins. Note the word read-only: nothing in this pass updates an order, cancels a subscription or refunds a charge.
I think that’s the correct first move, but the part worth your afternoon is the tooling they used to produce it. WooCommerce extracted the scaffolding, the audit process and the checks into public agent skill repos, so you can run the same workflow against your own plugin and get a real ability registered through the WordPress Abilities API, permission callback and all.
Read-only first is the right call
Every ability in this pass still runs its permission callback on execution, typically requiring a store-management or admin capability. The metadata also carries annotations for read-only and idempotent behavior. Even so, the surface is already sensitive: the payment abilities cover account, transaction, deposit and dispute summaries for WooPayments, plus balance and payout summaries for Stripe. Reading payment data with a shop manager credential is fine for a support session and wrong for a marketing dashboard, so the permission callback matters more than the transport the ability arrives on.
Read-only first is correct for a concrete reason. The first bug class in this pattern is an ability that claims read-only but writes somewhere: a last-viewed timestamp, a cache prime, a log row. The verify skill in this tooling ships with a readonly-but-writes detector for exactly that. If the extension pass had started with write abilities, that detector would be doing security work instead of correctness work, and every store running an agent would depend on it.
For store owners, the near-term win is mundane and useful. A support tool can answer why a payment failed or which tracking provider an order uses without a bespoke integration per store. If you’re pointing agents at order data for anything analytical, start by deciding what revenue means in that data before the agent does it for you.
Adding WooCommerce extension abilities to your own plugin
The workflow lives in two repos. WordPress/agent-skills is the portable core layer with three skills: wp-abilities-api, wp-abilities-audit and wp-abilities-verify. The woocommerce/agent-skills repo overlays the WooCommerce specifics, including the abilities-api-implement skill with the Domain class shape, the loader-only registrar, the paginated output envelope and the WC 10.9 dependency boundary. If your plugin doesn’t depend on WooCommerce, the first repo is enough. The steps:
Install both skillpacks
Clone the WooCommerce repo and run the install script against your plugin directory:
git clone git@github.com:woocommerce/agent-skills.git
cd agent-skills
node shared/scripts/skillpack-build.mjs --clean
node shared/scripts/skillpack-install.mjs \
--dest=/path/to/your/plugin \
--targets=claude,codex,cursorThe skill files land in .claude/skills/, .codex/skills/ or .cursor/skills/ depending on which assistant you use. Open the project, ask it to register abilities, and it loads the skill and works through the playbook.
Audit before you scaffold
The wp-abilities-audit skill enumerates your plugin’s functionality and capability gates, then proposes abilities in clusters. This is the step everyone will want to skip, and it’s the one that decides whether the output is any good. One ability per REST endpoint produces noise; the grouping heuristic exists so you get a few coherent read surfaces instead of forty fragments. I’ve only run this against small and mid-sized plugins, so I can’t say how much supervision a large plugin with years of legacy admin screens needs.
Register behind a version guard
Registration goes through wp_abilities_api_init and wp_register_ability(), which means the site needs WordPress 6.9 or newer. For a WooCommerce extension, guard the WooCommerce version too, since the domain ability surface starts at 10.9:
add_action( 'wp_abilities_api_init', 'bbioon_register_giftcard_abilities' );
function bbioon_register_giftcard_abilities() {
// The WooCommerce ability surface starts at 10.9.
if ( ! defined( 'WC_VERSION' ) || version_compare( WC_VERSION, '10.9', '<' ) ) {
return;
}
wp_register_ability( 'bbioon-shop/gift-cards-get', array(
'label' => __( 'Read gift cards', 'bbioon-shop' ),
'description' => __( 'Returns gift cards with balance and status.', 'bbioon-shop' ),
'category' => 'commerce',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'code' => array( 'type' => 'string' ),
),
),
'output_schema' => array( 'type' => 'object' ),
'execute_callback' => 'bbioon_shop_gift_cards_get',
'permission_callback' => function () {
return current_user_can( 'manage_woocommerce' );
},
) );
}Keep the execute callback thin and return the paginated envelope the playbook asks for. Register your category with wp_register_ability_category() before you use it, or pick an existing one.
Run the verifier
wp-abilities-verify does static and runtime correctness checks, including the readonly-but-writes detector. It’s cheap insurance, and it belongs in CI if the plugin already has a pipeline. A schema drift or a changed callback signature is the kind of thing you want caught by a test before an agent surfaces a broken ability to a store manager.
Check the changelog before promising a date
The availability table in the announcement is an estimate built from merged pull requests and current release tags, so don’t treat it as a release schedule. A few things have shipped: WooCommerce Shipping 2.3.5, Royal Mail 4.0.4, MailPoet 5.28.0. Stripe and PayPal are still open pull requests. Subscriptions is expected after 8.7.1, likely 8.8.0. So if a client asks today whether their agent can read subscriptions, the honest answer is not yet. The changelog is the source of truth.
Two version checks decide whether any of this registers on a given store: WordPress 6.9 for the abilities runtime, WooCommerce 10.9 for the domain abilities. An older store never fires the hook, so the ability never shows up and nothing breaks. When a client says the tool sees nothing, check this first. If you maintain an extension with data agents would usefully read, that’s the whole job now: audit it, register behind the guard, verify it. I do that pass for plugin owners who’d rather hand the scaffolding to someone who has run this workflow before.
