A Local WordPress the Agent Can Reach

The previous module ended with a rules file telling the agent not to guess. This lesson gives it something better than a rule: an installation it can query. The difference shows up in the first minute of a real task. Without an install, an agent asked to check a hook has two options, and it takes the second one. It reasons from training data, or it writes a stub and tests against the stub.

That failure is documented rather than theoretical. In a recorded agent run, the agent wrote its own implementations of wp_kses_post(), get_block_wrapper_attributes() and esc_attr__(), tested its plugin against them, and reported green. Its summary admitted the WP-CLI command could not be run because no WordPress was present. The stubs happened to be right that time. The method cannot tell you when they are wrong, which is the only thing verification is for.

An agent tests what it can execute

Give the agent an install and the loop changes shape. It can call function_exists() for an API it is unsure about. It can activate the plugin and read what WordPress says. It can query a post table to confirm the block attribute persisted. It can fetch a front-end URL and look for its own markup in the response.

Those four checks are not sophisticated. They are the same checks you would run, and they have the property that matters: they can fail. A stub harness written by the model cannot fail in a way that teaches the model anything, because the stub and the belief behind it are the same artifact.

Three ways to get an install, and when each is right

Playground CLI runs WordPress in WebAssembly with SQLite, so there is no database server and no Docker daemon to install. The official wp-playground skill states its requirements plainly: WordPress 7.0 or newer, PHP 7.4 or newer, and Node.js 20.18 or newer for the CLI. On launch it detects where your current code should live and mounts a plugin into wp-content/plugins or a theme into wp-content/themes by recognising plugin headers or a theme's style.css. That detection is the feature that matters for agent work: the agent can run one command from inside your plugin directory and get a working site with the plugin mounted.

wp-env is the WordPress-developer standard. It runs WordPress and a database in Docker from a JSON configuration file, which makes it the right choice when you need a database server you can connect to with a client, or when you want the site's PHP version pinned to match production. Gutenberg's own AGENTS.md uses it and gives the instruction that matters for an agent: check status first and only start the environment if it is not already running.

A manual install is what you already have if you develop locally, and it is usually the fastest path to an agent that can run WP-CLI. It also has the sharpest edges, covered next.

WP-CLI is the agent's interface to WordPress

An agent does not need a browser to verify most of what you will ask it to do. WP-CLI gives it a command for nearly everything, and the commands are stable and scriptable. The ones worth giving the agent in its rules file or its prompt are the boring ones:

wp core version                                  # what am I actually running
wp plugin activate acme-notice                   # does it activate
wp plugin list --fields=name,status              # what is active right now
wp eval 'var_dump( function_exists( "wp_kses_post" ) );'
wp post list --post_type=page --fields=ID,post_title
wp option get siteurl                            # which site am I pointed at

The wp eval line is the one to internalise, because it answers the exact question an agent gets wrong most often. An agent that is unsure whether get_block_wrapper_attributes() exists can ask WordPress instead of its own memory, and the answer is a boolean from the running site. In the live install used for this lesson, that check returns:

$ wp eval 'var_dump( function_exists( "wp_kses_post" ), function_exists( "get_block_wrapper_attributes" ) );'
bool(true)
bool(true)

Point the same check at a function that does not exist and the output is the same shape, which is what makes it a usable gate: function_exists( "acme_sanitize_notice_message" ) returns false on that install. A stub cannot lie to you about that. WordPress can.

WP-CLI fails loudly, and the messages are worth knowing

Two failures show up in almost every local WordPress setup, and both look like something else.

A wp-config.php that never loads WordPress. WP-CLI bootstraps WordPress by including your config file and expecting it to include WordPress in turn. If yours defines the database constants and stops, WP-CLI reports a strange config file and refuses to proceed. The fix is the last line of the sample config that people delete when they write their own: require_once ABSPATH . 'wp-settings.php';.

Nothing works until WordPress is installed. Both wp scaffold plugin and wp scaffold _s refuse to run against an uninstalled tree, which kills the plan of scaffolding now and installing later. Run the install first. While you are there, note that wp scaffold _s emits a classic PHP-template theme with no theme.json and a style.css header still declaring "Tested up to: 5.4" — a trap for module 3, but one worth knowing before you let an agent run the command and call the result modern.

There is also environmental noise you should expect and tell the agent to ignore. On the machine used here, WP-CLI 2.12.0 running on PHP 8.5.6 prints a deprecation notice from a bundled library before every command. An agent that treats that notice as its failure signal will chase a bug that is not there, so the rules file should name the noise or the agent should be told to filter it with --quiet or an error-reporting level.

The official skill exists because this is the hard part

WordPress publishes an agent skill for exactly this job. The wp-playground skill, in the WordPress/agent-skills repository, is documented as "a new AI agent skill designed to run WordPress via the Playground CLI, giving agents a fast, repeatable way to run WordPress and verify their work as they iterate". Its author's stated reason is the clearest statement of the problem in this course: agents work better when they have a clear feedback loop.

The skill also documents behaviour that matters for a real loop. Agents in testing alternated between curl and Playwright to interact with the site, verify results, apply fixes and re-verify. Helper scripts cut the time to a testable WordPress from about a minute to a few seconds, and the Playground CLI can log in automatically for WP-Admin testing. It ships with a guardrail worth repeating to your agent verbatim: Playground instances are disposable and SQLite-backed, so never point them at production data.

The same repository carries a wp-env skill for the Docker path and a wp-wpcli-and-ops skill whose opening procedure is to confirm the environment and the blast radius before running anything that writes.

What the agent needs to be able to reach

Having an install is not the same as the agent being able to use it. Three specific constraints cause most of the failures.

Working directory. WP-CLI resolves the site from its current directory or a --path argument. An agent running commands from your plugin's repository will not find the site unless it is told where it is. Put the path in the rules file rather than in each prompt.

Network. A sandboxed agent that cannot reach the network cannot run wp plugin install, install Composer dependencies, or fetch the WordPress download. Check the sandbox's allowed hosts before assuming a command failed for a code reason.

Database credentials. The database user needs to exist and the credentials in the config file need to be right, because the resulting error message rarely says "credentials". An agent will happily interpret a connection failure as a plugin bug and start editing your code. Giving it a known-good baseline is part of setup.

$ wp core version
7.1.3
$ wp plugin list --fields=name,status
name          status
acme-blocks   inactive
acme-notice   active
akismet       inactive
hello         inactive
$ wp eval 'var_dump( function_exists( "wp_kses_post" ) );'
bool(true)