Wordpress Router

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).
• The user’s intent (what they want changed) and any constraints (WP version targets, WP.com specifics, release requirements).

Procedure

1. Run the project triage script:

• node skills/wp-project-triage/scripts/detect_wp_project.mjs

2. Read the triage output and classify:

• primary project kind(s),
• tooling available (PHP/Composer, Node, @wordpress/scripts),
• tests present (PHPUnit, Playwright, wp-env),
• any version hints.

3. Route to domain workflows based on user intent + repo kind:

• For the decision tree, read: skills/wordpress-router/references/decision-tree.md.

4. Apply guardrails before making changes:

• Confirm any version constraints if unclear.
• Prefer the repo’s existing tooling and conventions for builds/tests.

Verification

• Re-run the triage script if you create or restructure significant files.
• Run the repo’s lint/test/build commands that the triage output recommends (if available).

Failure modes / debugging

• If triage reports kind: unknown, inspect:
• root composer.json, package.json, style.css, block.json, theme.json, wp-content/.
• If the repo is huge, consider narrowing scanning scope or adding ignore rules to the triage script.

Escalation

• If routing is ambiguous, ask one question:
• “Is this intended to be a WordPress plugin, a theme (classic/block), or a full site repo?”

Router decision tree (v1)

This is a lightweight routing guide. It assumes you can run wp-project-triage first.

Step 1: classify repo kind (from triage)

Use triage.project.kind and the strongest signals:

• wp-core → treat as WordPress core checkout work (core patches, PHPUnit, build tools).
• wp-site → treat as a full site repo (wp-content present; changes might be theme + plugins).
• wp-block-theme → theme.json/templates/patterns workflows.
• wp-theme → classic theme workflows (templates PHP, functions.php, style.css).
• wp-block-plugin → Gutenberg block development in a plugin (block.json, build pipeline).
• wp-plugin / wp-mu-plugin → plugin workflows (hooks, admin, settings, cron, REST, security).
• gutenberg → Gutenberg monorepo workflows (packages, tooling, docs).

If multiple kinds match, prefer the most specific: gutenberg > wp-core > wp-site > wp-block-theme > wp-block-plugin > wp-theme > wp-plugin.

Step 2: route by user intent (keywords)

Route by intent even if repo kind is broad (like wp-site):

• *Interactivity API / data-wp- directives / @wordpress/interactivity / viewScriptModule**
• Route → wp-interactivity-api.
• Abilities API / wp_register_ability / wp-abilities/v1 / @wordpress/abilities
• Route → wp-abilities-api.
• Playground / run-blueprint / build-snapshot / @wp-playground/cli / playground.wordpress.net
• Route → wp-playground.
• Blocks / block.json / registerBlockType / attributes / save serialization
• Route → wp-block-development.
• *theme.json / Global Styles / templates/.html / patterns/**
• Route → wp-block-themes.
• Plugins / hooks / activation hook / uninstall / Settings API / admin pages
• Route → wp-plugin-development.
• REST endpoint / register_rest_route / permission_callback
• Route → wp-rest-api.
• WP-CLI / wp-cli.yml / commands
• Route → wp-wpcli-and-ops.
• Build tooling / @wordpress/scripts / webpack / Vite / npm scripts
• Route → wp-build-tooling (planned).
• Testing / PHPUnit / wp-env / Playwright
• Route → wp-testing (planned).
• PHPStan / static analysis / phpstan.neon / phpstan-baseline.neon
• Route → wp-phpstan.
• Performance / caching / query profiling / editor slowness
• Route → wp-performance.
• Security / nonces / capabilities / sanitization/escaping / uploads
• Route → wp-security (planned).

Step 3: guardrails checklist (always)

• Verify detected tooling before suggesting commands (Composer vs npm/yarn/pnpm).
• Prefer existing lint/test scripts if present.
• If version constraints aren’t detectable, ask for target WP core and PHP versions.