- name
- wordpress-router
- description
- Use at the start of WordPress tasks to classify the repo type (plugin, theme, block theme, WP core, full site) and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing).
- compatibility
- Targets WordPress 6.9+ (PHP 8.0+). Filesystem-based agent with bash + node.
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/null2) 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?"