WordPress 6.9 Abilities API provides standardized capability discovery and execution for Data Machine operations. All REST API, CLI, and Chat tool operations delegate to registered abilities.

Overview

The Abilities API in inc/Abilities/ provides a unified interface for Data Machine operations. Each ability implements execute_callback with permission_callback for consistent access control across REST API, CLI commands, and Chat tools.

Total registered abilities: 201

This page documents the shape of the current ability surface and the source files that own each domain. For an exact live inventory, run wp abilities list --category=datamachine-* in a loaded WordPress install or inspect wp_register_ability() callsites under inc/Abilities/.

Multi-Agent Scoping

Data Machine follows a WordPress-shaped identifier model: agent_id is the stable numeric row ID, and agent_slug is the human-readable, portable identifier. Programmatic ability inputs should use explicit fields (agent_id when selecting by row ID, agent_slug when selecting by slug). The generic agent selector is reserved for CLI and resolver-style boundaries that intentionally accept either ID or slug. The PermissionHelper class resolves selectors to scoped agent and user IDs, enforces ownership checks via owns_resource() and owns_agent_resource(), and controls access grants via can_access_agent().

Registered Ability Domains

The current core registry has 201 datamachine/* abilities across these domains:

Workspace, GitHub, and code-review abilities are intentionally not registered by Data Machine core. They live in the data-machine-code extension plugin.

content_format remains the caller’s authoring/source format (markdown, html, or blocks) and is distinct from the stored post_content format selected by datamachine_post_content_format. Content/block abilities read the post type’s canonical stored format through DataMachineCoreContentContentFormat, convert to block markup for block edits, then convert back before writing.

Category Registration

Data Machine registers multiple ability categories via wp_register_ability_category() on the wp_abilities_api_categories_init hook. Category slugs use the datamachine-{domain} format (e.g. datamachine-content, datamachine-flow, datamachine-pipeline):

wp_register_ability_category(
    'datamachine-flow',
    array(
        'label' => 'Flow',
        'description' => 'Flow CRUD, scheduling, queue management, and webhook triggers.',
    )
);

See inc/Abilities/AbilityCategories.php for the full list of registered categories.

Permission Model

All abilities support both WordPress admin and WP-CLI contexts via the shared PermissionHelper:

// Standard permission check
PermissionHelper::can_manage(); // WP-CLI/background/pre-auth contexts pass; web users need a mapped Data Machine capability.

// Multi-agent scoped permission check. Requests may provide explicit
// `agent_id` or `agent_slug`; resolver boundaries may also accept `agent`.
PermissionHelper::can_access_agent($agent_id);
PermissionHelper::owns_resource($resource_user_id);
PermissionHelper::resolve_scoped_agent_id($params);
PermissionHelper::resolve_scoped_user_id($params);

Architecture

Delegation Pattern

REST API endpoints, CLI commands, and Chat tools delegate to abilities for business logic. Abilities are the canonical, public-facing primitive; implementation classes below an ability are internal details.

REST API Endpoint → Ability → Database / WordPress API
CLI Command → Ability → Database / WordPress API
Chat Tool → Ability → Database / WordPress API

Facade Pattern

Several top-level ability classes serve as facades that instantiate sub-ability classes from subdirectories; other domains are registered directly from their subdirectory classes:

• inc/Abilities/ChatAbilities.php → inc/Abilities/Chat/CreateChatSessionAbility.php, etc.
• inc/Abilities/EngineAbilities.php → inc/Abilities/Engine/RunFlowAbility.php, etc.
• Flow abilities are registered from inc/Abilities/Flow/CreateFlowAbility.php, inc/Abilities/Flow/QueueAbility.php, inc/Abilities/Flow/WebhookTriggerAbility.php, etc.

Ability Registration

Each abilities class registers abilities on the wp_abilities_api_init hook:

public function register(): void {
    add_action( 'wp_abilities_api_init', array( $this, 'register_abilities' ) );
}

Testing

Ability coverage lives in focused smoke tests under tests/ rather than a separate tests/Unit/Abilities/ tree. The ability-related smoke tests cover registration, schema contracts, permission contexts, chat/tool integration, source inventory, queue behavior, taxonomy cleanup, auth scoping, and wp-ai-client runtime boundaries. Run them through Homeboy or directly through the repository’s PHP smoke harness:

homeboy test data-machine

WP-CLI Integration

CLI commands execute abilities directly. See individual command files in inc/Cli/Commands/ for available commands.

Post Tracking

The PostTracking class in inc/Core/WordPress/PostTracking.php provides post tracking functionality for handlers creating WordPress posts.

Meta Keys:

• _datamachine_post_handler: Handler slug that created the post
• _datamachine_post_flow_id: Flow ID associated with the post
• _datamachine_post_pipeline_id: Pipeline ID associated with the post

Usage:

use DataMachineCoreWordPressPostTracking;

// After creating a post
$this->storePostTrackingMeta($post_id, $handler_config);