lcrvl2 seo-weekly-recap : le récap hebdomadaire client
Une fois par semaine, raconter au client ce que le système a fait et où en est sa visibilité. C'est un document de NARRATION : ce skill ne calcule aucun chiffre, ne détecte rien, ne recommande pas d'optimisations. Il agrège ce que les autres skills ont déjà produit.
Règle universelle : aucune entreprise hardcodée. Client = tenant/slug, données dans seo/clients/<slug>/.
Division du travail : monitoring mesure (snapshot, rapport de perf), content-refresh analyse (queue), l'orchestrateur fait avancer les cartes. Le récap LIT ces trois-là plus le board, et synthétise. Si une donnée manque, il le dit ; il ne la recrée jamais.
Période couverte
Depuis le récap précédent : la date du dernier outputs/reports/recap-*.md existant. S'il n'y en a aucun (premier run) : les 7 derniers jours. Toujours annoncer la période en tête de récap.
Sources (lecture seule, dans cet ordre)
| Source | Ce qu'on en tire |
|---|---|
Kanban (tenant = slug) : kanban_list + fils de commentaires des cartes touchées dans la période |
Les actions : briefs déposés, validations client, révisions demandées, articles + QA déposés, publications, cartes bloquées pour le owner |
outputs/content/<dates de la période>/ |
La production : briefs et articles créés (chemins, mots-clés) |
outputs/monitoring/ : dernier rapport-*.md + dernier snapshot-*.json |
La performance, TELLE QUE monitoring l'a écrite (aucun recalcul). Snapshot simulated: true = ne JAMAIS citer ces chiffres. Pas d'export GSC = une ligne "suivi de performance en attente de connexion GSC" |
outputs/refresh/queue.json (+ scan-*.json de la période) |
Les contenus à rafraîchir détectés cette semaine (compte + top 3), sans relancer de scan |
Sans Kanban (harness sans les outils kanban_*) : reconstituer les actions depuis les dossiers outputs/ datés uniquement, et le dire ("actions reconstituées depuis les fichiers produits").
Structure du récap
Écrire outputs/reports/recap-YYYY-MM-DD.md, en français, dans la voix du système (sobre, chiffres et faits, pas d'adjectifs, phrases complètes). 5 sections :
- Fait cette semaine : ce qui a été produit et ce qui a avancé, en langage client ("le brief sur [mot-clé] a été rédigé et attend votre validation", "l'article [titre] a été validé et publié"). Chaque item avec son chemin ou son URL.
- En attente de votre validation : les cartes bloquées sections 2 et 3 du board, avec le geste attendu ("un clic pour valider, ou un commentaire pour demander une modification"). C'est la section qui fait agir le client.
- Performance : reprendre les points saillants du rapport monitoring (3-5 lignes max, pas un copier-coller). Si monitoring est en attente de GSC, une seule ligne le dit.
- Contenus à rafraîchir : le compte de la queue refresh + les 2-3 prioritaires, formulé comme un constat ("X contenus existants montrent des signes de déclin, les priorités sont...").
- La semaine prochaine : ce qui est en triage/todo sur le board et les jobs prévus.
Si une section est vide, une ligne honnête ("aucune publication cette semaine") plutôt que du remplissage.
Livraison
- Archiver le fichier dans
outputs/reports/. - Le déposer là où le client le lit : en commentaire de la carte dédiée "Récap" du board (la créer au premier run si absente, tag
recap, jamais une carte par semaine), ou sur le canal convenu.
Jamais
- Jamais recalculer un signal, un score ou une position : si monitoring ou refresh ne l'a pas produit, ça n'existe pas cette semaine.
- Jamais présenter des données simulées ou partielles comme des mesures réelles.
- Jamais de promesse de résultats futurs ni d'extrapolation de tendance.
- Jamais gonfler : un récap d'une semaine calme reste court.
Sur Hermes
C'est CE skill que le scheduled job hebdomadaire "Digest" exécute : "Run /seo weekly-recap " (vendredi en fin de journée, après les jobs monitoring et refresh de la semaine). Le worker a besoin du toolset kanban_* et du workdir contenant seo/clients/<slug>/.