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)

• User's intent (what they want changed) and any constraints (WP version targets, release requirements)

Procedure

1. Detect project type

Run quick detection checks:

Check for plugin indicators

ls -la | grep -E "^-.*.php$" | head -3 grep -l "Plugin Name:" *.php 2>/dev/null

Check for theme indicators

ls style.css 2>/dev/null && head -20 style.css

Check for block theme indicators

ls theme.json 2>/dev/null ls -d templates/ parts/ 2>/dev/null

Check for WP core

ls wp-includes/ wp-admin/ 2>/dev/null

Check for full site

ls wp-content/ 2>/dev/null

2. Classify the project

Indicators Type Primary Skill

Plugin Name: in PHP header Plugin wp-plugin-development

style.css with Theme Name:

Classic Theme wp-theme-development

theme.json

• templates/

Block Theme wp-block-themes

block.json files Has Blocks wp-gutenberg-blocks

wp-includes/

• wp-admin/

WP Core Core development workflow

wp-content/ present Full Site Multiple skills as needed

3. Route to domain workflow

Based on user intent + repo kind:

Intent Route To

Create/modify Gutenberg blocks wp-gutenberg-blocks

Block theme work (theme.json, templates) wp-block-themes

Add interactivity (data-wp-* directives) wp-interactivity-api

Plugin architecture, hooks, Settings API wp-plugin-development

Performance profiling/optimization wp-performance-review

Security audit wp-security-review

WP-CLI operations wp-wpcli-and-ops

Testing in isolation wp-playground

4. Apply guardrails

Before making changes:

• Confirm any version constraints if unclear

• Prefer the repo's existing tooling and conventions

• Check for existing tests/lint configs

Verification

• Re-run detection if you create or restructure significant files

• Run the repo's lint/test/build commands if available

Failure modes / debugging

• If detection is unclear, inspect:

• Root composer.json , package.json

• style.css , block.json , theme.json

• wp-content/ structure

• If repo is huge, narrow scanning scope

Escalation

If routing is ambiguous, ask:

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