Créer un super agent WordPress avec Codex, VS Code, WP-CLI, SSH et les skills officiels de WordPress.org

À retenir

WP-CLI

SSH

WordPress Agent Skills

Expérience WordPress & IA

Créer un super agent WordPress avec Codex, VS Code, WP-CLI, SSH et les skills officiels WordPress.org

Une méthode concrète pour transformer un assistant IA en orchestrateur WordPress capable d’auditer des plugins, de diagnostiquer des sites, de travailler avec WP-CLI, de se connecter en SSH et de garder une mémoire projet structurée.

Introduction

Passer d’un simple chatbot à un orchestrateur WordPress

Depuis quelque temps, je cherchais une manière plus fiable de travailler avec l’intelligence artificielle sur mes projets WordPress. Pas seulement demander à une IA de corriger un bout de code, mais créer un véritable orchestrateur capable de comprendre mes projets, d’analyser mes plugins, de vérifier mes sites, d’utiliser WP-CLI, de se connecter à un serveur en SSH, de garder une mémoire de travail et surtout de respecter les bonnes pratiques WordPress.

L’idée de départ était simple : faire de Codex, connecté à Visual Studio Code, un poste de pilotage WordPress. Le résultat est devenu beaucoup plus intéressant que prévu : un agent structuré, documenté, capable de travailler en local et à distance, tout en restant cadré par des règles de sécurité strictes.

La base de cette expérience repose sur les Agent Skills officiels de WordPress.org, disponibles sur GitHub : https://github.com/WordPress/agent-skills.

Idée centrale :

un agent IA devient vraiment utile quand il combine contexte projet, règles persistantes, skills spécialisés, WP-CLI, SSH et mémoire technique.

Pourquoi

Pourquoi créer un agent WordPress dédié ?

Les assistants IA peuvent générer du code. Mais WordPress demande plus que du code : il demande des règles, des conventions, des vérifications et une logique de publication.

01

Éviter l’improvisation

WordPress a ses propres standards : sécurité, internationalisation, Gutenberg, Plugin Check, fichiers build, readme.txt et compatibilité WordPress.org.

02

Auditer avant d’agir

L’agent doit d’abord inspecter, comprendre, lister les risques et proposer un plan avant de modifier un plugin, un thème ou un site distant.

03

Garder une mémoire

Les décisions, audits, sites détectés, commandes utilisées et actions restantes sont enregistrés dans une mémoire projet, sans secrets ni mots de passe.

WordPress.org

Les skills officiels WordPress comme socle de travail

Les skills WordPress ne sont pas des agents autonomes. Ce sont des paquets d’instructions, checklists et scripts que l’agent peut charger selon la tâche.

Skills utilisés dans l’orchestrateur

• wp-plugin-development
• wp-block-development
• wp-plugin-directory-guidelines
• wp-wpcli-and-ops
• wp-performance
• wp-phpstan
• wp-block-themes
• wp-project-triage

Ce qu’ils apportent

• Meilleur cadrage des audits WordPress
• Rappels sur escaping, sanitization et i18n
• Contrôles Gutenberg et block.json
• Préparation WordPress.org
• Diagnostic WP-CLI local et distant
• Maintenance plus prudente

Dépôt officiel

https://github.com/WordPress/agent-skills

Méthode

La méthode utilisée : Codex, VS Code, WP-CLI, SSH et mémoire

Installer Codex dans Visual Studio Code

VS Code devient le poste de pilotage. Codex lit les fichiers, utilise le terminal, applique les règles du workspace et travaille dans le contexte du projet.

Installer les skills WordPress

Les skills officiels WordPress sont installés dans le workspace de l’agent, par exemple dans .codex/skills/.

Créer un fichier AGENTS.md

Ce fichier définit les règles permanentes : audit avant modification, sécurité SSH, WP-CLI, mémoire, routage des skills et interdiction des actions destructives sans validation.

Configurer WP-CLI local et distant

WP-CLI devient l’outil principal pour vérifier les installations WordPress, lister plugins et thèmes, contrôler les versions et lancer Plugin Check.

Valider la connexion SSH

L’agent peut diagnostiquer un serveur via SSH, mais uniquement avec des commandes non destructives et sans jamais lire ou stocker les clés privées.

Subtilité importante

Ce workflow n’est pas limité à Codex

Dans mon cas, j’ai utilisé Codex connecté à Visual Studio Code, mais le principe n’est pas limité à Codex.

La même logique peut être adaptée à d’autres agents compatibles avec Visual Studio Code, comme Claude Code. Dans ce cas, l’idée reste la même : un agent connecté à l’éditeur, capable de lire le projet, d’utiliser le terminal, de travailler avec WP-CLI, d’exécuter des diagnostics SSH et de s’appuyer sur les skills WordPress.

L’orchestrateur n’est donc pas seulement un –all-tables-with-prefix –precise –report-changed-onlyagent Codex –all-tables-with-prefix –precise –report-changed-only. C’est surtout une méthode de travail : structurer un environnement WordPress avec des règles, une mémoire, des scripts, des prompts, des templates et les skills officiels WordPress.org.

