fix(ai): resolve ability IDs when tool name differs from ability ID - #1175

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

rg -n -C 8 \
  'wp_register_ability|wp_get_abilities|operationId|str_ends_with' \
  packages \
  --glob '*.php' \
  --glob '*.ts' || true

Repository: imjlk/wp-typia

Length of output: 1943

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

printf 'repo root files (top-level):\n'
git ls-files | sed -n '1,50p'

printf '\ncandidate file exists?\n'
if [ -f packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts ]; then
  wc -l packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts
  sed -n '730,800p' packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts | cat -n
else
  fd -i 'cli-add-workspace-ai-templates.ts' .
fi

printf '\nability-related searches in packages:\n'
rg -n -C 8 \
  'wp_register_ability|wp_get_abilities|operationId|str_ends_with|get_id\(\)|property_exists\(.*id' \
  packages \
  --glob '*.php' \
  --glob '*.ts' \
  --glob '*.tsx' || true

Repository: imjlk/wp-typia

Length of output: 1914

🌐 Web query:

WordPress wp_find_abilities function complete abilities registry unique name suffix

💡 Result:

The WordPress Abilities API, introduced in version 6.9.0, does not contain a function named wp_find_abilities. Instead, the registry system utilizes specific functions and class methods for retrieving and querying registered abilities. The Abilities Registry is managed by the WP_Abilities_Registry class, which stores abilities in a collection [1][2]. Abilities are identified by a unique name that must follow a namespaced format, typically namespace/ability-name [3][2][4]. Key mechanisms for interacting with the registry include: 1. Retrieval Functions: - wp_get_ability( string $name): Retrieves a specific registered ability instance by its unique name [5][1]. - wp_get_abilities: Returns an array of all currently registered abilities [6][1]. - wp_has_ability( string $name): A boolean check to determine if an ability is registered [1]. 2. Registry Implementation: The WP_Abilities_Registry class provides the internal logic for registration and retrieval [1][2]. Registration is performed via wp_register_ability( string $name, array $args), which enforces naming conventions [1][3][4]. Specifically, names must consist of lowercase alphanumeric characters, dashes, and a single forward slash to separate the namespace prefix from the ability identifier [3][4]. There is no specific "unique name suffix" requirement in the Abilities API; instead, uniqueness is guaranteed by the full namespaced string (e.g., my-plugin/my-ability) [3][2]. If you were searching for a way to list or filter abilities, wp_get_abilities is the standard approach to retrieve the complete registry [6].

Citations:

• 1: https://core.trac.wordpress.org/ticket/64098
• 2: https://developer.wordpress.org/apis/abilities-api/
• 3: https://developer.wordpress.org/reference/classes/WP_Abilities_Registry/register/
• 4: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php
• 5: https://developer.wordpress.org/reference/functions/wp_get_ability/
• 6: https://github.com/WordPress/abilities-api/blob/trunk/docs/php-api.md

🌐 Web query:

WordPress wp_find_abilities API operationId unique full name suffix

💡 Result:

The WordPress Abilities API does not define a specific operationId called wp_find_abilities. The primary functions for managing and interacting with abilities are wp_register_ability, wp_get_ability, wp_get_abilities, and wp_has_ability [1][2][3]. In the context of the WordPress REST API, operationId values typically follow a camelCase convention [4][5]. While the Abilities API exposes endpoints under the /wp-abilities/v1 namespace [6][7], these endpoints are defined by their HTTP methods and resource paths (e.g., /wp-abilities/v1/abilities or /wp-abilities/v1/(namespace)/(ability)/run) rather than a unified "find" operationId [6][7][8]. There is no formal API requirement for a unique full name suffix in this context. Abilities are registered with a namespaced string identifier (e.g., my-plugin/analyze-text) [2], and their execution via the REST API is handled by the WP_REST_Abilities_V1_Run_Controller class, which dynamically processes requests based on these identifiers [8].

Citations:

