WordPress Router Skill | Agent Skills

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?"

Agent Skills: WordPress Router

Skill Files