用途：处理 WordPress Abilities API 相关任务，包括在 PHP 中注册的能力与能力类别、通过 REST（wp-abilities/v1）向客户端暴露能力、在 JS 中消费能力（@wordpress/abilities），以及诊断“能力不显示”“客户端看不到能力”“REST 返回为空”等问题。
输入前提：仓库根目录（建议先运行 wp-project-triage）；目标 WordPress 版本及属于核心还是插件/主题；改动应放置的位置（插件、主题或 mu-plugin）。
主要能力与流程：先区分领域能力层与投影层（MCP、命令面板、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：信息类能力设 readonly: true，需对客户端可见的能力设 show_in_rest: true；使用文档规定的初始化钩子。随后验证 REST 暴露，必要时用 @wordpress/abilities 在 JS 侧消费并确保构建工具包含依赖。
验证与限制：改动后 wp-project-triage 应显示 signals.usesAbilitiesApi: true；在 WP 环境中检查 wp-abilities/v1 端点返回预期能力与类别。常见失败：注册代码未运行、缺少 show_in_rest、类别/ID 不匹配；REST 有但 JS 无——REST 基址/命名空间错误、依赖未打包或缓存；执行回调异常或忽略输入——输入 schema 默认值、分页键漂移或基于 empty() 的 ID 校验问题。若不确定版本支持，需先确认目标 WP 核心版本及 Abilities API 来自核心还是插件。