• 1: https://github.com/WordPress/abilities-api/blob/trunk/docs/php-api.md
• 2: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php
• 3: https://developer.wordpress.org/reference/files/wp-includes/abilities-api.php/
• 4: https://github.com/api-evangelist/wordpress/blob/main/rules/wordpress-spectral-rules.yml
• 5: https://raw.githubusercontent.com/api-evangelist/techcrunch/refs/heads/main/rules/techcrunch-wordpress-rules.yml
• 6: https://developer.wordpress.org/apis/abilities-api/rest-api-endpoints/
• 7: https://github.com/WordPress/abilities-api/blob/trunk/docs/rest-api.md
• 8: https://github.com/WordPress/wordpress-develop/blob/6.9.4/src/wp-includes/rest-api/endpoints/class-wp-rest-abilities-v1-run-controller.php

🌐 Web query:

WordPress wp_find_abilities 6.9.4 all_abilities prefix wp-abilities/v1

💡 Result:

The WordPress Abilities API, introduced in WordPress 6.9, provides a standardized way to register, discover, and execute plugin, theme, and core functionality [1][2][3]. The API uses the wp-abilities/v1 namespace for its REST API endpoints [4][3]. Key details regarding your query include: 1. Abilities API Namespace: All Abilities REST API endpoints are served under the wp-json/wp-abilities/v1 namespace [4][2][3]. 2. PHP Functionality vs. REST API: - There is no core function named wp_find_abilities [5][6]. The standard PHP function to retrieve all registered abilities is wp_get_abilities() [5][7]. - Abilities are not exposed via the REST API by default [4][3]. You must set the show_in_rest meta key to true when registering an ability using wp_register_ability() to make it available via the wp-abilities/v1 REST endpoints [4][3][8]. 3. REST API Endpoints: Once exposed, abilities can be accessed via [4][3]: - List all abilities: GET /wp-abilities/v1/abilities [4][3] - Get a single ability: GET /wp-abilities/v1/abilities/{name} [4][3] - Execute an ability: GET|POST|DELETE /wp-abilities/v1/abilities/{name}/run [4][7][3] The term all_abilities in your query typically refers to the variable used to store the array returned by the wp_get_abilities() function in PHP implementations [5][7][9]. Top results: [5][4][7][3]

Citations:

• 1: https://developer.wordpress.org/apis/abilities-api/
• 2: https://developer.wordpress.org/news/2025/11/introducing-the-wordpress-abilities-api/
• 3: https://make.wordpress.org/core/2025/11/10/abilities-api-in-wordpress-6-9/
• 4: https://developer.wordpress.org/apis/abilities-api/rest-api-endpoints/
• 5: https://github.com/WordPress/abilities-api/blob/trunk/docs/php-api.md
• 6: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php
• 7: https://wp-kama.com/handbook/codex/abilities-api
• 8: https://github.com/WordPress/wordpress-develop/blob/6.9.1/src/wp-includes/rest-api/endpoints/class-wp-rest-abilities-v1-list-controller.php
• 9: https://kinsta.com/blog/wordpress-abilities-api/

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

python3 - <<'PY'
import os, subprocess, re
from pathlib import Path

# Determine repo root from git metadata if possible.
try:
    repo = subprocess.check_output(["git", "rev-parse", "--show-toplevel"], text=True, stderr=subprocess.DEVNULL).strip()
except Exception as e:
    print(f"git rev-parse failed: {e}")
    exit(0)

print(f"repo: {repo}")
file_root = Path(repo, "packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts")
print(f"target exists: {file_root.exists()}")
if file_root.exists():
    lines = file_root.read_text().splitlines()
    print(f"lines: {len(lines)}")
    for i in range(730, min(800, len(lines))):
        print(f"{i+1:4d}: {lines[i]}")

