faloppad/examen-calendrier-social

Révision du calendrier social

Un contrôle hebdomadaire qui boucle la boucle. Il examine les 7 jours passés et les 14 jours à venir, puis rédige un court rapport et propose des modifications aux fichiers Markdown qui pilotent la compétence social-calendar.

Cette compétence lit Airtable et n'y écrit jamais. Elle modifie les fichiers de stratégie et de chaîne uniquement après que l'utilisateur a approuvé le changement, sauf si l'invite de routine indique le contraire.

Configuration

• AIRTABLE_TOKEN et AIRTABLE_BASE_ID, dans l'environnement ou un fichier .env dans le répertoire de travail ou la racine du dépôt.
• STRATEGY_DIR pointant vers le dossier contenant strategy.md et channels/. S'il n'est pas défini, cherchez strategy.md dans le répertoire de travail, ./my-strategy/ et ./strategy/.
• Le script de calendrier de la compétence principale : skills/social-calendar/scripts/airtable_calendar.py (ci-dessous, $CAL). Le connecteur MCP Airtable fonctionne aussi s'il est connecté.

Étapes

1. Charger les règles

Lisez strategy.md et tous les fichiers channels/*.md pour les chaînes actives (python3 $CAL channels). Notez pour chaque chaîne : la cadence cible, les types de publication autorisés, les règles de voix, les mots ou sujets interdits, les règles de hashtags et le propriétaire. Notez les OKR actuels et les piliers de contenu de la stratégie.

Si la révision de la semaine dernière existe dans $STRATEGY_DIR/reviews/, lisez-la et vérifiez si ses propositions acceptées ont été appliquées.

2. Regarder les 7 derniers jours

python3 $CAL list --from -7 --to today --json > /tmp/review-past.json

À partir de cette liste, examinez :

• Les publications Live. Ce sont le sujet principal.
• Les publications Failed et Manual. Les échecs ont-ils été corrigés ? Quelqu'un a-t-il vraiment publié les publications manuelles ?
• Les publications To approve, Needs media et Approved avec une date dans le passé. Ce sont des approbations manquées ou un éditeur qui n'a pas fonctionné.

Vérifiez chaque publication Live par rapport à sa fiche chaîne et à la stratégie :

• Voix et format. Cela ressemble-t-il aux exemples de la fiche chaîne ? Longueur, hashtags, liens, emoji comme le dit le fichier ?
• Adéquation. Cela sert-il un pilier ou un OKR dans strategy.md ? Le type de publication est-il autorisé sur cette chaîne ?
• Cadence. Comptez par chaîne par rapport à l'objectif. Notez les chaînes en excès ou en déficit.
• Répétition. Publications quasi identiques sur la même chaîne, ou le même message sur chaque chaîne le même jour.
• Faits. Affirmations, chiffres et noms que le champ Source ne soutient pas.

Ne signalez que les problèmes que vous pouvez attribuer à une publication spécifique. Citez le nom de l'enregistrement et la date.

3. Regarder les 14 prochains jours

python3 $CAL list --from +1 --to +14 --json > /tmp/review-next.json

Par chaîne et par semaine, signalez :

• Lacunes : semaines en dessous de la cible de cadence. Suggérez quel type de publication les comblerait à partir du contenu déjà disponible (un podcast avec des clips inutilisés, un article récent).
• Surcharge : plus d'une publication par jour sur une chaîne, ou une semaine dominée par un seul type (trois articles d'actualité, des promotions consécutives).
• Publications hors stratégie : contenu qui ne correspond à aucun pilier ou que la fiche chaîne exclut.
• Goulots d'approbation : publications To approve dues dans les 3 prochains jours, regroupées par Owner, afin que quelqu'un puisse les relancer.
• Publications Needs media dues dans les 7 prochains jours, avec ce dont chacune a besoin.

4. Récupérer les métriques lorsque c'est possible

Essayez dans cet ordre et utilisez ce qui est disponible :

1. Un connecteur de plateforme, comme un connecteur LinkedIn ou un autre MCP d'analytique. Récupérez les impressions, réactions, commentaires, republications et clics par publication pour les 7 derniers jours et faites correspondre aux enregistrements par Live link ou date et chaîne.
2. Un connecteur d'analytique web (GA4 ou similaire). Récupérez les sessions provenant de référents sociaux ou de liens marqués UTM pour la semaine.
3. Exportations manuelles : fichiers CSV dans $STRATEGY_DIR/metrics/ (par exemple un export d'analytique de page LinkedIn). Utilisez le fichier le plus récent par chaîne et indiquez quel fichier vous avez lu.

Lorsqu'aucun de ceux-ci n'existe pour une chaîne, écrivez "Aucune métrique pour <chaîne> cette semaine" et passez à autre chose. N'estimez, n'extrapolez et n'inventez jamais de chiffres. Une révision sans métriques reste utile pour les vérifications de stratégie et de cadence.

Avec les métriques, comparez uniquement les publications sur la même chaîne. Recherchez des motifs qui se répètent sur au moins 3 publications, comme le type de publication, le style d'ouverture, média ou non, jour de la semaine. Une seule bonne ou mauvaise publication n'est pas un motif.

5. Rédiger le rapport

Sauvegardez-le dans $STRATEGY_DIR/reviews/YYYY-MM-DD.md (créez le dossier si nécessaire) et imprimez-le. Limitez-le à un écran :

# Révision sociale, semaine du 2026-11-02

## Résumé
Trois à cinq phrases simples. Ce qui a été publié, ce qui a cassé, le seul changement qui vaut la peine d'être fait.

## 7 derniers jours
| Chaîne | Live | Objectif | Échec | Notes |
|---|---|---|---|---|

Problèmes spécifiques, un point par ligne, avec le nom de l'enregistrement et la date.

## Métriques
Par chaîne : ce que vous avez trouvé et sa source, ou "Aucune métrique pour <chaîne> cette semaine".

## 14 prochains jours
Lacunes, surcharge, publications hors stratégie, approbations à relancer (par propriétaire), médias encore nécessaires.

## Changements proposés
Liste numérotée. Chacun nomme le fichier, explique pourquoi en une phrase et montre un diff.

6. Proposer des modifications aux fichiers de stratégie et de chaîne

Ne proposez un changement que lorsque les preuves de cette semaine le soutiennent : une erreur répétée, une règle que personne ne suit, une cadence qui ne tient pas, ou un motif dans les métriques sur plusieurs publications. Chaque proposition est un diff unifié par rapport au fichier actuel :

--- channels/brightloop-linkedin.md
+++ channels/brightloop-linkedin.md
@@ Cadence @@
-- 5 publications par semaine, du lundi au vendredi
+- 4 publications par semaine, du lundi au jeudi. Les publications du vendredi ont obtenu moins de la moitié des réactions des autres jours au cours des 6 dernières semaines.

N'appliquez pas les diffs. Listez-les et attendez que l'utilisateur dise lesquels appliquer. Appliquez-les sans demander uniquement si l'invite de routine l'autorise explicitement, et alors seulement pour le type de changement qu'elle nomme. Ne modifiez jamais le fichier de chaîne d'une autre personne sans son approbation, même lorsqu'il est permis d'appliquer des changements.

Ne modifiez pas les enregistrements Airtable depuis cette compétence. Si une publication planifiée doit changer, dites laquelle et pourquoi. L'utilisateur ou la compétence social-calendar effectue le changement.

Exemple d'invite de routine

Configurez ceci comme une tâche ou routine hebdomadaire programmée, par exemple tous les lundis à 08h00, avec le dépôt comme répertoire de travail :

Exécutez la compétence social-calendar-review pour la semaine passée.
STRATEGY_DIR est ./my-strategy. Les identifiants Airtable sont dans .env.
Utilisez le connecteur LinkedIn pour les métriques s'il est disponible. Sinon, lisez le fichier CSV
le plus récent dans ./my-strategy/metrics/ pour chaque chaîne, et indiquez clairement où il n'y en a pas.
Sauvegardez le rapport dans ./my-strategy/reviews/ et publiez les sections Résumé et Changements proposés
dans #marketing sur Slack.
N'appliquez aucun changement proposé. Je répondrai avec les numéros que je souhaite appliquer.

Pour permettre à la routine d'effectuer de petites corrections par elle-même, remplacez la dernière ligne par quelque chose comme "Vous pouvez appliquer les changements proposés aux listes de hashtags et aux jours de publication dans mes propres fichiers de chaîne. Laissez tout le reste comme proposition."