Comment construire une Claude skill pour rédiger des articles SEO

Pourquoi un agent unique ne suffit plus

Un seul prompt ne peut pas tenir simultanément l'angle, la structure, la longueur, le maillage et la voix de marque. Vous l'avez observé. Le modèle ouvre fort, puis dérive sur la longueur, et oublie le tutoiement décidé en début de session. Il recopie un lien interne déjà placé, et termine par la formule de clôture que vous aviez explicitement bannie. Ce n'est pas un défaut d'intelligence, c'est un défaut d'attention partagée. Plus la liste de contraintes s'allonge, plus la probabilité d'en sacrifier une augmente à chaque génération.

Le second symptôme est plus pernicieux : le modèle s'auto-félicite. Demandez-lui de vérifier ses propres règles, il vous renverra un audit positif sur 90 % du texte, exactement aux endroits où une regex aurait trouvé l'erreur. Vous payez alors deux fois : la dérive éditoriale, puis la fausse confirmation qu'elle n'a pas eu lieu.

Une skill bien conçue accepte cette limite et la traite comme une donnée d'architecture, pas comme un problème de prompt à rallonge. Elle pose des garde-fous, isole les contextes, et confie chaque contrainte mesurable à un agent dédié.

Une skill Claude Code, concrètement

Une Claude skill, c'est un dossier que l'agent charge automatiquement quand votre prompt correspond à un de ses triggers. Concrètement, vous créez ~/.claude/skills/writers-room/, vous y déposez un fichier SKILL.md avec un en-tête YAML, et la skill devient active. Elle reste en place à chaque nouvelle session, sans avoir à recoller votre prompt fétiche.

Ce dossier accueille bien plus qu'un fichier de prompt. Il regroupe la déclaration des sous-agents, une configuration externalisée en YAML, des scripts Python qui mesurent les contraintes, des templates de rendu HTML. Une skill sérieuse y ajoute un journal des retours utilisateur, un fichier de feedback que le rédacteur en chef consulte à chaque nouvelle génération.

L'intérêt pour la production d'articles SEO se résume en trois points. Votre charte éditoriale ne s'évapore plus entre deux sessions, elle est codée. Un consultant non-développeur peut ajuster la voix dans le YAML sans toucher à l'orchestration. Et les règles d'un client se promeuvent en règles d'agence, ou se spécialisent par site avec un simple config.yml dédié.

À quoi ressemble un fichier SKILL.md

Concrètement, voici la déclaration minimale d'une skill. Le frontmatter YAML décrit quand elle se déclenche, le corps Markdown décrit ce qu'elle fait. C'est tout - pas de configuration cachée, pas de DSL propriétaire.

---
name: writers-room
description: Produce a publication-ready article through a multi-agent
  editorial workshop. Triggers : "write a complete article",
  "rédige un article complet", "writers room".
---

# Writers Room

Un rédacteur en chef coordonne treize sous-agents (recherche, plan,
rédaction, style, maillage, cohérence...) et un vérificateur Python
qui contrôle liens, longueur des paragraphes, phrases bannies.

Pipeline :
1. Recherche → 2. Plan → 3. Premier jet
4. Style + Lisibilité + Sémantique (en parallèle)
5. Maillage interne + externe
6. Vérification programmatique → boucle correctrice
7. Rendu HTML avec ouverture automatique du navigateur

Le moteur lit la description à chaque démarrage de session, la confronte au prompt utilisateur, et n'active la skill que si le contexte correspond. Cette ségrégation par déclaration explicite, plutôt que par mot-clé caché dans un méga-prompt système, est ce qui rend l'écosystème skills à la fois discrétionnaire et auditable.

Pas réservée à Claude Code : Codex et Gemini lisent le même format

Le format SKILL.md est devenu un standard partagé. Codex CLI découvre les skills dans ~/.agents/skills//, Gemini CLI dans ~/.gemini/skills//, et Claude Code dans ~/.claude/skills//. Le frontmatter YAML name + description est identique dans les trois cas, la détection par triggers fonctionne pareil, et le corps Markdown se lit de la même façon.