Équivalence de structure

Codex :
AGENTS.md
.codex/skills/

Claude Code :
CLAUDE.md
.claude/skills/

Codex est l'outil utilisé pour cette expérience, mais le principe peut être reproduit avec d'autres agents capables de travailler dans VS Code et de respecter une configuration projet.

Architecture

La structure du workspace de l’agent

Structure type

WordPress-Agent/
│
├── AGENTS.md
│
├── memory/
│ ├── sites-registry.md
│ ├── known-environment.md
│ ├── audit-history.md
│ └── decisions.md
│
├── prompts/
│ ├── audit-plugin.md
│ ├── prepare-wordpress-org-release.md
│ ├── fix-gutenberg-block.md
│ ├── fix-elementor-preview.md
│ ├── create-theme-child.md
│ └── deploy-via-ssh.md
│
├── templates/
│ ├── plugin-audit-report.md
│ ├── release-checklist.md
│ ├── changelog-entry.md
│ └── client-message.md
│
├── docs/
│ ├── architecture.md
│ ├── workflow.md
│ ├── ssh-rules.md
│ ├── wordpress-org-rules.md
│ └── local-environment.md
│
├── scripts/
│ ├── discover-local-wp-sites.ps1
│ ├── audit-wp-site.ps1
│ └── ssh-config-audit.ps1
│
└── .codex/
 └── skills/

memory/

Registre des sites, décisions, audits, environnement local et actions restantes.

prompts/

Prompts réutilisables pour audits, corrections, releases, thèmes et SSH.

scripts/

Scripts de découverte locale, audit de sites et analyse de configuration SSH.

WP-CLI

WP-CLI : le levier indispensable

Avec WP-CLI, l’agent ne se contente pas de regarder les fichiers. Il peut interroger WordPress correctement, localement ou sur serveur.

Commandes locales utiles

• wp –info
• wp core version –path=<site-path>
• wp plugin list –path=<site-path>
• wp theme list –path=<site-path>
• wp option get siteurl –path=<site-path>
• wp plugin check <plugin-slug> –path=<site-path>

Ce que cela permet

• Vérifier les versions WordPress
• Lister plugins et thèmes
• Identifier le thème actif
• Préparer une release WordPress.org
• Lancer Plugin Check
• Auditer sans ouvrir l’administration

SSH

Connecter l’agent au serveur, sans perdre le contrôle

L’agent peut utiliser SSH pour diagnostiquer un serveur distant, mais toujours avec une règle stricte : lecture d’abord, modification seulement après validation.

Diagnostic distant

Commandes SSH sûres

ssh <alias> "echo SSH_OK && hostname && pwd"
ssh <alias> "php -v"
ssh <alias> "wp --info"
ssh <alias> "cd /path/to/site && wp plugin list"

Règles de sécurité

• Ne jamais lire les clés privées
• Ne jamais stocker la passphrase
• Ne jamais modifier SSH sans instruction
• Ne jamais lancer de commande destructive sans validation
• Documenter chaque connexion validée

La connexion SSH permet aussi de détecter automatiquement les installations WordPress sur un serveur, puis de les inscrire dans la mémoire de l'agent.

Cas pratiques

Ce que l’orchestrateur peut faire maintenant

A

Auditer un plugin

Vérifier sécurité, i18n, Gutenberg, Elementor, fichiers build, readme.txt, Plugin Check et compatibilité WordPress.org.

B

Préparer une release

Contrôler version, stable tag, ZIP propre, absence de fichiers inutiles, build compilé et conformité aux guidelines du répertoire.

C

Créer un thème enfant

Partir de Twenty Twenty-Four, conserver sa robustesse FSE et appliquer une identité visuelle Glassmorphism personnalisée.

D

Inventorier un serveur

Détecter toutes les installations WordPress distantes, récupérer siteurl, home, version, thème actif et plugins actifs.

E

Diagnostiquer un site

Contrôler PHP, WP-CLI, plugins, thèmes, versions, erreurs probables et état général sans modifier la production.

F

Nettoyer prudemment

Analyser les bases de données, options autoloadées, transients et tables suspectes, mais uniquement avec sauvegarde et validation.

Exemple concret

Créer un thème enfant FSE inspiré d’un thème existant

Une expérience intéressante a été de demander à l’agent de créer un thème enfant Full Site Editing basé sur Twenty Twenty-Four. L’idée n’était pas de créer un thème vide, mais de conserver la robustesse du thème parent et de transformer son apparence.

L’agent peut inspecter un thème existant, récupérer les couleurs, analyser le CSS personnalisé, repérer les template parts utiles comme le header, le header top et le footer, puis créer un nouveau thème enfant qui hérite du parent.

Mission type

Créer un thème enfant FSE de Twenty Twenty-Four.
Inspecter le thème existant.
Récupérer couleurs, CSS utile, header, header-top et footer.
Créer un style SaaS Glassmorphism.
Ne pas modifier le thème parent.
Ne pas activer sans confirmation.

