Pipeline de blog posts avec des critiques IA en parallèle

Intention

Je voulais améliorer ma skill d’écriture de posts. Je me suis inspiré d’un article sur un content pipeline — il y utilise le format de “documentation de conversations”, où l’auteur montre non seulement le résultat, mais aussi le processus. Je ne voulais pas simplement le copier, je voulais créer un système modulaire :

• Pipeline de 5 phases avec orchestration d’agents
• Intégration d’Exa AI pour les recherches
• Deux formats d’article (standard et conversationnel)
• Possibilité de réutiliser la skill sur différents sites

L’idée principale : au lieu de passes d’édition séquentielles, lancer des agents spécialisés en parallèle. Comme le pattern fan-out/fan-in dans les systèmes distribués — je distribue le travail, je collecte les résultats.

Tentatives

Première itération : structure

J’ai commencé par créer une structure modulaire :

/Users/ilya/.claude/skills/blogpost-pipeline/
├── phases/
│   ├── 01-questions.md
│   ├── 02-research.md
│   ├── 03-draft.md
│   ├── 04-critics.md
│   └── 05-deploy.md
├── formats/
│   ├── standard.md
│   └── conversation.md
└── config/
    ├── sites.yaml
    └── eo-os.yaml

Chaque phase est un fichier séparé avec des instructions. Les formats décrivent la structure de l’article. Les configs contiennent les spécificités de chaque site.

Deuxième itération : 5 phases

J’ai défini le pipeline :

1. Questions — poser des questions à l’utilisateur sur le sujet, l’audience, le format et le site cible
2. Research — collecter du matériel via Exa AI (recherche sémantique) et la recherche web
3. Draft — écrire le brouillon dans le format choisi
4. Critics — lancer 4 critiques en parallèle, collecter le feedback, appliquer les corrections
5. Deploy — sauvegarder dans le bon répertoire, envoyer un aperçu par Telegram

La quatrième phase diffère des autres. Au lieu d’un éditeur — 4 agents spécialisés travaillent simultanément :

AI Slop Detector    ─┐
Rhythm Analyzer     ─┼─► Merge ─► Final edits
Specificity Checker ─┤
Fact Checker        ─┘

L’AI Slop Detector cherche les clichés (“dive into”, “it’s worth noting”). Le Rhythm Analyzer vérifie le flux et la variation de la longueur des phrases. Le Specificity Checker remplace les formulations vagues par des exemples concrets. Le Fact Checker exige des preuves pour les affirmations.

Tous les quatre regardent le même texte en parallèle. Ensuite je regroupe leur feedback et j’applique les corrections en une seule passe. Si deux critiques se contredisent — je tranche manuellement.

Troisième itération : configs des sites

J’ai créé des configs pour trois sites dans config/sites.yaml :

sites:
  igindin:
    path: apps/igindin-blog/drafts/
    telegram_channel: "@igindin_blog"

  t4s:
    path: apps/t4s-club/content/blog/
    telegram_channel: "@t4s_club"

  eo-os:
    path: apps/eo-os/content/articles/
    auto_publish: true

Une skill lit le config et sait où sauvegarder et comment notifier.

Rebondissements

Problème 1 : skills dupliquées

Quand j’ai lancé la nouvelle skill, deux commandes /blogpost sont apparues dans la liste :

• Ancienne skill (approche en 4 passes)
• Nouvelle skill (pipeline en 5 phases)

Confusion. J’ai supprimé l’ancienne :

rm -rf "/Users/ilya/[vibecoding]/.claude/skills/blogpost"

Problème 2 : content-factory était aussi un doublon

Il s’avérait que content-factory était une ancienne version d’une fonctionnalité similaire. Je l’ai supprimée également. Après ça, la liste des skills était propre.

Problème 3 : la skill ne posait pas de questions

La première version commençait à écrire immédiatement, sautant la phase de questions. L’article résultant était sans contexte — 2000 mots de phrases génériques du genre “l’IA est un outil puissant”.

J’ai ajouté au début du SKILL.md :

## CRITICAL: Start with Questions

**DO NOT start writing immediately.**

Before ANY writing, you MUST use AskUserQuestion to gather context:
1. Topic & angle
2. Audience
3. Format (standard/conversation)
4. Target site

Only after receiving answers → proceed to research and writing.

Maintenant la skill commence toujours par un dialogue. Les 2-3 premières minutes sont des questions, puis un résultat abouti dès la première tentative.

Résultat

Au final, j’ai obtenu un système fonctionnel :

• Pipeline de 5 phases — des questions jusqu’au déploiement
• Modularité — formats et configs sont réutilisés
• Symlinks — une skill dans ~/.claude/skills/blogpost-pipeline/, des symlinks dans chaque projet
• Propreté — aucun doublon
• Questions obligatoires — la skill n’écrit pas à l’aveugle

Je lance /blogpost, je réponds à 3-4 questions, j’obtiens l’article dans le bon format pour le bon site.

Conclusion

Les critiques parallèles, c’est du fan-out/fan-in pour le texte.

L’approche classique de l’édition est séquentielle : brouillon → structure → style → faits → polish final. Chaque passe attend la précédente.

Nouvelle approche : brouillon → [4 agents simultanés] → une correction unifiée. Plus rapide et plus rigoureux, parce que les agents ne s’influencent pas mutuellement et ne manquent pas les problèmes que “le précédent a déjà corrigés”.

Quand j’ai lancé les quatre critiques sur ce brouillon, ils ont trouvé :

• 7 endroits avec des mots de hedging (“peut-être”, “genre”)
• 3 listes monotones avec des points de longueur identique
• 5 affirmations abstraites sans exemples
• 2 imprécisions techniques

Manuellement, j’aurais passé 30-40 minutes sur 4 passes. Les agents parallèles l’ont fait en 2 minutes.

---

Cet article a été écrit par la skill qu’il décrit.