Migrating WordPress Playground Documentation to WordPress.org

At the beginning of 2026, the Playground team received a community request to migrate the official WordPress Playground documentation to the standard Handbook format on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.

The current documentation uses Docusaurus, which offers several features that speed up our work, including a built-in internationalization system, component libraries, reusable components with MDX, and a configuration file for integrating external features like Kapa.ai.

Moving to the official handbook It establishes Playground as a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WordPress project and provides a familiar documentation structure for our users. However, migrating from our current setup presents a few unique technical challenges. Here is an update on our progress, the challenges we are navigating, and our roadmap for the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies..

The Challenge: Docusaurus vs. Handbook Formatting

To migrate to the WordPress.org Handbook format, we need to adapt our existing Docusaurus-specific components to work within the Handbook’s script rendering. Similar to the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project, we have created a JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file mapping all pages to be included in the new handbook.

We are taking two approaches to handle the markdown conversion:

  1. Duplication of the current format to a Handbook-friendly format.
  2. Migrating essential components to alternatives that can be natively rendered by the Handbook scripts.

The selected approach was the second, using alternative components compatible with both platforms, which avoids duplicating work and keeps both versions online.

Progress Report: What We’ve Completed & What’s in Progress

  • Anchor Links & IDs (Done): We have removed all hardcoded IDs used for internal page linking, as the Handbook handles this natively.
  • Asset Loading (Done): Docusaurus uses dynamic pointing for asset folders (like images). We have updated our approach to point directly to the raw files hosted on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/, ensuring images render correctly without issue.
  • MDX Fragments (In Review): Playground docs heavily utilize MDX fragments (reusable snippets of code/text used across multiple pages). We have created a PR to adapt these fragments for an inline structure, and it is currently under review.
  • Callout Components (To Do): Docusaurus components for Warnings, Info, and Tips currently do not render in the Handbook. We need to create alternatives for these to ensure important points of attention are still highlighted for the user.
  • SEO & Open Graph Data (To Do): We need to double-check our Open Graph data (logos, descriptions, titles). Currently, every page has a headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. defining its title and summary. We need to collaborate with the Handbook team to ensure these are being parsed dynamically for optimal SEO.

The Migration Roadmap

To ensure a smooth transition, we have broken the migration into three distinct phases:

Phase 1: The English Migration

Our immediate priority is to get the core English documentation published in the WordPress.org Handbook. During this time, both documents will be live; the English version will, in the meantime, redirect to the Handbook once the migration is complete.

Phase 2: Internationalization (i18n)

Playground boasts a highly localized user base, with over 220 pages translated into languages including Portuguese, Japanese, Spanish, French, Gujarati, Bengali, and Tagalog.

Because Handbook support for translations is still evolving, we have established a fallback strategy:

  • We will define a set of pages eligible for translation and publishing in the new handbook, something similar to what we have in the current docs. At a minimum, the first “blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.” of introductory pages must be translated; otherwise, the user will be redirected to the English version, the current behavior with Docusaurus.
  • Fallback Plan: Until Phase 2 is complete, we will keep the Docusaurus site live strictly as a fallback for international users. English traffic will be redirected to WordPress.org, while translated content will remain on Docusaurus until it can be safely migrated.

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia, @fellyph will be present and will lead the Contributor table for WordPress. One of the themes of the contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ for Playground will be the migration of the docs and the discussion of a solution for internationalization.

Phase 3: The “Ask AI” Feature

Late last year, we introduced the “Ask AI” button (powered by Kapa.ai) to help users find immediate answers to specific questions and blueprint rendering errors. This feature has been incredibly useful, but migrating it requires careful consideration.

  • Testing: The Kapa.ai team proposed to use the solution on the .org account. But this should be discussed with the Docs team to move forward.
  • Privacy Considerations: Because user queries are stored in the Kapa.ai dashboard, we need to have a detailed discussion with the documentation team regarding privacy policies before implementing this on the official .org domain.

Next Steps

The playground team will continue working on unblocking Phase 1 by resolving the remaining component and SEO metadata issues. We will also be reaching out to the Handbook and Docs teams to clarify our i18n redirect rules and the future of the Ask AI implementation.

