用途：当任务涉及 WordPress Abilities API 时使用本技能，包括在 PHP 中注册 ability 或 ability category、通过 REST（wp-abilities/v1）向客户端暴露能力、在 JS 中消费能力（如 @wordpress/abilities），以及诊断“能力不显示”“客户端看不到能力”“REST 返回空”等问题。
主要能力与流程：先确认可用性与版本约束，检查 signals.isWpCoreCheckout 和 versions.wordpress.core；若目标 WP 低于 6.9，可能需要 Abilities API 插件/包而非依赖核心。然后在仓库中搜索 wp_register_ability(、wp_register_ability_category(、wp_abilities_api_init、wp_abilities_api_categories_init、wp-abilities/v1、@wordpress/abilities，判断是全新引入还是仅消费。如需分组，可先注册能力分类。随后在 PHP 中注册能力，包含带命名空间的稳定 id、label/description、category 和 meta：信息类能力设 add readonly: true，需对客户端可见的能力设 show_in_rest: true，并使用文档规定的 init 钩子确保正确时机加载。再验证 REST 端点存在且返回符合预期；若客户端仍看不到，确认 meta.show_in_rest 已启用且查询的是正确端点。最后按需从 JS 消费，优先使用 @wordpress/abilities 做客户端访问与检查，并确保构建工具包含该依赖。
验证与调试：变更后 wp-project-triage 应显示 signals.usesAbilitiesApi: true；在 WP 环境中检查 wp-abilities/v1 下端点是否按预期返回能力与分类；可在 PHP（能力注册与 meta 暴露）和 JS（能力消费与 UI 门控）附近补充测试。常见失败原因：注册代码未运行（钩子错误或文件未加载）、缺少 meta.show_in_rest、分类/ID 不匹配；REST 可见但 JS 不可见可能是 REST 基址/命名空间错误、JS 依赖未打包或缓存（对象/页面缓存）掩盖变更。若不确定版本支持，需确认目标 WP 核心版本及 Abilities API 来自核心还是插件；规范细节可参考 references/rest-api.md 与 references/php-registration.md。要求输入包括仓库根目录、目标 WordPress 版本及是否为核心/插件/主题，以及改动应落在插件、主题还是 mu-plugin。