Implement server-side registry for Abilities API

[gziolo]

A typical WordPress site might have dozens of plugins, each adding unique functionality. But there’s no standardized way for these components to express their capabilities. An AI assistant has no systematic way to discover that your backup plugin can create snapshots, your SEO plugin can analyze content, or your e-commerce solution can generate reports. This fragmentation limits what we can build.

The Abilities API establishes a common pattern that the entire ecosystem can adopt. It may look something like this:

// Any plugin can register its abilities with the `init` hook.
wp_register_ability( 'my-seo-plugin/analyze-content-seo', [
    'label'       => __( 'Analyze Content SEO', 'my-seo-plugin' ),
    'description' => __( 'Analyzes post content for SEO improvements.', 
'my-seo-plugin' ),
    'thinking_message' => __('Reviewing your content now!'),
    'success_message' => __('Content reviewed successfully.'),
    'execute_callback'    => [ 'MySEOPlugin', 'analyze_content' ],
    'input_schema'  => [
        'type' => 'object',
        'properties' => [
            'post_id' => [ 'type' => 'integer', 'description' => __( 'The post identifier.', 'my-seo-plugin' ), 'required' => true ],
        ],
        'additionalProperties' => false,
    ],
    'output_schema' => ]
        'type' => 'number',
        'description' => __( 'The score for the content in percentage.', 'my-seo-plugin' ),
        'required' => true,
    ],
    'permission_callback'  => 'edit_posts',
] );

More details in the announcement post:

https://make.wordpress.org/ai/2025/07/17/abilities-api/

See also Feature API as a reference:

• https://github.com/Automattic/wp-feature-api/blob/trunk/includes/wp-feature.php
• https://github.com/Automattic/wp-feature-api/blob/trunk/includes/class-wp-feature-registry.php
• https://github.com/Automattic/wp-feature-api/blob/trunk/includes/class-wp-feature.php

[justlevine]

I know @/Jameswlepage included them in the announcement post, but since I can't find the actual discussion behind it, I'd love clarification on the goals of thinkingMessage and successMessage (or their snake_case equivalents)

IMO these seem very tied to the current and short-lived chatbot model and will have trouble scaling. Would strongly recommend a more generic 'statuses': array<string,string> of ability specific status keys paired with their translatable messages.

Those could then be used (and validated) inside the callbacks, e.g. (pseudocode)

// ...
'execute_callback' => static function ( WP_Ability $ability, ...$other_args_maybe ) : true|WP_Error {
  $did_stuff = $ability->do_stuff();

  if ( is_wp_error( $did_stuff ) {
    return $did_stuff;
  }
    
  $ability->set_status( 'did_stuff' ); // error/warn/return bad-value if status isnt in array.
  return $ability->do_more_stuff();
},
// ...

Similar to how WP handles label and meta_cap inheritence, we could have a default array of statuses that are inherited, e.g.

[
  'start' => sprintf( __( 'Starting %s'), $label ), 
  'success' => sprintf( __( '%s completed successfully'), $label )
]

---

Separately/more generally, I strongly suggest we avoid using thinking* to represent any sort of state. Not just is it inaccurate, but it doesn't actually give any indication of what part of the API lifecycle it represents

[gziolo]

I know @/Jameswlepage included them in the announcement post, but since I can't find the actual discussion behind it, I'd love clarification on the goals of thinkingMessage and successMessage (or their snake_case equivalents)

I copied them from the post (now updated to snake_case for consistency and to follow WP coding conventions). I'll share the initial proposal of the API early next week the latest. I'm inclined to start with meta to keep stuff like that possible initially, before we have actual usage to make it final in the API.

[gziolo]

I drafted a PR to share the code with accompanying tests:

• Implement server-side registry for Abilities API  #3

I would appreciate some help in configuring the repository to run PHPUnit tests locally and enabling a GitHub action that runs the tests on every commit. We will also need other tools integrated to run code analysis.

[justlevine]

I would appreciate some help in configuring the repository to run PHPUnit tests locally and enabling a GitHub action that runs the tests on every commit.

I should have time over the weekend, will setup wpcs/phpunit/phpstan and the accompanying ci.

[justlevine]

I should have time over the weekend, will setup wpcs/phpunit/phpstan and the accompanying ci.

Still to write docs and a PR description, but you can see PHPCS, PHPStan, and PHPUnit (with coverage) working in:

• chore: scaffold plugin entrypoint and tooling #4

Right now it's based on #3 to prove it works, but if that's gonna be in review for a while, I can rebase it onto trunk 🤷