majiayu000 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.jsonwp-content/structure
- Root
- 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?"