En pratique, vous clonez le repo une fois et vous le liez par symlink dans les trois dossiers. La même skill devient utilisable depuis votre client préféré sans dupliquer les fichiers ni maintenir trois versions. Quelques détails d'orchestration (la syntaxe précise d'invocation des sous-agents, les noms de tools propres à chaque CLI) peuvent demander de légères adaptations, mais la déclaration des rôles, les triggers et la structure éditoriale traversent les écosystèmes sans accroc.

La rédaction est un atelier, pas un monologue

Pensez la rédaction comme une chaîne éditoriale, avec des rôles séparés et un rédacteur en chef qui orchestre. C'est le modèle que les rédactions humaines utilisent depuis cent ans, et que Karpathy a remis au goût du jour côté LLM avec son LLM Council. Sur une skill, cela donne une demi-douzaine de sous-agents. Un planificateur d'angle, un chercheur qui vérifie les sources, un rédacteur, un relecteur de cohérence narrative, un poseur de liens internes, un vérificateur de contraintes dures.

Chaque sous-agent reçoit un brief court, un objectif unique, et une liste fermée de tools. Le planificateur travaille sur le brief éditorial SEO avant que la moindre phrase ne soit écrite. Le poseur de liens internes ne voit que la liste des URL candidates et les ancres déjà utilisées, pas le brief stratégique. Cette ségrégation des contextes évite la confusion classique du modèle qui mélange "pourquoi écrire l'article" et "comment poser une ancre dans le paragraphe 4".

L'orchestration se branche sur le mécanisme de subagent de Claude Code. La documentation Anthropic décrit le champ context: fork et un agent dédié par tâche. Vous gardez la conversation principale propre, et chaque sous-agent travaille en contexte isolé avec ses outils.

Les briques techniques d'une skill qui tient la route

Une skill éditoriale solide repose sur quatre briques distinctes, et il faut résister à la tentation de les fusionner. La première est le SKILL.md : un fichier court, déclaratif, qui décrit quand la skill doit se déclencher et quels rôles elle coordonne. La seconde est l'ensemble des prompts par rôle, externalisés dans des fichiers séparés que le rédacteur en chef charge à la demande.

La troisième brique est la configuration externe : voix de marque, règles dures, banque d'URL internes, glossaire interdit, plafond de mots. Vous la stockez dans un YAML que la skill lit à chaque exécution. Cela permet à un consultant non-développeur d'ajuster le ton sans toucher au code, exactement comme un guide de style éditorial vit séparément des articles. C'est aussi ce qui rend la skill réutilisable d'un client à l'autre.

La quatrième brique, la plus négligée, est le vérificateur programmatique. Un script Python qui compte les liens internes, mesure les paragraphes, traque les phrases bannies, valide la longueur des titres, et refuse les tirets cadratins en plein corps. Sa logique reste triviale, son existence est non négociable. Pour les sources externes, je recommande la grille E-E-A-T de Google sur la qualité éditoriale. Une skill produit le squelette, et elle doit forcer la traçabilité jusqu'à la source primaire.

Le piège : laisser le modèle s'auto-déclarer "ok"

La règle d'or, c'est qu'un modèle ne valide jamais lui-même son output sur des contraintes mesurables. Cette ligne devrait être affichée au mur de toute équipe qui industrialise la rédaction par LLM. Tout ce qui est comptable, mesurable, ou vérifiable par regex doit passer par un script déterministe avant publication. Vous laissez au modèle ce qu'il sait faire. Juger l'angle, reformuler une transition lourde, choisir un exemple. Et vous lui retirez ce qu'il ne sait pas faire de manière fiable. Compter, mesurer, garantir l'absence d'un motif.

En pratique, le rédacteur en chef tourne en boucle : génération, vérification programmatique, retour des erreurs au sous-agent compétent, nouvelle génération ciblée. Ce loop, limité à trois ou quatre passes, élimine 80 % des dérives qui survivaient dans une approche prompt-unique. Le coût en tokens est réel, mais reste largement inférieur au coût d'une relecture humaine sur un texte qui n'aurait pas dû arriver dans votre boîte mail.