Teach your coding agent to write WordPress Playground Blueprints

The new blueprint agent skill teaches your coding agent the Playground Blueprint schema, which defines valid property names, resource types, and step sequencing. No more pluginZipFile instead of pluginData. No more runPHP steps missing require '/wordpress/wp-load.php'.

Install it once, and your agent generates valid Blueprint JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. with a high success rate, and the best part of it all with natural language. That is perfect for testing new ideas, finding edge cases in your Plugins and Themes, and creating demos from your projects.

What the blueprint skill does

The skill is a structured Markdown reference that your coding agent loads into its context. It covers:

  • Every top-level property: landingPage, preferredVersions, features, steps, shorthands (login, plugins, siteOptions, constants)
  • All resource types: wordpress.org/plugins, wordpress.org/themes, url, git:directory, literal:directory, bundled
  • Step reference: installPlugin, writeFile, writeFiles, runPHP, wp-cli, runSql, and more
  • Common mistakes: a table of pitfalls the agent checks against before generating output
  • Blueprint bundles: self-contained packages with bundled resources

The agent reads this reference before writing any Blueprint. Instead of guessing property names, it follows the documented schema.

How to install the skill

For a quick install, use the npx skills CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. to add the blueprint skill to your project:

npx skills add wordpress/agent-skills --skill blueprint

Or install manually by cloning the agent-skills repository and running the build script:

git clone https://github.com/WordPress/agent-skills.git
cd agent-skills
node shared/scripts/skillpack-build.mjs --clean
node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=claude,gemini,codex,cursor,vscode

The skill works with Claude Code, Gemini CLI, GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ Copilot, Cursor, and Codex.

Five examples

Each example below shows a prompt you give your agent and the Blueprint it produces. These are real-world scenarios where the blueprint skill prevents common errors.

1. Quick development environment

Prompt:

Create a Blueprint that sets up a development environment with
debug mode, the Developer plugin, and landing on the admin dashboard.

Generated Blueprint:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "features": { "networking": true },
  "constants": {
    "WP_DEBUG": true,
    "WP_DEBUG_LOG": true
  },
  "login": true,
  "plugins": ["developer"],
  "steps": []
}

Notice how the agent uses the constants shorthand instead of a defineWpConfigConsts step, and login: true instead of a separate login step. The skill teaches agents to pick shorthands for simple cases and explicit steps when order matters.

WordPress Admin panel showing the Developer plugin enabled via blueprint

2. PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. from a GitHub branch

Prompt:

Write a Blueprint that installs my plugin from the feature/checkout-v2
branch on GitHub and activates it.

Generated Blueprint:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/plugins.php",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [
    { "step": "login" },
    {
      "step": "installPlugin",
      "pluginData": {
        "resource": "git:directory",
        "url": "https://github.com/your-org/your-plugin",
        "ref": "feature/checkout-v2",
        "refType": "branch",
        "path": "/"
      },
      "options": { "activate": true }
    }
  ]
}

Without the skill, agents commonly omit refType, which causes git:directory to fail for branch names. The skill’s common mistakes table flags this explicitly: “Omitting refType with branch/tag ref — required; only HEAD works without it.”

3. WooCommerce store with sample products

Prompt:

Create a Blueprint for a WooCommerce store with 5 sample products
across 2 categories, running on PHP 8.2.

Generated Blueprint:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/shop/",
  "preferredVersions": { "php": "8.2", "wp": "latest" },
  "features": { "networking": true },
  "steps": [
    { "step": "login" },
    {
      "step": "installPlugin",
      "pluginData": { "resource": "wordpress.org/plugins", "slug": "woocommerce" },
      "options": { "activate": true }
    },
    {
      "step": "runPHP",
      "code": "<?php\nrequire '/wordpress/wp-load.php';\n\n// Create categories\n$cat_clothing = wp_insert_term('Clothing', 'product_cat');\n$cat_accessories = wp_insert_term('Accessories', 'product_cat');\n\n$products = [\n  ['T-Shirt', 29.99, $cat_clothing['term_id']],\n  ['Hoodie', 59.99, $cat_clothing['term_id']],\n  ['Jeans', 49.99, $cat_clothing['term_id']],\n  ['Watch', 89.99, $cat_accessories['term_id']],\n  ['Backpack', 39.99, $cat_accessories['term_id']]\n];\n\nforeach ($products as [$title, $price, $cat_id]) {\n  $post_id = wp_insert_post([\n    'post_title' => $title,\n    'post_type' => 'product',\n    'post_status' => 'publish'\n  ]);\n  update_post_meta($post_id, '_regular_price', $price);\n  update_post_meta($post_id, '_price', $price);\n  wp_set_object_terms($post_id, [$cat_id], 'product_cat');\n}\n"
    }
  ]
}

