wp-abilities-api
WordPress Abilities API registration, REST exposure, and client-side consumption for WordPress 6.9+.
- Register abilities and categories in PHP using
wp_register_ability()andwp_register_ability_category()with stable IDs, labels, and metadata - Expose abilities to clients via the
/wp-json/wp-abilities/v1/REST endpoints by settingmeta.show_in_rest: true - Consume abilities in JavaScript using the
@wordpress/abilitiespackage for client-side access and permission checks - Requires WordPress 6.9+ (PHP 7.2.24+) and works with WP core, plugins, and themes; some workflows need WP-CLI
WP Abilities API
When to use
Use this skill when the task involves:
- registering abilities or ability categories in PHP,
- exposing abilities to clients via REST (
wp-abilities/v1), - consuming abilities in JS (notably
@wordpress/abilities), - diagnosing “ability doesn’t show up” / “client can’t see ability” / “REST returns empty”.
Inputs required
- Repo root (run
wp-project-triagefirst if you haven’t). - Target WordPress version(s) and whether this is WP core or a plugin/theme.
- Where the change should live (plugin vs theme vs mu-plugin).
Procedure
1) Confirm availability and version constraints
- If this is WP core work, check
signals.isWpCoreCheckoutandversions.wordpress.core. - If the project targets WP < 6.9, you may need the Abilities API plugin/package rather than relying on core.
2) Find existing Abilities usage
Search for these in the repo:
wp_register_ability(wp_register_ability_category(wp_abilities_api_initwp_abilities_api_categories_initwp-abilities/v1@wordpress/abilities
If none exist, decide whether you’re introducing Abilities API fresh (new registrations + client consumption) or only consuming.
3) Register categories (optional)
If you need a logical grouping, register an ability category early (see references/php-registration.md).
4) Register abilities (PHP)
Implement the ability in PHP registration with:
- stable
id(namespaced), label/description,category,meta:- add
readonly: truewhen the ability is informational, - set
show_in_rest: truefor abilities you want visible to clients.
- add
Use the documented init hooks for Abilities API registration so they load at the right time (see references/php-registration.md).
5) Confirm REST exposure
- Verify the REST endpoints exist and return expected results (see
references/rest-api.md). - If the client still can’t see the ability, confirm
meta.show_in_restis enabled and you’re querying the right endpoint.
6) Consume from JS (if needed)
- Prefer
@wordpress/abilitiesAPIs for client-side access and checks. - Ensure build tooling includes the dependency and the project’s build pipeline bundles it.
Verification
wp-project-triageindicatessignals.usesAbilitiesApi: trueafter your change (if applicable).- REST check (in a WP environment): endpoints under
wp-abilities/v1return your ability and category when expected. - If the repo has tests, add/update coverage near:
- PHP: ability registration and meta exposure
- JS: ability consumption and UI gating
Failure modes / debugging
- Ability never appears:
- registration code not running (wrong hook / file not loaded),
- missing
meta.show_in_rest, - incorrect category/ID mismatch.
- REST shows ability but JS doesn’t:
- wrong REST base/namespace,
- JS dependency not bundled,
- caching (object/page caches) masking changes.
Escalation
- If you’re uncertain about version support, confirm target WP core versions and whether Abilities API is expected from core or as a plugin.
- For canonical details, consult:
references/rest-api.mdreferences/php-registration.md
More from wordpress/agent-skills
wp-plugin-development
Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.
2.3Kwp-rest-api
Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.
1.8Kwp-block-themes
Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching).
1.7Kwp-performance
Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.
1.6Kwp-block-development
Use when developing WordPress (Gutenberg) blocks: block.json metadata, register_block_type(_from_metadata), attributes/serialization, supports, dynamic rendering (render.php/render_callback), deprecations/migrations, viewScript vs viewScriptModule, and @wordpress/scripts/@wordpress/create-block build and test workflows.
1.5Kwordpress-router
Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging).
1.4K