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