cwp abilities
shipped 1.0.0cwp abilities [env] [flags]
Acts on the local site. Name an environment to act there instead.
| Argument | What it is | Default |
|---|---|---|
[env] | environment to read (default: default_environment in cwp.yml) |
| Flag | What it does | Default |
|---|---|---|
--filter <text> | substring of the name, label or description | “ |
--with-agent | with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real | off |
Plus the shared flags --json, -v, --verbose, -q, --quiet and --dry-run.
What it does
Lists every ability a site registers, and what each one declares about itself.
The second column is the part that matters, because it is what decides which
guards cwp ability applies:
✓ bricks/get-page-elements — read — Get page elements
! bricks/set-page-elements — write, destructive — Set page elements
Not restricted to bricks/. This is the plain door onto WordPress’s own
Abilities API, so a plain WordPress site with abilities on it is served by exactly
this command. A Bricks 2.4 site with the SNN-BRX child theme registers 175.
145 of them are Bricks’ own. The rest come from the child theme’s namespace,
WordPress core’s and the MCP adapter’s.
--filter matches the name, the label or the description.
Example
cwp abilities # everything registered, locally
cwp abilities --filter revision
cwp abilities prod # what production actually has
cwp abilities --json # for a script
What it does not do
It reads and reports; it calls nothing.
It cannot make an unreachable ability surface reachable. If Bricks registered
nothing at all, cwp doctor names which of the four causes it is:
WordPress too old, Bricks too old, the AI surface switched off, or
BRICKS_DISABLE_MCP set.