تأخذك إعدادات Claude Code الافتراضيّة بعيدًا. لكن ثمّة نقطة — عادةً نحو الشهر الثالث من الاستعمال الجادّ — تتجاوزها. تريد أثرًا جانبيًّا حتميًّا بعد كلّ نداء أداة. تريد أن يقرأ الوكيل ويكي مؤسّستك الداخليّ. تريد إطلاق أداة مخصّصة تتحدّث إلى API شركتك المخصّص.

لذلك صُنع هذا المقال. أربعة أنماط :

1. Hooks — لاصق حتميّ بين خطوات الوكيل.
2. خوادم MCP — بيانات شركة يستطيع الوكيل قراءتها.
3. أدوات مخصّصة — أوامرك الخاصّة موصّلة داخل الوكيل.
4. جراحة System prompt — حين لا تكفي الـ prompts وحدها.

1. Hooks — لاصق حتميّ

الـ hook هو سكربت يُطلق على حدث معروف : onFileEdit، onShellRun، onSessionStart، onSessionEnd، إلخ. ليست « ذكاء اصطناعي » ؛ هي shell خالص.

لماذا تهمّ : تتيح لك إضافة ضمانات حتميّة حول وكيل احتماليّ بطبعه.

أمثلة أُشغّلها على كلّ مشروع :

{
  "hooks": {
    "onSessionStart": "scripts/claude-onstart.sh",
    "onFileEdit": "scripts/claude-onedit.sh",
    "onSessionEnd": "scripts/claude-onend.sh"
  }
}

scripts/claude-onstart.sh :

#!/usr/bin/env bash
# Snapshot للـ working tree قبل أن يبدأ الوكيل.
git stash push -u -m "claude-pre-session-$(date +%s)" --keep-index || true

scripts/claude-onedit.sh :

#!/usr/bin/env bash
# بعد كلّ تعديل ملف، prettier على الملف المعدّل فقط.
file="$1"
if [ -f "$file" ]; then
  pnpm prettier --write "$file" --log-level silent
fi

scripts/claude-onend.sh :

#!/usr/bin/env bash
# في نهاية الجلسة، نشحن الـ transcript.
cp ~/.claude/sessions/last.jsonl /var/log/claude/$(date +%F-%H%M).jsonl

ثلاثة hooks. كلّ جلسة الآن قابلة للـ snapshot، مهيكلة، ومُدقّقة. لا شيء منها ذكاء اصطناعي ؛ كلّها بنية تحتيّة.

2. خوادم MCP — بياناتك داخل الوكيل

Model Context Protocol (MCP) هو المعيار للسماح لوكيل بقراءة مصادر بيانات خارجيّة وقت الجلسة. بدل لصق صفحة Confluence، تربط خادم MCP ويستطيع الوكيل تصفّحه عند الطلب.

أنماط رأيتها تثمر :

• MCP لمتعقّب الأخطاء. يقرأ الوكيل التذكرة، بما فيها التعليقات، قبل أن يبدأ التطبيق.
• MCP لمخطّط قاعدة بيانات الـ staging. يستطيع الوكيل استبطان الجداول بدل التخمين.
• MCP للـ runbooks. يقرأ الوكيل docs/runbooks/<incident-type>.md تلقائيًا.

التهيئة تعيش في .claude/mcp.json :

{
  "servers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-linear"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    },
    "company-docs": {
      "command": "node",
      "args": ["./mcp/company-docs.js"]
    }
  }
}

تحذيران :

• خوادم MCP تعمل بصلاحياتك. عاملها كـ CLIs ؛ راجع كودها قبل توصيلها.
• MCP قابل للتسرّب. إذا وصّلت خادمًا يعرض بيانات عملاء، يمكن لكلّ جلسة قراءتها. قيّد النطاق بإحكام.

3. أدوات مخصّصة — أفعالك الخاصّة

Sub-agents وslash commands تتيحان لك إعادة استعمال نصّ. الأدوات المخصّصة تتيح إضافة أفعال قابلة للنداء.