The skill ensures the agent includes require '/wordpress/wp-load.php' at the top of every runPHP step. Without this line, all WordPress functions fail silently — a mistake agents make frequently without the skill reference.

WordPress Playground Loading a store with 5 products in a woo store.

4. Inline mu-plugin for custom behavior

Prompt:

Write a Blueprint that disables the admin bar and adds a custom
dashboard widget showing the server's PHP version.

Generated Blueprint:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [
    { "step": "login" },
    {
      "step": "writeFile",
      "path": "/wordpress/wp-content/mu-plugins/custom-dashboard.php",
      "data": "<?php\nadd_filter('show_admin_bar', '__return_false');\n\nadd_action('wp_dashboard_setup', function() {\n  wp_add_dashboard_widget(\n    'php_version_widget',\n    'PHP Version',\n    function() {\n      echo '<p>Running PHP ' . phpversion() . '</p>';\n    }\n  );\n});"
    }
  ]
}

The agent uses writeFile to create a mu-plugin, which loads automatically without activation. The skill explicitly documents this pattern and warns agents not to add require wp-load.php inside mu-plugin code (that line is only needed in runPHP steps).

5. Blueprint bundle with a custom plugin

Prompt:

Create a Blueprint bundle that installs a custom analytics plugin
from a local zip file.

Generated bundle structure:

analytics-bundle/
├── blueprint.json
└── analytics-plugin.zip

blueprint.json:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/plugins.php",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [
    { "step": "login" },
    {
      "step": "installPlugin",
      "pluginData": {
        "resource": "bundled",
        "path": "/analytics-plugin.zip"
      },
      "options": { "activate": true }
    }
  ]
}

Run it locally:

npx @wp-playground/cli server --blueprint=./analytics-bundle/ --blueprint-may-read-adjacent-files

The --blueprint-may-read-adjacent-files flag is required for directory bundles. Without it, any bundled resource reference fails with a “File not found” error. The skill documents this gotcha, so agents include the flag automatically.

How the blueprint skill fits with other tools

The blueprint skill works alongside two other Playground tools for AI agents:

ToolWhat it doesWhen to use it
Blueprint skillGenerates valid Blueprint JSONWhen you need a Blueprint file for sharing, version control, or CI
wp-playground skillRuns CLI commands, manages servers, debugs instancesWhen you need a running Playground instance with live interaction
MCP serverConnects agents directly to a browser PlaygroundWhen you need real-time PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php execution and file manipulation

Use the blueprint skill when you want a portable, reproducible configuration. Use the wp-playground skill when you need a running server. Combine them: generate a Blueprint with the blueprint skill, then launch it with the wp-playground skill’s CLI commands.

Test your Blueprints

Inline URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org (quick test)

Minify the Blueprint JSON and append it to the Playground URL:

https://playground.wordpress.net/#{"preferredVersions":{"php":"8.3","wp":"latest"},"steps":[{"step":"login"}]}

Local CLI (full test)

# Start a server with your Blueprint
npx @wp-playground/cli server --blueprint=./blueprint.json

# Headless validation (runs and exits)
npx @wp-playground/cli run-blueprint --blueprint=./blueprint.json

Get started

Install the blueprint skill in your project:

npx skills add wordpress/agent-skills --skill blueprint

Then ask your agent to write a Blueprint. Describe what you need: plugins, themes, content, configuration, and the agent produces valid JSON that runs on the first try.

Share what you build in the #playground channel on Making WordPress Slack or open an issue on GitHub.

#agent-skills, #ai