AutoGineer
Generated banner for Wordpress Router
Generated logo for Wordpress Router

Wordpress Router

WordPressOfficialPublished by WordPress

  • Skill
  • Meta (authoring, orchestration, planning, memory)
  • Software development
  • GPL-2.0-or-later
  • No issues found
Download ZIP

From the author

Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging).
— the description by WordPress

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The WordPress Router is a foundational skill designed to analyze a WordPress project directory and determine the appropriate development context. By running a triage script, it identifies the project type—such as a plugin, block theme, or core checkout—and maps the user's intent to the correct specialized workflow. This ensures that subsequent development tasks, whether related to block development, REST API integration, or security, are handled using the correct tools, guardrails, and conventions specific to that codebase.

What it does

  • Analyzes the project root to classify the WordPress codebase type.
  • Detects available tooling, including PHP, Composer, Node, and WordPress-specific scripts.
  • Routes user requests to specialized domain skills based on intent and project structure.
  • Provides a decision tree for handling various WordPress development scenarios.
  • Enforces guardrails by verifying version constraints and existing project conventions.

When to use it

  • At the beginning of any WordPress development task to ensure the correct context is set.
  • When you need to determine if a project is a plugin, theme, or core checkout.
  • When you are unsure which specialized WordPress skill or workflow to apply to a task.
  • Before performing structural changes or adding new features to a WordPress codebase.

Advantages

  • Prevents misconfiguration by identifying the project type before executing tasks.
  • Promotes consistency by respecting the existing build and test tooling of the repository.
  • Streamlines development by automatically delegating to the most relevant domain-specific workflows.
  • Reduces ambiguity in complex WordPress environments like full site repositories.

Usage examples

“I need to add a new REST API endpoint to this plugin.”
The router identifies the project as a plugin, confirms the environment, and routes the request to the wp-rest-api workflow.
“How do I update the global styles in this block theme?”
The router detects a block theme structure and delegates the task to the wp-block-themes workflow.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wordpress/wordpress-router/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip wordpress-router.zip -d .agents/skills

Documentation by WordPress

WordPress Router

When to use

Use this skill at the start of most WordPress tasks to:

  • identify what kind of WordPress codebase this is (plugin vs theme vs block theme vs WP core checkout vs full site),

  • pick the right workflow and guardrails,

  • delegate to the most relevant domain skill(s).

Inputs required

  • Repo root (current working directory).

  • The user’s intent (what they want changed) and any constraints (WP version targets, WP.com specifics, release requirements).

Procedure

  1. Run the project triage script:

    • node skills/wp-project-triage/scripts/detect_wp_project.mjs

  2. Read the triage output and classify:

    • primary project kind(s),

    • tooling available (PHP/Composer, Node, @wordpress/scripts),

    • tests present (PHPUnit, Playwright, wp-env),

    • any version hints.

  3. Route to domain workflows based on user intent + repo kind:

    • For the decision tree, read: skills/wordpress-router/references/decision-tree.md.

  4. Apply guardrails before making changes:

    • Confirm any version constraints if unclear.

    • Prefer the repo’s existing tooling and conventions for builds/tests.

Verification

  • Re-run the triage script if you create or restructure significant files.

  • Run the repo’s lint/test/build commands that the triage output recommends (if available).

Failure modes / debugging

  • If triage reports kind: unknown, inspect:

    • root composer.json, package.json, style.css, block.json, theme.json, wp-content/.

  • If the repo is huge, consider narrowing scanning scope or adding ignore rules to the triage script.

Escalation

  • If routing is ambiguous, ask one question:

    • “Is this intended to be a WordPress plugin, a theme (classic/block), or a full site repo?”

Files

references/decision-tree.md

Router decision tree (v1)

This is a lightweight routing guide. It assumes you can run wp-project-triage first.

Step 1: classify repo kind (from triage)

Use triage.project.kind and the strongest signals:

  • wp-core → treat as WordPress core checkout work (core patches, PHPUnit, build tools).

  • wp-site → treat as a full site repo (wp-content present; changes might be theme + plugins).

  • wp-block-theme → theme.json/templates/patterns workflows.

  • wp-theme → classic theme workflows (templates PHP, functions.php, style.css).

  • wp-block-plugin → Gutenberg block development in a plugin (block.json, build pipeline).

  • wp-plugin / wp-mu-plugin → plugin workflows (hooks, admin, settings, cron, REST, security).

  • gutenberg → Gutenberg monorepo workflows (packages, tooling, docs).

If multiple kinds match, prefer the most specific: gutenberg > wp-core > wp-site > wp-block-theme > wp-block-plugin > wp-theme > wp-plugin.

Step 2: route by user intent (keywords)

Route by intent even if repo kind is broad (like wp-site):

  • Interactivity API / data-wp- directives / @wordpress/interactivity / viewScriptModule*

    • Route → wp-interactivity-api.

  • Design, implement, or review an ability’s schemas, CRUD behavior, or permissions

    • Route → wp-ability-development.

  • Abilities API registration, exposure, or consumption / wp_register_ability / wp-abilities/v1 / @wordpress/abilities

    • Route → wp-abilities-api.

  • Ambiguous WordPress Playground requests

    • Route → wp-playground, then follow its routing wrapper.

  • Blueprint JSON / Blueprint schema / Blueprint steps / Blueprint bundles

    • Route → blueprint.

  • @wp-playground/cli / server / run-blueprint / build-snapshot / auto-mount / Xdebug

    • Route → wp-playground, then read references/cli.md or references/debugging.md.

  • playground.wordpress.net / Blueprint Editor / share links / browser-only Playground

    • Route → wp-playground, then read references/website.md.

  • Blocks / block.json / registerBlockType / attributes / save serialization

    • Route → wp-block-development.

  • theme.json / Global Styles / templates/*.html / patterns/

    • Route → wp-block-themes.

  • Plugins / hooks / activation hook / uninstall / Settings API / admin pages

    • Route → wp-plugin-development.

  • REST endpoint / register_rest_route / permission_callback

    • Route → wp-rest-api.

  • WP-CLI / wp-cli.yml / commands

    • Route → wp-wpcli-and-ops.

  • Build tooling / @wordpress/scripts / webpack / Vite / npm scripts

    • Route → wp-build-tooling (planned).

  • Testing / PHPUnit / wp-env / Playwright

    • Route → wp-testing (planned).

  • PHPStan / static analysis / phpstan.neon / phpstan-baseline.neon

    • Route → wp-phpstan.

  • Performance / caching / query profiling / editor slowness

    • Route → wp-performance.

  • Security / nonces / capabilities / sanitization/escaping / uploads

    • Route → wp-security (planned).

Step 3: guardrails checklist (always)

  • Verify detected tooling before suggesting commands (Composer vs npm/yarn/pnpm).

  • Prefer existing lint/test scripts if present.

  • If version constraints aren’t detectable, ask for target WP core and PHP versions.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

The author says: Targets WordPress 7.0+ (PHP 7.4.0+). Filesystem-based agent with bash + node. Some workflows require WP-CLI.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
WordPress
Publisher
WordPress (Official)
Source
WordPress/agent-skills · skills/wordpress-router · commit 7374e6f
Licence
GNU General Public License v2.0 or later (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by WordPress.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download wordpress-router.zip