Müşteri hesaplarında içerik ajanını güvenle çalıştırmanın altı komut istemi

Bir içerik ajanı için önemli olan komut istemleri, zekice yazılmış tek satırlık cümleler değildir. Önemli olan, katı kuralları bir kez koyan kalıcı bir talimat bloğu ve her biri tek bir iş yapan birkaç görev istemidir: haftanın taslaklarını hazırlamak, açıklamaları çeşitlendirmek, planlamak, hiçbir şey yayına çıkmadan kontrol etmek ve hataları analiz etmek. Aşağıda bunlardan altısını, eksiksiz ve yapıştırmaya hazır hâlde bulacaksınız. Hepsi Shager'a MCP üzerinden bağlı bir ajan için yazıldı.

İstemler Claude Code ve Claude Desktop için yazıldı. Araç adları istemciden değil MCP sunucusundan geldiği için küçük değişikliklerle Codex veya Cursor'da da çalışmaları gerekir.

Bu istemler nasıl kurgulandı

Yükün büyük kısmını iki teknik taşıyor. Anthropic'in komut istemi en iyi uygulamaları, modelin bir müşteri brifini talimatla karıştırmaması için talimatları, bağlamı ve girdileri XML etiketleriyle ayırmayı; biçimi ve tonu netleştirmek için de somut örnekler kullanmayı öneriyor. İkisini de aşağıda göreceksiniz.

Diğer ilke benim: her istem, ajanın çağırabileceği Shager araçlarını adıyla belirtir. "Bunu yayınla" denen bir ajan bir yolunu bulur. "create_post aracını schedule_at olmadan çağır, sonra dur" denen bir ajan tam olarak bunu yapar.

Kullanmadan önce köşeli parantez içindeki her şeyi kendi bilgilerinizle değiştirin.

Diyagramın tamamı için yana kaydırın

İstem 1: kalıcı talimatlar

Bu blok ajanın kalıcı bağlamına girer: Claude Code için bir CLAUDE.md dosyası, Claude Desktop'ta proje talimatları, Codex için bir AGENTS.md dosyası. Anthropic'in bellek belgeleri, kısa ve somut talimatlara daha tutarlı uyulduğunu belirtiyor; o yüzden yalnızca gerçekten ihtiyaç duyduğunuz kuralları tutun. Buradaki her kural, kimse aksini söylemediğinde ajanların yaptığı bir hatayı hedefliyor. Blok her oturumda bir kez okunur ve sizi her görevde kuralları tekrarlamaktan kurtarır.

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>

İstem 2: briften haftanın taslaklarını hazırlamak

İşin asıl yükünü bu istem taşır. Brif kendi etiketinin içine konur; böylece model onu emir olarak değil, malzeme olarak ele alır.

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.

3. adımdaki "go bekle" satırı size tek bir mesaja mal olur, ama kötü planların çoğunu kırk taslağa dönüşmeden yakalar.

İstem 3: hesap başına açıklama çeşitleme

Onaylanmış tek bir ana açıklamanın birçok sürüme dönüşmesi gerektiğinde bunu kullanın. İstemde örnekler var, çünkü tonu sıfatlardan çok örnekler yönlendirir.

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.

Bu istemin arkasındaki yöntem, yapay zekâ ile hesap başına açıklama çeşitleme yazısında daha ayrıntılı anlatılıyor.

Diyagramın tamamı için yana kaydırın

İstem 4: onaylanmış taslakları planlamak

Saate dokunan tek istem budur. Yalnızca anahtarın publish yetkisi varsa çalışır ve bu yetkiyi bir insan verir. Bu bilinçli bir tercih.

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>

Zaman kurallarının gerekçesi ajanlar için planlama stratejisi yazısında.

İstem 5: yayın öncesi kontrol

Bunu ayrı bir tur olarak, tercihen yeni bir oturumda çalıştırın; böylece kontrol eden, az önce kendi yazdığı taslakları denetlemiş olmaz.

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.

Yazma yetkisi olmayan bir kontrolcü, kurabileceğiniz en ucuz güvenlik katmanıdır. Ajan gönderileri için insan onayı yazısında anlatılan insan kontrol noktasıyla da iyi bir ikili oluşturur.

İstem 6: hata analizi

Büyük bir gönderimde bazı hesaplar mutlaka başarısız olur. Asıl soru, bunu ne kadar çabuk öğrendiğiniz ve ajanın durumu daha da kötüleştirip kötüleştirmediğidir.

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.

Anahtarlar ve bağlam hakkında bir not

Bu istemlerin hiçbirinde API anahtarı yok ve olmamalı da. Anahtar, MCP istemcisinin yapılandırmasında veya bir ortam değişkeninde durur. Onu bir isteme yapıştırmak, anahtarı konuşma kayıtlarına, loglara ve bazen paylaşılan sohbet geçmişine taşır.

Sık sorulan sorular

Bu istemler Claude dışındaki modellerle de çalışır mı?

Yapı çalışır. XML etiketleri ve açıkça adı verilen araçlar her yetenekli modele yardımcı olur. Kalıcı talimatların nasıl yüklendiğini uyarlamanız gerekebilir, çünkü her istemcinin kalıcı bağlam için kendi dosyası veya ayarı vardır.

Ajan neden haftalık taslak isteminden doğrudan planlama yapmıyor?

Çünkü en pahalı hatalar yayın anında olur. Ayrı bir istem ve ayrıca verilen bir yetki, o anı bilinçli bir adıma dönüştürür. Bir taslağı geri almak ucuzdur, altmış sayfaya giden bir gönderiyi geri almak değil.

Kalıcı talimatlar ne kadar uzun olmalı?

Katı kurallarınız ne kadarını gerektiriyorsa o kadar, daha fazla değil. Pratikte hiç çiğnenmeyen bir kural muhtemelen çıkarılabilir. Bir hata iki kez tekrarlanıyorsa kurala dönüşür.

Bundan sonra

Ajanınız henüz bağlı değilse, ajan giriş noktası MCP adresini ve kendi kendine kayıt çağrısını gösteriyor. Tek bir müşteride 1. ve 2. istemlerle başlayın, hacim büyüdükçe diğerlerini ekleyin.