wp-abilities-api

The wp-abilities-api skill supports working with the WordPress Abilities API, covering wp_register_ability, wp_register_ability_category, the /wp-json/wp-abilities/v1/* REST endpoints, and the @wordpress/abilities JavaScript package. It is used for defining abilities and categories, attaching meta, exposing abilities to clients over REST, performing permission-style checks, and diagnosing problems where an ability does not show up or a client cannot see it. It targets WordPress 6.9+ on PHP 7.2.24+, operates as a filesystem-based agent with bash and node, and notes that some workflows require WP-CLI.

The procedure starts by confirming availability and version constraints, recommending a wp-project-triage run first and checking whether the project is a WP core checkout or a plugin/theme. For projects targeting WordPress below 6.9, the Abilities API plugin or package may be needed rather than core. It then searches the repository for existing usage (wp_register_ability(, wp_register_ability_category(, the init hooks wp_abilities_api_init and wp_abilities_api_categories_init, the wp-abilities/v1 REST namespace, and @wordpress/abilities) to decide whether to introduce the API fresh or only consume it. Categories can be registered for logical grouping, and abilities are registered in PHP with a stable namespaced id, label and description, a category, and meta, where readonly: true marks informational abilities and show_in_rest: true makes an ability visible to clients. Documented init hooks ensure registrations load at the right time.

The skill then verifies REST exposure, advising that if a client still cannot see an ability you should confirm meta.show_in_rest is enabled and that the correct endpoint is being queried, and covers consuming abilities from JavaScript via @wordpress/abilities, ensuring the dependency is bundled by the build pipeline. Verification suggestions include confirming wp-project-triage reports usesAbilitiesApi: true, checking that wp-abilities/v1 endpoints return the ability and category, and adding test coverage for PHP registration/meta exposure and JS consumption/UI gating. It enumerates failure modes such as registration code not running due to a wrong hook or unloaded file, missing meta.show_in_rest, category or ID mismatches, wrong REST base or namespace, an unbundled JS dependency, and caching masking changes. Canonical details live in references/php-registration.md and references/rest-api.md.