# ست تعليمات تجعل وكيل المحتوى آمنًا على حسابات العملاء

_2026-09-22 · تعليمات جاهزة للنسخ لوكيل محتوى يعمل عبر Shager: قواعد ثابتة، ومسودات أسبوعية، وتنويع النصوص، والجدولة، والمراجعة، ومعالجة الأعطال._

التعليمات التي تصنع الفرق مع وكيل المحتوى ليست جملًا ذكية من سطر واحد. إنها كتلة تعليمات ثابتة تضع القواعد الصارمة مرة واحدة، ومعها عدد قليل من تعليمات المهام، كل واحدة تؤدي عملًا واحدًا: كتابة مسودات الأسبوع، وتنويع النصوص، والجدولة، والمراجعة قبل خروج أي شيء، ومعالجة الأعطال. إليك ست منها، كاملة وجاهزة للصق، مكتوبة لوكيل مربوط بـ Shager عبر MCP.

كُتبت هذه التعليمات لـ Claude Code وClaude Desktop، ويُفترض أن تعمل في Codex أو Cursor مع تعديلات بسيطة، لأن أسماء الأدوات تأتي من خادم MCP لا من العميل.

## كيف بُنيت هذه التعليمات

تقنيتان تحملان معظم العبء. توصي [أفضل ممارسات كتابة التعليمات](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) لدى Anthropic بالفصل بين التعليمات والسياق والمدخلات بوسوم XML، كي لا يخلط النموذج بين موجز العميل وأمر موجّه إليه، وباستخدام أمثلة ملموسة لتثبيت الصيغة والنبرة. وستجد التقنيتين في ما يلي.

أما المبدأ الآخر فهو من تجربتي: كل تعليمات تذكر بالاسم أدوات Shager التي يحق للوكيل استدعاؤها. الوكيل الذي يُقال له «انشر هذا» سيجد طريقة ما. والوكيل الذي يُقال له «استدعِ `create_post` من دون `schedule_at` ثم توقف» سيفعل ذلك بالضبط.

استبدل كل ما بين الأقواس الزاوية قبل الاستخدام.

## التعليمات 1: التعليمات الثابتة

توضع هذه في السياق الدائم للوكيل: ملف [`CLAUDE.md`](https://code.claude.com/docs/en/memory) في Claude Code، وتعليمات المشروع في Claude Desktop، وملف [`AGENTS.md`](https://developers.openai.com/codex/guides/agents-md) في Codex. تشير وثائق الذاكرة لدى Anthropic إلى أن التعليمات الأقصر والأكثر تحديدًا تُتَّبع بثبات أكبر، فاحتفظ فقط بالقواعد التي تحتاجها فعلًا. كل قاعدة هنا تعالج خطأً يرتكبه الوكلاء حين لا يُقال لهم غير ذلك. تُقرأ مرة في كل جلسة، وتوفّر عليك تكرار القواعد في كل مهمة.

```text
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>
```

## التعليمات 2: مسودات الأسبوع انطلاقًا من موجز

هذه هي أداة العمل اليومية. يوضع الموجز داخل وسم خاص به كي يعامله النموذج مادةً للعمل، لا أوامر.

```text
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.
```

سطر «انتظر go» في الخطوة 3 يكلّف رسالة واحدة، ويلتقط معظم الخطط السيئة قبل أن تتحول إلى أربعين مسودة.

## التعليمات 3: تنويع النص لكل حساب

استخدمها حين يجب أن يتحول نص رئيسي واحد حصل على الموافقة إلى نصوص كثيرة. وهي تتضمن أمثلة، لأن الأمثلة توجّه النبرة أفضل مما تفعل الصفات.

```text
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.
```

المنهج الذي تقوم عليه هذه التعليمات مشروح بتفصيل أكبر في [تنويع النصوص لكل حساب بالذكاء الاصطناعي](/ar/blog/caption-variation-per-account-with-ai).

## التعليمات 4: جدولة المسودات الموافَق عليها

هذه هي التعليمات الوحيدة التي تلمس الساعة. ولا تعمل إلا إذا كان المفتاح يحمل صلاحية `publish`، التي يمنحها إنسان. وهذا مقصود.

```text
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>
```

المنطق وراء قواعد التوقيت موجود في [استراتيجية الجدولة للوكلاء](/ar/blog/scheduling-strategy-for-agents).

## التعليمات 5: مراجعة ما قبل الإطلاق

شغّلها جولةً مستقلة، ويُفضّل في جلسة جديدة، كي لا يكون المراجع هو من كتب للتو المسودات التي يفحصها.

```text
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.
```

المراجع الذي لا يستطيع الكتابة هو أرخص طبقة أمان ستبنيها. ويتكامل جيدًا مع البوابة البشرية الموصوفة في [موافقة الإنسان على منشورات الوكيل](/ar/blog/human-approval-for-agent-posts).

## التعليمات 6: معالجة الأعطال

في أي إطلاق كبير ستفشل بعض الحسابات. السؤال هو متى تعرف بذلك، وهل سيزيد الوكيل الأمر سوءًا.

```text
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.
```

## ملاحظة عن المفاتيح والسياق

لا تحتوي أي من هذه التعليمات على مفتاح API، ولا ينبغي لها ذلك. يعيش المفتاح في إعدادات عميل MCP أو في متغير بيئة. ولصقه في التعليمات يضعه في سجلات الجلسات والسجلات التقنية، وأحيانًا في سجل محادثات مشترك.

## أسئلة شائعة

### هل تعمل هذه التعليمات مع نماذج غير Claude؟

البنية تعمل. وسوم XML وأسماء الأدوات الصريحة تساعد أي نموذج قادر. وقد تحتاج إلى تعديل طريقة تحميل التعليمات الثابتة، لأن لكل عميل ملفه أو إعداده الخاص بالسياق الدائم.

### لماذا لا أترك الوكيل يجدول مباشرة من تعليمات مسودات الأسبوع؟

لأن أغلى الأخطاء تقع لحظة النشر، وتعليمات مستقلة بصلاحية تُمنح على حدة تجعل تلك اللحظة قرارًا مقصودًا. التراجع عن مسودة رخيص، أما منشور ذهب إلى ستين صفحة فلا.

### ما الطول المناسب للتعليمات الثابتة؟

بالقدر الذي تتطلبه قواعدك الصارمة، لا أكثر. إن لم تُخرق قاعدة ما عمليًا أبدًا، فربما يمكن حذفها. وإن تكرر خطأ مرتين، صار قاعدة.

## إلى أين بعد ذلك

إن لم يكن وكيلك مربوطًا بعد، فإن [نقطة دخول الوكلاء](/ar/agents) تعرض عنوان MCP واستدعاء التسجيل الذاتي. ابدأ بالتعليمات 1 و2 مع عميل واحد، ثم أضف البقية مع ازدياد الحجم.

---
Source: https://shager.ai/ar/blog/prompts-for-a-content-agent