# Wp Abilities Verify

Verify a WordPress plugin's Abilities API registrations: enumerate abilities, check...

- Repository: https://github.com/WordPress/agent-skills (2319 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add WordPress/agent-skills --skill wp-abilities-verify -g -a claude-code -y`
Codex: `npx skills add WordPress/agent-skills --skill wp-abilities-verify -g -a codex -y`
Cursor: `npx skills add WordPress/agent-skills --skill wp-abilities-verify -g -a cursor -y`
Gemini CLI: `npx skills add WordPress/agent-skills --skill wp-abilities-verify -g -a gemini-cli -y`

## Description

Verify a WordPress plugin's Abilities API registrations: enumerate abilities, check that callback behavior matches each annotation's claim (the adversarial readonly-but-writes detection), validate permissions and schemas, and validate audit documents produced by wp-abilities-audit.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# WP Abilities Verify

Verify a WordPress plugin's Abilities API registrations. The
centerpiece is the **adversarial annotation correctness check**: a
`readonly: true` ability that actually writes (via `$wpdb->update`,
`update_option`, a non-GET delegate, etc.) is a security and UX
disaster because agents plan actions on the basis of the annotations
they introspect. This skill catches those lies by reading the callback
body and comparing what it does against what the annotation claims.

The skill also validates audit docs produced by `wp-abilities-audit`,
checks permission gates and schema hygiene, and optionally executes
each ability against a live environment.

## When to use

- After abilities have been registered in a plugin but before a PR
  lands.
- As a health-check on an already-shipped plugin (catch regressions
  where a refactor turned a readonly ability into a writing one).
- To validate an audit document before handing it to an implementer.

## Two modes

- **Static mode**, runs from the plugin checkout. No env. Enumerates
  via source inspection, runs the adversarial correctness check, runs
  schema and permission lints, and validates audit docs.
- **Runtime mode**, requires a running env. Does everything static
  does PLUS: `wp_get_abilities()` for authoritative enumeration,
  executes each ability with curated inputs, confirms permission
  roundtrip against real users, and runs a twin-invocation heuristic
  on `idempotent: true` abilities to flag candidates for review
  (return-value equality is a signal, not a verdict, core defines
  idempotent as "no additional effect on the environment").

Both modes produce the same structured report format.

A static-mode PASS means "no obvious-shape violations," not "verified
write-free." For high-stakes plugins, run runtime mode before landing, it catches bootstrap-order, permission-roundtrip, and idempotency
issues that static can't. See `references/annotation-correctness.md`
for the static blind spots.

The rest: https://github.com/WordPress/agent-skills/blob/HEAD/skills/wp-abilities-verify/SKILL.md