Routeur WordPress

Quand l'utiliser

Utilisez cette skill au début de la plupart des tâches WordPress pour :

identifier le type de codebase WordPress utilisée (plugin vs theme vs block theme vs checkout WP core vs full site),
choisir le workflow et les garde-fous appropriés,
déléguer aux skill(s) de domaine les plus pertinents.

Racine du repository (répertoire de travail actuel).
L'intention de l'utilisateur (ce qu'il souhaite modifier) et les contraintes éventuelles (versions WordPress ciblées, spécificités WP.com, exigences de release).

Exécutez le script de triage du projet :
- node skills/wp-project-triage/scripts/detect_wp_project.mjs
Lisez la sortie du triage et classifiez :
- type(s) principal(aux) du projet,
- outillage disponible (PHP/Composer, Node, @wordpress/scripts),
- tests présents (PHPUnit, Playwright, wp-env),
- tous les indices de version.
Routez vers les workflows de domaine en fonction de l'intention de l'utilisateur + type de repository :
- Pour l'arbre de décision, consultez : skills/wordpress-router/references/decision-tree.md.
Appliquez les garde-fous avant de faire des modifications :
- Confirmez les contraintes de version si c'est flou.
- Préférez l'outillage existant du repository et les conventions pour les builds/tests.

Réexécutez le script de triage si vous créez ou restructurez des fichiers importants.
Exécutez les commandes de lint/test/build du repository que la sortie du triage recommande (si disponibles).

Si le triage signale kind: unknown, inspectez :
- composer.json, package.json, style.css, block.json, theme.json, wp-content/ à la racine.
Si le repository est volumineux, envisagez de réduire la portée du scan ou d'ajouter des règles d'ignore au script de triage.

Si le routage est ambigu, posez une seule question :
- « Est-ce que cela est destiné à être un plugin WordPress, un theme (classique/block), ou un repository full site ? »