social-calendar

Calendrier social

Transformez un contenu en publications pour plusieurs canaux et placez-les dans le calendrier Airtable pour approbation. La publication se fait via scripts/publish_approved.py, qui transmet les publications approuvées au planificateur d'Upload-Post. Vous l'exécutez uniquement lorsque l'utilisateur le demande.

Les noms de champs, les valeurs de statut et les variables d'environnement proviennent de docs/data-model.md dans le dépôt. Ne renommez rien. Les chemins de scripts ci-dessous sont relatifs au dossier de ce skill.

Avant de commencer

1. Vérifiez que AIRTABLE_TOKEN et AIRTABLE_BASE_ID sont définis (environnement ou fichier .env dans le répertoire de travail ou la racine du dépôt). Exécutez python3 scripts/airtable_calendar.py channels comme test de bon fonctionnement. Si les tables n'existent pas encore, orientez l'utilisateur vers scripts/setup_airtable.py à la racine du dépôt.
2. Trouvez le dossier de stratégie. Utilisez STRATEGY_DIR s'il est défini. Sinon, cherchez strategy.md dans le répertoire de travail, ./my-strategy/ et ./strategy/. S'il n'y en a pas, demandez où il se trouve. Si l'utilisateur n'en a pas encore, proposez de copier templates/strategy.md et templates/channels/_channel-template.md et de les remplir ensemble avant d'écrire des publications.

Si le connecteur MCP Airtable est disponible, vous pouvez l'utiliser à la place du script pour les lectures et écritures. Les règles de ce fichier s'appliquent toujours. Voir references/airtable.md.

Flux de travail

1. Lire la stratégie et les fichiers de canaux

