WordPress Playground

When to use it

Build, debug or review WordPress Playground Blueprints, @wp-playground/cli setups, query/embed links and shareable plugin or theme reproductions. Use for boot failures, resource/mount problems and untrusted-Blueprint review. Not a substitute for real MySQL or host testing.

Boundaries and hand-offs

• Test strategy and CI design for the plugin itself: wp-devkit-test-strategy and wp-devkit-ci-cd-and-release-engineering ; this skill covers the Playground layer.
• Security review of the plugin under test: wp-devkit-security-review .
• Real database, cache, cron or host behavior: use wp-env/Docker, not Playground.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:playground-review <target-path>

The short form /wp-devkit:playground requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-playground-development
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• blueprint-authoring.md : Blueprint authoring and review
• cli-and-local-environments.md : Playground CLI and local environments
• embedding-and-query-api.md : Embedding, query API and shareable links
• playground-development-workbook.md : Playground development workbook

How a review runs

1. List every step and resource; read all runPHP , runPHPWithOptions , runSql , wp-cli , writeFile(s) , archive imports and URLs before anything runs ( references/blueprint-authoring.md , trust review). Do not execute them.
2. Validate against the schema used by the installed generation; parsing JSON is not validation.
3. Check step order, resource types, pinning and CORS-reachable URLs; record resolved versions of aliases.
4. For CLI work, read the installed --help , then check flags, mounts and persistence mode ( references/cli-and-local-environments.md ). For links and embeds, check query parameters, bundle layout, origins ( references/embedding-and-query-api.md ).
5. Confirm the reproduction has a seed, a named trigger and an expected/observed pair; otherwise it is a setup, not a reproduction.
6. Describe the fresh-instance, missing-resource and second-run checks. Report runtime behavior as unexecuted unless it was run. Read references/playground-development-workbook.md for the decision table, symptoms, false positives, severity and acceptance checks. Optional disposable setup material: references/playground-isolation-fixture.json (not a defect reproduction; limits in the workbook).

What you get back

Lead with the result and reviewed scope (files read, nothing executed). Confirmed concern: file:line, actor, trigger, reachable path, impact, confidence, minimal fix, regression check. Keep candidates and "not established" items separate. Implementation: Blueprint/command, resolved versions, CLI and Node versions, exit codes, fresh-instance result, what remains unexecuted. A successful Playground boot does not prove MySQL, hosting, cache or production behavior.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.