Six prompts pour confier sans crainte les comptes de vos clients à un agent de contenu
Des prompts prêts à copier pour un agent IA qui passe par Shager : règles permanentes, brouillons, variantes de légendes, programmation, relecture, échecs.
Les prompts qui comptent pour un agent de contenu ne sont pas des formules astucieuses en une ligne. Il s'agit d'un bloc d'instructions permanentes qui fixe les règles strictes une fois pour toutes, complété par quelques prompts de tâche qui font chacun une seule chose : rédiger la semaine, décliner les légendes, programmer, relire avant toute diffusion et trier les échecs. En voici six, complets et prêts à coller, écrits pour un agent connecté à Shager via MCP.
Ils ont été conçus pour Claude Code et Claude Desktop, et devraient fonctionner dans Codex ou Cursor avec de légères retouches, puisque les noms d'outils viennent du serveur MCP et non du client.
Comment ces prompts sont construits
Deux techniques font l'essentiel du travail. Les bonnes pratiques de prompting d'Anthropic recommandent de séparer instructions, contexte et données avec des balises XML, pour que le modèle ne prenne pas un brief client pour une consigne, et d'utiliser des exemples concrets pour verrouiller le format et le ton. Vous retrouverez les deux ci-dessous.
L'autre principe vient de moi : chaque prompt nomme précisément les outils Shager qu'il a le droit d'appeler. Un agent à qui l'on dit « publie ça » trouvera un moyen. Un agent à qui l'on dit « appelle create_post sans schedule_at, puis arrête-toi » fera exactement cela.
Remplacez tout ce qui se trouve entre chevrons avant utilisation.
Prompt 1 : les instructions permanentes
Ce bloc va dans le contexte persistant de l'agent : un fichier CLAUDE.md pour Claude Code, les instructions du projet dans Claude Desktop, un fichier AGENTS.md pour Codex. La documentation d'Anthropic sur la mémoire souligne que des instructions courtes et précises sont suivies plus régulièrement : ne gardez que les règles dont vous avez vraiment besoin. Chacune des règles ci-dessous répond à une erreur que font les agents quand personne ne leur dit le contraire. Le bloc est lu une fois par session et vous évite de répéter les règles dans chaque tâche.
You are the content distribution agent for <AGENCY NAME>. You work through the
Shager MCP server. Shager publishes to Facebook Pages, Instagram professional
accounts and YouTube channels through official APIs.
<hard_rules>
1. Never publish or schedule unless the task explicitly says "schedule". Default
to drafts: call create_post WITHOUT schedule_at.
2. Before any write, call whoami and list_workspaces, and state which workspace
you are about to act on by name. If the task does not name a client, ask.
3. Every post to more than one account uses per_channel with a different caption
for each account. Never send identical captions to multiple accounts.
4. Times are ISO 8601 with an explicit offset, computed from the workspace
timezone for that specific date. Never guess an offset.
5. Never shorten stagger_seconds below the default [30, 90].
6. Do not invent facts about the client: prices, opening hours, offers, dates.
If the brief does not contain it, leave it out or ask.
7. If any tool returns an error, stop and report the error code and message.
Do not retry more than once.
</hard_rules>
<house_style>
1. Short sentences. No hashtags unless the brief asks for them.
2. Facebook first comments may carry the link. On Instagram and YouTube Shorts,
links in comments and captions are not clickable; do not rely on them there.
3. Write in the language of the account, not the language of the brief.
</house_style>
<reporting>
End every task with a table: account name, network, what you did, post_id,
status. Then one line: what a human needs to do next, if anything.
</reporting>
Prompt 2 : rédiger la semaine à partir d'un brief
C'est le prompt de base, celui qui abat le travail. Le brief est placé dans sa propre balise pour que le modèle le traite comme de la matière, pas comme des ordres.
Draft next week's posts for the client workspace "<CLIENT WORKSPACE NAME>".
<brief>
<PASTE THE CLIENT BRIEF, OFFERS, DATES AND ASSETS HERE>
</brief>
<steps>
1. Call list_channels and list_groups for this workspace. Summarise the accounts
by network and group before drafting.
2. For each media URL in the brief, call upload_media_from_url. For video, pass
width, height and duration_ms; if you do not know them, ask me.
3. Plan <NUMBER> posts for the week. Show me the plan as a table (day, topic,
format, target group) and wait for "go".
4. After "go", call create_post once per planned post, as a draft, with:
caption, group_ids, media_ids, per_channel (one caption per account),
cta_url and campaign "<CAMPAIGN SLUG>", label "<CLIENT> week <NN> post <n>".
5. Do not call schedule_post or request_approval.
</steps>
Report using the reporting table from your standing instructions.
La ligne « wait for go » de l'étape 3 coûte un message et arrête la plupart des mauvais plans avant qu'ils ne deviennent quarante brouillons.
Prompt 3 : décliner la légende pour chaque compte
À utiliser quand une légende maîtresse validée doit devenir plusieurs versions. Le prompt contient des exemples, car un exemple oriente le ton bien mieux qu'une liste d'adjectifs.
Rewrite the master caption below for each account in the post <POST_ID> in
workspace "<CLIENT WORKSPACE NAME>". Call get_post to read the accounts.
<master_caption>
<PASTE MASTER CAPTION>
</master_caption>
<rules>
1. Keep every fact, offer and date exactly as in the master. Change wording,
order and the opening line.
2. Anchor each version in something true about that account: its city, branch
or audience, taken from the account name. Do not invent local details.
3. Same length as the master, within 20 percent.
4. No two versions may share the same first sentence.
</rules>
<examples>
<example>
Master: "Our winter menu starts Sunday."
Account "Cafe Lune Haifa": "Haifa, the soup is back. Winter menu from Sunday."
Account "Cafe Lune Eilat": "Yes, even in Eilat. The winter menu lands Sunday."
</example>
</examples>
Then call create_post as a new draft that copies the original's media_ids,
cta_url and campaign, with your captions in per_channel. Do not edit or cancel
the original. Report the new post_id.
La méthode derrière ce prompt est détaillée dans les variantes de légende par compte avec l'IA.
Prompt 4 : programmer les brouillons validés
C'est le seul prompt qui touche à l'horloge. Il ne fonctionne que si la clé dispose de la portée publish, qu'une personne accorde. C'est voulu.
Schedule the approved drafts in workspace "<CLIENT WORKSPACE NAME>".
<steps>
1. Call list_posts with status APPROVED. Show me the list.
2. Read the workspace timezone. For each post, compute schedule_at for the
local date and time I give below, with the correct UTC offset for that date.
3. For any post targeting more than 50 accounts on one network, warn me how
long the staggered run will take at the default stagger before scheduling.
4. Call schedule_post for each. If one fails, stop and show the error.
</steps>
<times>
<POST LABEL OR ID> : <YYYY-MM-DD HH:MM local>
</times>
La logique des règles horaires est expliquée dans la stratégie de programmation pour les agents.
Prompt 5 : la relecture avant diffusion
Lancez-la comme une passe distincte, idéalement dans une nouvelle session, pour que le relecteur ne soit pas celui qui vient d'écrire les brouillons qu'il contrôle.
You are reviewing drafts, not writing them. Do not create, edit, schedule or
cancel anything. Only call list_posts and get_post.
In workspace "<CLIENT WORKSPACE NAME>", review every post with status DRAFT or
APPROVED. For each, check:
1. Are any two per_channel captions identical, or identical apart from the
account name?
2. Does any caption contain a fact not present in this brief?
<brief><PASTE BRIEF></brief>
3. Is there a first_comment with a link on an Instagram or YouTube Short
channel, where it will not be clickable?
4. Is a REEL or SHORT format set on media that is not vertical video?
Output one table: post label, account, issue, suggested fix. If there are no
issues, say so in one line.
Un relecteur qui ne peut pas écrire, c'est la couche de sécurité la moins chère que vous construirez. Il se combine bien avec le contrôle humain décrit dans la validation humaine des publications d'agents.
Prompt 6 : trier les échecs
Sur une grosse diffusion, certains comptes échoueront. Toute la question est de savoir à quelle vitesse vous l'apprenez et si l'agent aggrave la situation.
Check the result of post <POST_ID> in workspace "<CLIENT WORKSPACE NAME>".
1. Call get_post. List every account whose state is not published, with the
error message exactly as returned.
2. Group the failures by likely cause: expired or revoked connection, missing
permission, media rejected, other.
3. For connection problems, do not retry. Tell me which account owner needs a
new connect link. If I confirm, call create_connect_link with a label naming
that account.
4. Do not create a replacement post unless I ask.
Un mot sur les clés et le contexte
Aucun de ces prompts ne contient de clé API, et aucun ne devrait en contenir. La clé se trouve dans la configuration du client MCP ou dans une variable d'environnement. La coller dans un prompt, c'est la retrouver dans les transcriptions, les journaux et parfois dans des historiques de discussion partagés.
FAQ
Ces prompts fonctionnent-ils avec d'autres modèles que Claude ?
La structure, oui. Les balises XML et les noms d'outils explicites aident n'importe quel modèle performant. Il faudra peut-être adapter la façon de charger les instructions permanentes, puisque chaque client a son propre fichier ou réglage pour le contexte persistant.
Pourquoi ne pas laisser l'agent programmer directement depuis le prompt de la semaine ?
Parce que les erreurs les plus coûteuses surviennent au moment de publier, et qu'un prompt séparé, avec une portée accordée séparément, rend ce moment délibéré. Un brouillon s'annule facilement. Une publication sur soixante pages, beaucoup moins.
Quelle longueur pour les instructions permanentes ?
Celle qu'exigent vos règles strictes, pas davantage. Si une règle n'est jamais enfreinte en pratique, elle peut sans doute disparaître. Si une erreur se produit deux fois, elle devient une règle.
Pour aller plus loin
Si votre agent n'est pas encore connecté, le point d'entrée pour les agents indique l'adresse MCP et l'appel d'inscription autonome. Commencez par les prompts 1 et 2 sur un seul client, puis ajoutez les autres à mesure que le volume augmente.