Doublez ce vérificateur d'un rendu HTML local automatique. Le relecteur humain lit alors l'article tel qu'il sortira en ligne, avec le maillage et la mise en forme, pas en markdown brut. Cette habitude réduit de moitié les itérations finales. Elle rejoint la logique d'optimisation sémantique SEO. Un contenu se juge en contexte de publication, pas en isolation.

Le feedback comme moteur d'amélioration

Une skill qui n'apprend pas de votre retour livre toujours le même article, même quand vous lui avez déjà dit ce qui ne va pas. C'est le défaut le plus rapide à constater. Trois articles de suite ouvrent par la même formule, trois articles de suite que vous reformulez à la main. Une skill éditoriale digne de ce nom doit absorber ce feedback comme donnée d'entrée du run suivant.

L'architecture la plus simple repose sur deux fichiers, et pas un seul. Le config.yml accueille les règles dures et stables : voix, plafonds, vocabulaire banni, plage de liens. Le feedback.md accueille les retours datés en langue naturelle. Vous y notez par exemple qu'un mot revient trop souvent, ou qu'un ton vous semble trop académique pour ce sujet. Le rédacteur en chef lit feedback.md au démarrage de chaque run, et y annexe le retour utilisateur à la livraison.

La distillation est l'étape qui transforme l'accumulation en règle. Quand un même retour revient trois fois, vous le promouvez : "concrètement" bascule dans banned_phrases du config.yml. C'est un acte délibéré, pas automatique, parce qu'une promotion mal choisie casse votre voix de marque. Cette logique rejoint celle qu'on applique pour influencer les réponses des LLM. Un retour clair, daté et tracé bat toujours un prompt plus long.

Ce qu'il vous reste à arbitrer

Aucune skill ne supprime le jugement humain sur l'angle, la voix de marque, ou la sélection des sources primaires. Elle l'encadre, elle le rend reproductible, elle interdit les fautes grossières. Mais le choix de l'angle reste un acte éditorial. Décider que cet article-ci attaque le sujet par le coût caché de l'orchestration plutôt que par la promesse de rapidité, c'est une décision que le consultant prend. Pas le modèle.

Idem pour la voix. Une skill impose le vouvoiement et bannit les tirets cadratins. Elle ne sait pas que votre marque préfère "consultant augmenté" à "expert IA" parce que ce terme vous suit depuis trois ans. Cette mémoire-là vit dans la configuration que vous nourrissez, pas dans le modèle. La même logique guide une bonne stratégie de maillage interne. Les règles automatisables sont déléguées, les choix de hub stratégiques restent humains.

Reste enfin la question des sources. Un sous-agent trouve une URL plausible et la formate proprement. Seul l'humain valide qu'elle pointe vers une source primaire récente, dans la bonne juridiction, avec le bon angle. Ce dernier kilomètre sépare un contenu publiable d'un brouillon convaincant. Il restera votre responsabilité encore longtemps.

La bonne nouvelle, c'est que ce travail d'arbitrage devient enfin lisible. Vous voyez où le modèle a été contraint, où il a eu de la latitude, et où votre voix décide. Une skill éditoriale ne remplace pas le rédacteur en chef, elle lui rend ses heures de relecture pour qu'il les investisse dans ce qui mérite vraiment du jugement humain. C'est un changement d'allocation, pas une délégation aveugle.

Passons à la pratique

• Cartographiez vos rôles éditoriaux réels avant d'écrire le moindre prompt. Ce découpage détermine la qualité finale, pas le modèle choisi.
• Externalisez la configuration dans un fichier que vos consultants peuvent éditer sans ouvrir le code. Versionnez-le comme un asset de marque, au même titre qu'un guide de style.
• Écrivez le vérificateur programmatique avant le rédacteur en chef. Si vous ne savez pas mesurer la qualité, vous ne saurez pas la produire de manière reproductible.
• Tenez un fichier de feedback daté en parallèle, et promouvez en règles dures les retours qui reviennent trois fois.
• Plafonnez le loop de correction à trois ou quatre passes. Au-delà, le coût en tokens dépasse celui d'une relecture humaine sur un texte propre.