Agentic workflows via systems like Github Copilot or Claude Code offer an exciting new opportunity for all devs. This is especially true for enterprise WordPress devs.

Recently, I’ve been experimenting with assigning GitHub Copilot to very well scoped issues, and the results have been impressive. In 1 week, we shipped 4 small new features to pewresearch.org. We would not have gotten to these for months, they were low priority. They required almost no human interaction beyond a code review.

1. A inspector panel to show when editing a Chart what posts that Chart is embedded in.
2. A inspector panel to show analytics on Quizzes. A visual heatmap of submissions and some stats around the first 24 hours, first day, first week of submissions.
3. A block binding for Remote Pivot Table that calculates the sum of a column.
4. Removing numerical prefixes from SEO titles, e.g. a post title with 3. The Post Title becomes just The Post Title for Google, etc..

While these were all impressive, one skill the agent lacked was the ability to actually check it’s work. I spoke with James LePage, head of AI for Automattic, about how to tackle this problem. He introduced me to WP Playground CLI. I didn’t even know that Playground had a CLI up to this point. After a few hours of experimentation, we have an agent that can actually browse the site off its codebase.

Getting Copilot to run WP Playground

You do need to allow the next domains in the Copilot agent firewall:

npmjs.org
localhost
w.org
wordpress.net
wordpress.org

Additionally, you should add a command to your package.json for either your plugin or monorepo npx @wp-playground/cli@latest server --auto-mount --blueprint=blueprint.json. 

This will auto mount the folders and files in place for the Playground ENV. It provides access to your plugin. In our case, it provides access to /wp-content as we’re working out of a monorepo.

In your AGENTS.md file be sure to give instructions for agents to start a lightweight env by running your command in package.json. See our AGENTS.md as an example.

Then add the workflow, and the command to your repo. Note the {{{ENV VARS AND KEYS GO HERE}}} this is where you can export your env secrets and such into the env.