AGENTS.md

Version anonymisée du fichier de cadrage

Cette version est publiable : aucun chemin personnel, aucun serveur réel, aucune clé, aucune passphrase.

AGENTS.md — version anonymisée

# WordPress Orchestrator Agent

You are a WordPress orchestration agent.

Your role is to help inspect, audit, maintain and prepare WordPress projects using official WordPress best practices, WP-CLI, SSH diagnostics and WordPress Agent Skills.

## Core principles

- Do not assume a single WordPress site.
- Always identify the target project before acting.
- Prefer inspection and reporting before modification.
- Never run destructive commands without explicit confirmation.
- Never read, display or store secrets.
- Never store SSH passphrases, API keys, passwords or private key contents.
- Use WordPress standards for security, escaping, sanitization, i18n and release preparation.

## Workspace structure

Use these folders:

- memory/ for persistent project memory.
- prompts/ for reusable task prompts.
- templates/ for reusable reports and messages.
- docs/ for architecture and workflows.
- scripts/ for local diagnostic scripts.
- .codex/skills/ for installed WordPress Agent Skills.

## Persistent memory

Maintain these files:

- memory/sites-registry.md
- memory/known-environment.md
- memory/audit-history.md
- memory/decisions.md

Rules:

- Create the files if they do not exist.
- Append new dated entries.
- Do not overwrite previous history.
- Do not store credentials, secrets, passphrases or private key contents.

## WP-CLI

WP-CLI is the preferred tool for WordPress diagnostics.

Allowed diagnostic examples:

wp --info
wp core version --path=<site-path>
wp plugin list --path=<site-path>
wp theme list --path=<site-path>
wp option get siteurl --path=<site-path>
wp option get home --path=<site-path>
wp plugin check <plugin-slug> --path=<site-path>

Do not run update, delete, reset, search-replace or database modification commands without explicit confirmation.

## WordPress skill routing

Use the relevant WordPress Agent Skills depending on the task.

- wp-plugin-development
- wp-block-development
- wp-plugin-directory-guidelines
- wp-wpcli-and-ops
- wp-performance
- wp-phpstan
- wp-block-themes
- wp-project-triage

## SSH rules

SSH may be used only through existing local SSH aliases.

Allowed:

- Read SSH alias names.
- Read Host, HostName, User, Port and IdentityFile paths.
- Use SSH for non-destructive diagnostics.
- Use WP-CLI remotely when available.

Forbidden:

- Never read private key contents.
- Never display private keys.
- Never store passphrases.
- Never modify SSH config without explicit instruction.
- Never run destructive remote commands without explicit confirmation.

Allowed diagnostic examples:

ssh <alias> "echo SSH_OK && hostname && pwd"
ssh <alias> "php -v"
ssh <alias> "wp --info"
ssh <alias> "cd /path/to/site && wp core version"
ssh <alias> "cd /path/to/site && wp plugin list"
ssh <alias> "cd /path/to/site && wp theme list"

Forbidden remote commands without explicit confirmation:

rm
mv
chmod
chown
git pull
wp core update
wp plugin update
wp theme update
wp search-replace
wp db reset
mysql
rsync
scp

## Task workflow

Before editing:

1. Identify the target project.
2. Identify the task type.
3. Select the relevant WordPress skills.
4. Inspect the project.
5. Produce a short plan.
6. Make only the minimum necessary changes.

After work:

1. Summarize files changed.
2. Summarize commands executed.
3. Summarize tests performed.
4. Mention remaining risks.
5. Update memory/audit-history.md.

## Safety rule

The agent must prefer a safe audit over an unsafe action.

When unsure, it must stop and report instead of modifying production.

Sécurité

Le point central : un agent capable de s’arrêter

Un bon agent n'est pas seulement un agent capable d'agir. C'est un agent capable de savoir quand il ne doit pas agir.

Actions interdites sans validation

• Suppression de fichiers
• Déplacement de fichiers serveur
• Modification de configuration SSH
• Mises à jour WordPress en production
• Search-replace en base de données
• Commandes SQL destructives

Règles permanentes

• Audit avant correction
• Rapport avant modification
• Sauvegarde avant action sensible
• Pas de secret dans la mémoire
• Pas de clé privée lue
• Validation explicite avant déploiement

Conclusion

L’IA devient utile quand elle est outillée, cadrée et connectée

Cette expérience a transformé Codex dans VS Code en véritable orchestrateur WordPress : capable d’auditer des plugins, de préparer des releases WordPress.org, de contrôler des sites avec WP-CLI, de se connecter en SSH, de créer des thèmes enfants et de garder une mémoire technique.

Ce système n’est pas attaché à un seul modèle ou à un seul fournisseur : Codex a été utilisé ici, mais le même principe peut être adapté à Claude Code ou à d’autres agents compatibles avec VS Code et les skills WordPress.

L’objectif n’est pas de remplacer le développeur. L’objectif est de construire un assistant qui connaît l’environnement, respecte WordPress, documente son travail et permet d’aller plus vite sans perdre le contrôle.