Capstone : le skill /plan-week

On assemble tout

Tu as maintenant toutes les pièces : un skill de création (ch.3), une voix de marque (ch.4), un quality gate automatique (ch.5), et une publication parallèle (ch.6). Chaque brique a été construite et testée isolément — c'est ce qui rend l'assemblage serein. On les relie dans une seule commande qui planifie une semaine entière de contenu : /plan-week.

Mesure le chemin parcouru avec Léa : au chapitre 1, elle découvrait qu'un agent peut lire ses fichiers. Là, elle s'apprête à taper une phrase et obtenir sept jours de contenu multi-plateforme, dans sa voix, vérifié par son garde-fou, programmé aux bons créneaux. Ce n'est pas de la magie : c'est de la composition. Chaque chapitre était une fonction ; ce chapitre écrit le programme principal.

L'architecture avant le code

Avant de créer le skill, comprends son flux — parce que c'est toi qui devras le déboguer si quelque chose coince. La commande enchaîne cinq phases : recherche du sujet, génération d'un plan écrit dans un fichier, pause de validation humaine, exécution parallèle par subagents, et journalisation. La pause au milieu n'est pas une concession : c'est le point d'architecture le plus important du chapitre.

flowchart LR
  A["Sujet"] --> B["Recherche"]
  B --> C["content-plan.md"]
  C --> D{"Validation humaine"}
  D -->|"À corriger"| C
  D -->|"OK"| E["Subagents en parallèle"]
  E --> F["Posts programmés + journal"]

Remarque où est placée la validation : après la production du plan complet (le travail long et fastidieux est déjà fait), mais avant toute action irréversible (rien n'est encore publié ni programmé). C'est le placement optimal du contrôle humain : tu relis un document fini, confortablement, et ta décision porte sur du concret. Valider trop tôt (sur une intention vague) ne contrôle rien ; valider trop tard (après publication) ne sert plus à rien.

Créer le skill /plan-week

crée un skill "plan-week" qui :
- accepte un sujet, des brouillons, des URLs ou des images
- recherche le sujet et écrit un plan hebdo dans content-plan.md (jour, n° de post, sujet, texte complet, visuel oui/non)
- le texte doit être le post complet bien formaté, pas un résumé, adapté par plateforme
- crée le visuel une fois par jour (réutilisé par les posts du jour)
- me montre le plan et demande validation
- après validation, utilise des subagents parallèles pour programmer chaque post
- réutilise la voix, la config et le journal du skill /post

pose-moi des questions une à la fois jusqu'à 95% de confiance.

Deux lignes de ce prompt méritent ton attention. « Le texte doit être le post complet, pas un résumé » : sans cette précision, tu obtiendrais un plan de sujets — joli mais inutilisable, car tu devrais encore tout rédiger. « Réutilise la voix, la config et le journal du skill /post » : c'est la composition en action. Le nouveau skill ne réinvente rien, il s'appuie sur les briques existantes — d'où l'intérêt d'avoir centralisé la voix dans brand-voice.md au chapitre 4.

Le fichier comme interface de travail

Claude recherche le sujet, génère content-plan.md et demande ton accord. Ce choix — un fichier plutôt qu'un long message dans la conversation — est une pratique à retenir pour tous tes futurs systèmes. Un fichier se relit tranquillement, s'édite directement, se versionne dans Git, et survit à la conversation.

# Plan de contenu — semaine du 17 juin

## Lundi — Post 1 (LinkedIn)
Sujet : pourquoi le « sans parfum » est un faux ami
Visuel : oui (infographie ingrédients)
Texte :
> On croit bien faire en choisissant « sans parfum »...
> [post complet, prêt à publier]

## Lundi — Post 2 (Twitter)
...

Tu relis ; si un brouillon ne va pas, tu édites directement le fichier — pas besoin de décrire la modification à Claude, tu corriges le texte toi-même comme dans n'importe quel document — puis tu dis « continue ». Claude reprend le fichier dans son état actuel et lance un subagent par post, en parallèle. Le fichier est l'interface ; la conversation n'est que le déclencheur.

Quand ça dérape : déboguer une orchestration

Avec un système qui enchaîne cinq phases, il faut savoir localiser une panne. La méthode est toujours la même : identifier la phase qui a produit le problème, et la corriger isolément. Le plan est hors-sujet ? C'est la phase de recherche — précise le brief ou les sources dans le skill. Les textes sont bons mais le ton dérive ? C'est brand-voice.md qu'il faut enrichir (chapitre 4). Un post est bloqué à la programmation ? Lis le message du quality gate (chapitre 5). Un seul réseau échoue ? C'est le subagent ou l'API de cette plateforme (chapitre 6).

Tu remarques le réflexe : chaque brique du cours est aussi une zone de diagnostic. C'est l'avantage décisif d'avoir construit le système pièce par pièce plutôt que d'un bloc — tu sais où regarder, et tu peux tester chaque pièce séparément avec les commandes des chapitres précédents.

Le pattern à retenir : améliore l'outil, pas la sortie

Tu restes aux commandes : tu valides le plan avant toute exécution. L'IA et l'automatisation gèrent le travail répétitif. Et quand l'écart entre ce que tu voulais et ce que Claude a produit est grand, ne te contente pas de corriger le fichier : dis-le-lui — et demande-lui de mettre à jour le skill pour que la prochaine fois soit meilleure.

Concrètement, après chaque exécution de /plan-week, pose-toi la question : « qu'ai-je corrigé à la main dans le plan ? » Chaque correction manuelle récurrente est une règle qui manque au skill. Trois semaines de ce réflexe et tes corrections manuelles tendent vers zéro — c'est mesurable, et c'est le critère objectif d'un système mûr.

Ce que ce capstone t'a vraiment appris

Au-delà du marketing de Léa, tu viens d'exécuter un schéma universel d'automatisation : décomposer un processus métier en étapes, encoder chaque étape (skill), sécuriser le non-négociable (hook), paralléliser l'indépendant (subagents), et placer la validation humaine au point de levier maximal. Remplace « posts » par « factures à relancer », « tickets de support à trier » ou « veille concurrentielle à résumer » : le schéma tient tel quel.

Il reste une fragilité : tout ce savoir vit dans des fichiers, mais Claude repart de zéro à chaque session et doit les redécouvrir. Le dernier chapitre règle ça — et c'est lui qui transforme une belle démo en système durable.