Use for WordPress Playground workflows: fast disposable WP instances in the browser or locally via @wp-playground/cli (server, run-blueprint, build-snapshot), auto-mounting plugins/themes, switching WP/PHP versions, blueprints, and debugging (Xdebug).
wp-playground supports WordPress Playground workflows for fast, disposable WordPress instances in the browser or locally via the @wp-playground/cli package. It is used to spin up a disposable WordPress to test a plugin or theme without a full stack, to run or iterate on Playground Blueprints, to build reproducible site snapshots for sharing or CI, to switch WP and PHP versions to reproduce issues, and to debug plugin or theme code with Xdebug in isolation. Per its compatibility note, it targets WordPress 6.9+ (PHP 7.2.24+), the Playground CLI requires Node.js 20.18+, and WordPress runs in WebAssembly with SQLite. Required inputs include a ready host machine, the project path to mount, optional WP/PHP versions (defaulting to latest WP and PHP 8.3), a blueprint location if running one, a port preference if 9400 conflicts, and whether Xdebug is needed.
The procedure begins with guardrails: instances are ephemeral and SQLite-backed and must never point at production data, Node must be confirmed at 20.18 or higher, and mounted code should be free of secrets because Playground copies files into an in-memory filesystem. Quick local spin-up runs npx @wp-playground/cli@latest server --auto-mount, which opens on http://localhost:9400 by default and auto-detects and installs the plugin or theme, with --wp and --php flags to set versions. Manual or multiple mounts use the repeatable --mount=/host/path:/vfs/path option, and --mount-before-install bootstraps installer flows. Blueprints can run without a server via run-blueprint --blueprint=<file-or-url>, and build-snapshot --blueprint=<file> --outfile=./site.zip produces a shareable ZIP.
Debugging starts with --xdebug (or --enable-xdebug depending on CLI release) to expose an IDE key, then connecting VS Code or PhpStorm to the host and port shown. Version switching pins WP and PHP with --wp= and --php=. Browser-only workflows launch previews through URL fragments or query params on playground.wordpress.net, or via the live Blueprint Editor. Verification confirms that mounted code is active, re-runs with --verbosity=debug, and runs targeted smoke tests. The skill lists common failure modes (Node too old, mounts not applied, blueprints unable to read local assets needing --blueprint-may-read-adjacent-files, port conflicts, and slow UI tied to --experimental-multi-worker) and notes escalation paths when PHP extensions or native DB access are required, in which case Playground may be unsuitable and a full WP stack or wp-env/Docker is the fallback.
From the plugin or theme root, run `npx @wp-playground/cli@latest server --auto-mount`. It opens on http://localhost:9400 by default and auto-detects and installs the plugin or theme, with --wp and --php flags available to set versions.
The Playground CLI requires Node.js 20.18 or higher, and the skill targets WordPress 6.9+ (PHP 7.2.24+). It defaults to the latest WP and PHP 8.3, runs WP in WebAssembly with SQLite, and serves on port 9400 unless changed with --port.
Yes. Use `npx @wp-playground/cli@latest run-blueprint --blueprint=<file-or-url>`, which supports remote URLs and local files and is suited to scripted setup or CI validation. Add --blueprint-may-read-adjacent-files to allow bundled local assets.
No. Instances are ephemeral and SQLite-backed and must never point at production data. Mounted code should also be free of secrets, since Playground copies files into an in-memory filesystem.
If PHP extensions or native DB access are required, Playground may be unsuitable. The recommended fallback is a full WordPress stack or wp-env/Docker.
Quick Setup:
.claude/skills/Repository
wordpress/agent-skills