Lisez strategy.md en intégralité : objectifs, OKR, audiences, piliers de contenu, règles globales. Ensuite, listez channels/*.md et lisez les fichiers des canaux auxquels ce contenu pourrait aller. Chaque fichier de canal contient la voix, les objectifs, la cadence, les formats, les listes de bonnes et mauvaises pratiques, et des exemples de publications de ce compte.

Faites correspondre les fichiers de canaux aux lignes de la table Canaux via le champ Fichier du canal. Seuls les canaux qui sont Actif dans Airtable peuvent recevoir des publications. Si un fichier de canal n'a pas de ligne correspondante, mentionnez-le et ignorez-le.

2. Identifier le type de publication et la campagne

Déterminez ce qu'est le contenu : lancement de fonctionnalité, actualité, extraits de podcast ou vidéo, avis client, photos d'événement, aperçu de données ou de texte, promotion d'article, ou autre chose. Lisez references/post-types.md pour savoir comment chaque type devient des publications, quels canaux lui conviennent et jusqu'où le diffuser.

Donnez un libellé de Campagne au lot sous la forme AAAA-MM <Type> <Libellé>, par exemple 2026-11 Épisode Podcast 12 ou 2026-11 Fonctionnalité Export CSV. Mettez l'entrée brute dans Source (lien, nom de fichier, épisode, ou une note d'une ligne).

Ne posez une question que lorsque la réponse modifie les publications, comme « quels canaux ? » lorsque la stratégie ne le rend pas évident, ou « est-ce sous embargo jusqu'à une date ? ». Sinon, décidez et dites ce que vous avez décidé.

3. Consulter le calendrier

Listez ce qui est déjà planifié pour la période que vous allez remplir (par défaut les 4 prochaines semaines, plus long pour les extraits de podcast) :

python3 scripts/airtable_calendar.py list --from today --to +28 --json > /tmp/calendar.json

Pour chaque canal cible, déterminez :

• Lacunes de cadence. Publications par semaine par rapport à l'objectif du fichier de canal. Comptez tous les statuts sauf Rejeté et Échoué.
• Collisions. Jours ayant déjà une publication sur ce canal. Par défaut, au maximum une publication par jour par canal, sauf indication contraire du fichier de canal.
• Mélange de sujets. Trop d'un même type dans une semaine (trois publications d'actualité, deux promotions à la suite). Poussez la nouvelle publication vers une semaine plus légère.
• Doublons. Le même message déjà planifié ou récemment publié. La commande create effectue une vérification de similarité. Vous pouvez l'exécuter seule avec check-duplicates.

4. Rédiger les publications

Écrivez une publication par canal par date. Chacune suit le fichier de son canal : voix, longueur, format, hashtags, appel à l'action. Règles applicables partout :

• Utilisez uniquement les faits présents dans la source ou les fichiers de stratégie. N'inventez pas de chiffres, citations, noms de clients ou résultats.
• Ne copiez pas le même texte sur tous les canaux. Le profil d'un fondateur et la page de l'entreprise disent des choses différentes sur la même fonctionnalité.
• Les canaux des employés et co-fondateurs sont rédigés dans la voix de cette personne et nécessitent son approbation. Définissez Propriétaire comme l'approbateur nommé dans le fichier de canal.
• ContenuPublication contient le texte final avec de vrais sauts de ligne. Les émojis et l'Unicode sont acceptables. Les hashtags vont en ligne, généralement à la fin, comme l'indique le fichier de canal.
• LinkedIn et X affichent **texte** comme des astérisques littéraux. N'utilisez **gras** que pour les canaux où un humain colle dans un éditeur compatible Markdown, comme Substack. Suivez le fichier de canal s'il dit autrement.
• Limites de longueur : X divise tout texte de plus de 280 caractères en thread, Threads plus de 500, Bluesky plus de 300. Écrivez pour vous adapter, sauf si le fichier de canal demande des threads.
• Suivez les règles d'écriture de strategy.md. S'il n'y en a pas, écrivez des phrases directes simples et évitez le remplissage, les mots exagérés et les expressions toutes faites.

5. Choisir les dates

Planifié pour est une date seulement, AAAA-MM-JJ. L'heure provient du champ Heure de publication et Fuseau horaire du canal, donc ne mettez pas d'heures dans la publication.

• Remplissez d'abord les lacunes de cadence, puis répartissez le reste. Les publications promotionnelles pour un article s'étalent sur 2 à 3 semaines, pas toutes le même jour.
• Les actualités sortent le jour même ou le lendemain, ou pas du tout.
• Les extraits de podcast vont environ une ou deux par canal par semaine sur environ 3 mois.
• Mélangez les types sur une semaine : éducation, engagement, produit, preuve sociale.
• N'utilisez jamais une date passée. Utilisez aujourd'hui uniquement si l'utilisateur le demande et sait que le passage quotidien a peut-être déjà eu lieu.
• Si une semaine est pleine, déplacez la publication à la semaine suivante et mentionnez-le dans le rapport.

6. Héberger les médias

Airtable n'ingère que les URLs publiques. Les chemins locaux et les liens file:// sont ignorés silencieusement. Les images et vidéos dans un lot de création peuvent être des chemins locaux. Le script les télécharge d'abord sur catbox.moe et transmet l'URL publique à Airtable, qui copie le fichier sur son propre stockage. Les téléchargements sur Catbox sont publics et ne peuvent pas être supprimés, donc ne l'utilisez pas pour des données confidentielles. Demandez à l'utilisateur un autre hébergeur dans ce cas. Les détails sont dans references/airtable.md.

Pour les publications textuelles et de données qui nécessitent un visuel (Instagram, TikTok, ou un fichier de canal qui en demande un), créez une image simple. Suivez references/visuals.md.

7. Créer les enregistrements

Écrivez le lot sous forme de liste JSON en utilisant les noms de champs des Publications :

[
  {
    "Name": "Fonctionnalité - Export CSV",
    "Status": "À approuver",
    "Scheduled for": "2026-11-12",
    "Channel": "Brightloop LinkedIn",
    "PostContent": "Vous pouvez maintenant exporter n'importe quel rapport en CSV.\n\nUn clic, en haut à droite.",
    "Media": ["/tmp/csv-export.png"],
    "Source": "Note de version 2026-11-10",
    "Campaign": "2026-11 Fonctionnalité Export CSV",
    "Owner": "[email protected]"
  }
]

Choisissez le statut comme suit :

Situation	Statut
Prêt pour examen par le propriétaire (par défaut)	À approuver
Instagram, TikTok, YouTube ou Pinterest sans média encore	Nécessite un média
L'utilisateur veut faire des allers-retours sur le texte d'abord	Brouillon
L'utilisateur approuve explicitement pour ses propres canaux (voir ci-dessous)	Approuvé

Faites d'abord un essai à blanc, montrez le plan à l'utilisateur, puis créez :

python3 scripts/airtable_calendar.py create /tmp/batch.json --dry-run
python3 scripts/airtable_calendar.py create /tmp/batch.json

create valide les noms de champs, les statuts, les dates et les noms de canaux, rétrograde les publications sans média pour les plateformes uniquement visuelles à Nécessite un média, et refuse d'écrire s'il trouve des doublons probables. Corrigez le lot, ou passez --allow-duplicates si l'utilisateur confirme vouloir la répétition. Il écrit par lots de 10. Les plans conservés dans un CSV avec les colonnes Date, Canal, Type de contenu, Texte de la publication, Hashtags, Suggestion d'image peuvent être intégrés directement avec --csv.

8. Faire un rapport

Terminez par un tableau, une ligne par enregistrement créé, trié par date :

Date	Canal	Statut	Nom	Ligne d'ouverture

En dessous, listez en phrases simples : les canaux ignorés et pourquoi, les publications repoussées à une semaine ultérieure, les publications en Nécessite un média et ce dont elles ont besoin, et tout ce que le propriétaire devrait vérifier (affirmations, noms, liens).

Autres demandes

• « Ajoute l'image à ces publications. » Exécutez python3 scripts/airtable_calendar.py attach <record_id> <file or URL>. Une publication en Nécessite un média passe automatiquement à À approuver.
• **« Déplace cette publication », « rejette celle-là ». ** Exécutez update <record_id> --set "Scheduled for=2026-11-20" ou --set Status=Rejected. Si la publication est déjà Planifiée, exécutez ensuite python3 scripts/publish_approved.py --sync pour que la copie d'Upload-Post change aussi.
• « Qu'est-ce qui sort cette semaine ? » Exécutez list --from today --to +7 et résumez par canal et par jour.
• Modifications de la stratégie ou de la voix. Modifiez les fichiers markdown, pas Airtable. Le skill hebdomadaire social-calendar-review propose ces modifications.

Approuver au nom de l'utilisateur

Uniquement lorsque l'utilisateur le dit explicitement (« approuve les miens », « ceux-ci peuvent sortir directement »), et uniquement pour les canaux dont il est le Propriétaire. N'approuvez jamais de publications sur le profil d'un employé ou d'un co-fondateur, même si demandé en passant. Orientez l'utilisateur vers cette personne à la place. Définissez ces enregistrements à Approuvé, soit à la création, soit avec update <record_id> --set Status=Approved, et listez-les séparément dans le rapport.

Transition vers la publication

Lorsque l'utilisateur demande de planifier les publications approuvées (« planifie tout ce qui est approuvé », « publie-les ») :

1. Exécutez python3 scripts/publish_approved.py --sync --reconcile --mode schedule --dry-run et montrez ce qui serait envoyé : canal, date et heure, type de média, première ligne du texte.
2. Après confirmation de l'utilisateur, exécutez-le sans --dry-run. Upload-Post détient le planning et les publications deviennent Planifiée.
3. Si le créneau d'une publication approuvée est déjà passé, mentionnez-le et proposez --mode now.

L'utilisateur peut également avoir une routine ou une tâche cron exécutant le script, auquel cas les publications approuvées sont planifiées sans vous. Lisez references/publishing.md pour le rééchelonnement, l'annulation, la réconciliation et le mappage complet des champs. Préférez le script plutôt que d'effectuer vous-même les appels Upload-Post, car le script ne coûte aucun jeton par publication.

Ne publiez et ne planifiez jamais quoi que ce soit que l'utilisateur n'a pas demandé dans cette conversation. Écrire des enregistrements avec À approuver est la fin normale de ce skill.