مثال : أداة deploy-preview. على الوكيل ألاّ يُشغّل shell لنشر preview — كثير من الطرق لينحرف ذلك. بدل ذلك، اعرض أداة :

{
  "tools": {
    "deploy-preview": {
      "description": "نشر بيئة preview للفرع الحالي.",
      "schema": {
        "type": "object",
        "properties": {
          "branch": { "type": "string" }
        },
        "required": ["branch"]
      },
      "command": "scripts/deploy-preview.sh"
    }
  }
}

يرى الوكيل الآن فعلًا اسمه deploy-preview بمدخل مكتوب الأنواع. السكربت الذي تكتبه يقرّر ماذا يفعل. لا يستطيع الوكيل الإفلات من العقد.

هذا نفس النمط الذي سأستعمله لـ :

• run-load-test
• migrate-staging
• tail-prod-logs (للقراءة فقط)
• notify-pager-duty

كلّ واحدة حاجز يقول : « يستطيع الوكيل القيام بهذا، بهذه الطريقة بالضبط، ولا يمضي أعمق. »

4. جراحة System prompt

أحيانًا يكون سلوك sub-agent تقريبًا صحيحًا، وتعديل في system prompt يسدّ الفجوة. ثلاثة أنماط :

4أ. كتلة « rules »

ضع دائمًا الأمور غير القابلة للتفاوض تحت رأس باسم rules :

# rules
- لا تُضِف @ts-ignore أبدًا.
- لا تعدّل ملفًّا في /infra/ أبدًا.
- شغّل دائمًا `pnpm test` قبل إعلان النجاح.

يعاملها الوكيل كأقسى من مجرّد تعليمات لأنّها تبدو كقائمة قوانين.

4ب. مخطّط الإخراج أوّلًا

إذا أردت إخراجًا مهيكلًا (handoffs، JSON، YAML)، ضع المخطّط قبل الشرح النثريّ. ترسو الوكلاء على أوّل 200 token.

# مخطّط الإخراج (دائمًا أعلى الـ system prompt)
status: ok | needs-human | failed
artifacts: [path: string]
notes: string
next: code-reviewer | release-bot | done

# المنطق (تحت المخطّط، أبدًا فوقه)
# تُخرج هذا ليعرف الوكيل التالي في الـ pipeline موضعك بالضبط.

4ج. أمثلة معاكسة

أَرِ ما لا يجب فعله :

# إخراج سيّء
"تمّ. الـ cache مُنفّذ."

# إخراج جيّد
status: ok
artifacts: [{path: "lib/cache.ts"}]
notes: "LRU + TTL مُنفّذ. كلّ الاختبارات خضراء."
next: code-reviewer

الأمثلة المعاكسة فعّالة بشكل غريب أكثر من الإيجابيّة في الحصول على الالتزام. ليس لديّ نظريّة عميقة عن السبب ؛ تجريبيًا، تنجح.

حين تحتاج الأربعة معًا

الـ workflow المتقدّم الذي يُضيء الفرق الحقيقيّة :

hook (onSessionStart)              → snapshot stash
الوكيل يقرأ CLAUDE.md              → السياق
الوكيل يستدعي خادم MCP             → يقرأ تذكرة Linear
الوكيل يستدعي أداة مخصّصة          → run-load-test
hook (onFileEdit)                  → prettier
الوكيل يُصدر handoff مهيكلًا        → code-reviewer
hook (onSessionEnd)                → شحن الـ transcript

كلّ طبقة تضيف حتميّة، أو تتبّعًا، أو قدرة. لا واحدة منها هي « الوكيل ». كلّها سقالة.

تلك هي العبرة، بعد أربعة مقالات في الأنماط المتقدّمة : الوكيل هو الجزء الصغير. السقالة هي شغل الهندسة.

---

آخر مقال في السلسلة : مستقبل التطوير الوكيليّ — إلى أين يتّجه هذا في 2026، على ما سأراهن، والخطّ الذي بعده سأكون متشكّكًا.