print("\nability-related lines:")
search = re.compile(r'wp_register_ability|wp_get_ability|wp_get_abilities|wp_find_abilities|wp-abilities/v1|operationId|get_id\(\)|property_exists\(.*id|str_ends_with')
count = 0
for path in Path(repo).rglob("*"):
    if not path.is_file():
        continue
    if path.name.endswith((".php", ".ts", ".tsx")):
        try:
            text = path.read_text(errors="ignore")
        except Exception:
            continue
        for j, line in enumerate(text.splitlines(), 1):
            if search.search(line):
                count += 1
                if count <= 120:
                    print(f"{path}:{j}: {line.strip()}")
print(f"total matches: {count}")
PY

Repository: imjlk/wp-typia

Length of output: 1914

🌐 Web query:

site:github.com/WordPress/ wordpress-develop trunk wp-includes/abilities-api.php wp_find_abilities

💡 Result:

The wp_find_abilities function is a specific core ability introduced in WordPress 6.9, primarily designed to allow users to discover available abilities within the WordPress system [1]. It is managed via the Abilities API, which provides a unified, extensible framework for registering and executing discrete capabilities [2][3]. Key details regarding wp_find_abilities and the Abilities API include: Purpose and Availability: The core/find-abilities ability, which maps to the functional logic of wp_find_abilities, allows for the discovery of registered abilities [1]. It supports optional filtering by namespace and the show_in_rest property [1]. Access to this ability typically requires the read capability to prevent unauthorized enumeration while remaining accessible to authenticated users [1]. Implementation Context: The Abilities API, including the wp-includes/abilities-api.php file, serves as the registry and management layer for these capabilities [2][3]. Abilities must generally be registered using wp_register_ability during the wp_abilities_api_init action, although recent updates have allowed for registration after the init action in specific contexts [2][4]. Evolution and Filtering: Following the initial release of the Abilities API in WordPress 6.9, improvements have been made to increase flexibility. For example, recent developments (such as those tracked in Trac ticket #64990) have focused on adding comprehensive filtering support to functions like wp_get_abilities to allow for more granular retrieval of abilities by category, namespace, or meta properties [5]. For developers, the primary point of interaction is the Abilities API documentation and the source code located in wp-includes/abilities-api.php, which defines the registration and retrieval primitives [2][3].

Citations:

• 1: Add initial core abilities for WordPress 6.9 WordPress/abilities-api#108
• 2: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php
• 3: https://github.com/WordPress/abilities-api/blob/trunk/docs/php-api.md
• 4: Abilities API: Allow registration after init WordPress/wordpress-develop#12401
• 5: Feature #64990: Add filtering support to wp_get_abilities() via $args array WordPress/wordpress-develop#11531

🌐 Web query:

site:developer.wordpress.org/reference/functions/wp_get_abilities/

💡 Result:

wp_get_abilities() retrieves all currently registered WordPress abilities.

$abilities = wp_get_abilities();

foreach ( $abilities as $ability ) {
    echo $ability->get_label();
}

• Returns: WP_Ability[]
• Returns an empty array if no abilities are registered or the registry is unavailable.
• Introduced: WordPress 6.9.0. (developer.wordpress.org)

Citations:

• 1: https://developer.wordpress.org/reference/functions/wp_get_abilities/?utm_source=openai

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

source_file='packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts'
test_file='packages/wp-typia-project-tools/tests/typia-llm-tool-endpoint.test.ts'

if rg -n '\bget_id\s*\(' "$source_file"; then
  echo 'The generated fallback still uses get_id().' >&2
  exit 1
fi

rg -n -C 3 '\bget_name\s*\(' "$source_file" "$test_file"

Repository: imjlk/wp-typia

Length of output: 1901

🌐 Web query:

WordPress WP_Ability class get_name property names wp_get_abilities

💡 Result:

The WP_Ability class is part of the WordPress Abilities API, introduced in WordPress 6.9.0 [1][2]. The WP_Ability::get_name method is a public method used to retrieve the name of an ability, including its namespace (e.g., my-plugin/my-ability) [3][1]. It returns the value of the protected $name property defined within the class [3][4]. Regarding wp_get_abilities, this is a global function that returns an array of all ability instances currently registered in the system [5][6]. Each element in the returned array is an instance of the WP_Ability class [5]. In summary: - WP_Ability::get_name: Retrieves the name of a specific ability instance [3][2]. - wp_get_abilities: Returns a collection of all registered WP_Ability objects [5][6]. Developers typically use wp_get_abilities to retrieve the full list of abilities, and then call get_name on individual instances as needed for discovery or display purposes [5][6].

Citations:

• 1: https://developer.wordpress.org/reference/classes/wp_ability/
• 2: https://wp-kama.com/function/WP_Ability::get_name
• 3: https://developer.wordpress.org/reference/classes/wp_ability/get_name/
• 4: https://developer.wordpress.org/reference/classes/wp_ability/__construct/
• 5: https://developer.wordpress.org/reference/functions/wp_get_abilities/
• 6: https://github.com/WordPress/abilities-api/blob/trunk/docs/php-api.md

🌐 Web query:

developer.wordpress.org reference classes WP_Ability methods properties get_id id

💡 Result:

The WP_Ability class is a component of the WordPress Abilities API introduced in WordPress 6.9.0 [1][2]. It is used to encapsulate an "Ability"—a distinct unit of functionality that can be discovered and executed, often used in AI or automation contexts [3]. Regarding your query about get_id and id: 1. Properties: The WP_Ability class does not explicitly list a public property named $id in its core definition [1][2][4]. Instead, it uses a $name property (provided during registration) to identify the ability [2][5]. 2. Methods: The WP_Ability class does not provide a standard get_id method in the core WordPress implementation [1][2][6]. It is important not to confuse the core WP_Ability class with third-party implementations or similarly named classes. For example, some custom abstractions or plugin-specific classes (like Astra_Abstract_Ability) may define their own get_id methods and $id properties to handle internal tracking [7]. Additionally, in the context of your own plugin code, you might manually include an ID in your metadata or schema definitions [8], but this is not a native feature of the WP_Ability class itself. To interact with registered abilities, you should generally use the WP_Abilities_Registry, which manages these instances [3]. The ability name (passed to wp_register_ability) serves as the unique identifier [9][5].

Citations:

• 1: https://developer.wordpress.org/reference/classes/wp_ability/
• 2: https://github.com/WordPress/WordPress/blob/master/wp-includes/abilities-api/class-wp-ability.php
• 3: https://developer.wordpress.org/apis/abilities-api/
• 4: https://github.com/WordPress/wordpress-develop/blob/6.9.4/src/wp-includes/abilities-api/class-wp-ability.php
• 5: https://developer.wordpress.org/reference/classes/wp_ability/__construct/
• 6: https://developer.wordpress.org/reference/classes/wp_ability/execute/
• 7: https://developers.wpastra.com/astra-theme/reference/classes/astra_abstract_ability/
• 8: https://wprobo.com/how-to-register-custom-woocommerce-abilities-for-the-wordpress-mcp-adapter/
• 9: https://developer.wordpress.org/apis/abilities-api/php-reference/

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

source_file='packages/wp-typia-project-tools/src/runtime/add/cli-add-workspace-ai-templates.ts'

printf 'Repository checkout status:\n'
git status --short | sed -n '1,20p' || true

printf '\nLines 750-790 in source file:\n'
sed -n '750,790p' "$source_file" | cat -n

printf '\nGenerated PHP snippets containing candidate_id/get_name/get_id/id checks:\n'
rg -n -C 4 '\$candidate_id|get_id|get_name|property_exists|str_ends_with|ability_not_found' "$source_file"

printf '\nRelevant tests mentioning namespaced ability IDs:\n'
fd -i '.*workspace.*ai.*templates.*|.*llm.*endpoint.*|.*ability.*' packages/wp-typia-project-tools/tests packages/wp-typia-project-tools/src 2>/dev/null \
  | sed -n '1,50p' || true

Repository: imjlk/wp-typia

Length of output: 1914