تعرّف على Delegate Skills وكيف تقدر تستخدم Claude وCodex وأدوات AI مختلفة كفريق واحد، وتوزّع المهام بينها لتقليل التكلفة وتحسين الإنتاجية.
Delegate Skills: إزاي تخلي أدوات الذكاء الاصطناعي تشتغل كفريق واحد؟
مع انتشار أدوات الذكاء الاصطناعي، بقى طبيعي تلاقي نفسك مشترك في أكثر من خدمة: Claude، Codex، أدوات بحث، أدوات Coding، وأحيانًا أدوات إضافية للمراجعة أو الاختبار.
المشكلة إنك غالبًا بتستخدم أداة واحدة في كل مرة، بينما باقي الاشتراكات واقفة من غير استفادة حقيقية.
هنا بتظهر فكرة Delegate Skills.
الفكرة مش إنك تستبدل كل الأدوات بأداة واحدة، لكن إنك تخلي AI رئيسي يدير باقي الأدوات ويوزّع عليها المهام حسب نوع الشغل المطلوب.
وفقًا للمشروع نفسه، الـDelegate Skills مبنية حول فكرة وجود Orchestrator يكتب Brief واضح للمهمة، يرسلها إلى Implementer مناسب مثل Codex، ثم يراجع النتيجة قبل اعتمادها. GitHub
يعني إيه Orchestrator؟
تخيّل إن عندك فريق Developers.
بدل ما تعمل كل حاجة بنفسك، عندك شخص مسؤول عن إدارة الفريق.
هو اللي يقول:
أنت اعمل الـFeature.
أنت اكتب الـTests.
أنت راجع الكود.
وأنت حلل المشكلة.
نفس الفكرة هنا، لكن الفريق عبارة عن AI Agents.
مثلاً:
Claude
يكون مسؤول عن التخطيط واتخاذ القرارات.
↓
Codex
يأخذ مهمة تنفيذ محددة.
↓
Agent آخر
يعمل Review أو Research.
↓
النموذج الرئيسي يراجع النتيجة النهائية.
وده قريب من الفكرة التي يصف بها المشروع نفسه الـFleet: مجموعة مسارات أو lanes، وكل مسار يرتبط بأداة مناسبة لنوع معين من المهام. GitHub
الـWorkflow بيشتغل إزاي؟
من أهم الأفكار في Delegate Skills إن المهمة لا تُرسل للنموذج الآخر بشكل عشوائي.
الـOrchestrator يجهّز أولًا Brief كامل.
الـBrief يشمل عادةً:
الهدف من المهمة
حالة المشروع الحالية
المطلوب تغييره
الأشياء التي لا يجب تعديلها
أوامر الاختبار أو التحقق
النتيجة المتوقعة
بعد كده يتم إرسال المهمة إلى الـImplementer، وبعد رجوع النتيجة يتم عمل Review قبل دمج التغييرات. المشروع نفسه يوضح أن الـImplementer لا يمتلك تلقائيًا سياق المحادثة بالكامل، لذلك يجب أن يكون الـBrief مكتفيًا بذاته. GitHub
فكرة The Loop
الفيديو يشرح Workflow قائم على Loop متكرر:
Plan / Brief
↓
Delegate
↓
Execute
↓
Review
↓
Improve
↓
Accept
بدل:
Prompt → Generate → خلاص
الفكرة هنا أقرب لطريقة عمل Software Team حقيقي.
وده مهم خصوصًا في المشاريع الكبيرة، لأنك مش عايز Agent واحد يعمل Architecture وUI وTesting وRefactoring وكل حاجة من غير مراجعة.
Debating Plans
من الأفكار المذكورة في الشرح عن الفيديو إمكانية استخدام أكثر من نموذج لمناقشة الخطة قبل التنفيذ.
مثلًا:
Claude يقترح Architecture.
↓
Codex يراجعها.
↓
كل نموذج يوضح المشاكل المحتملة.
↓
الـOrchestrator يختار أو يحسن الخطة.
الفكرة هنا مش إن واحد منهم لازم يكون "الصح"، لكن إنك تستفيد من Second Opinion قبل ما تبدأ تنفيذ كبير. LinkedIn
Fleet System
واحدة من أقوى الأفكار هي إنك تعمل Fleet خاص بيك.
مثلًا:
Lane
Agent
Architecture
Claude
Implementation
Codex
Testing
Codex
Research
Grok
UI Review
Agent آخر
Code Review
Claude / Codex
وده فعليًا قريب من الشكل الذي يقدمه Delegate Skills: تعمل lanes مثل feature وtests وui، وكل واحدة مرتبطة بـImplementer معين. GitHub
Setup & Discovery
بدل ما تقعد تضبط كل حاجة يدويًا، المشروع يوفر Skill باسم delegate-setup هدفها اكتشاف أدوات الـCLI الموجودة عندك واقتراح Fleet مبني عليها. وبعد موافقتك يمكن كتابة إعدادات المشروع أو الإعدادات العامة. GitHub
يعني لو عندك مثلًا:
Codex CLI
Claude Code
Cursor Agent
Kimi Code
Grok
OpenCode
يمكن بناء Workflow يستفيد منهم بدل ما كل أداة تشتغل منفصلة.
هل الفكرة فعلًا توفر فلوس؟
الفيديو يركز على النقطة دي بشكل كبير.
الفكرة ببساطة إنك مش لازم تستخدم أغلى نموذج لكل Task.
مثلاً:
مش منطقي تستخدم أقوى نموذج عندك علشان يعمل:
Boilerplate
Rename لعدد كبير من الملفات
Tests
Repetitive refactoring
Codemods
Dependency updates
ممكن تخلّي نموذج أرخص أو أسرع ينفذ المهمة، بينما النموذج الأقوى يحتفظ بالتخطيط والمراجعة والقرارات المعقدة.
وده أيضًا أحد الاستخدامات التي يذكرها مشروع Codex Delegate: توجيه المهام الميكانيكية أو المحددة جيدًا إلى Codex، مع إبقاء الـOrchestrator مسؤولًا عن الحكم النهائي والجودة. GitHub
مثال عملي
لنفترض إنك بتبني منصة تعليمية.
بدل ما تقول لـClaude:
اعمل المشروع كله.
ممكن تعمل:
Claude
يحلل المشروع ويكتب Architecture.
↓
Codex
ينفذ Authentication.
↓
Codex
ينفذ Courses API.
↓
Agent UI
ينفذ الواجهات.
↓
Agent Testing
يكتب الاختبارات.
↓
Claude
يعمل Final Review.
هنا أنت فعليًا حولت أدوات الـAI من Chatbots مستقلة إلى Software Team.
أهم نقطة: الـAI الرئيسي هو المدير
Delegate Skills مش معناها إنك تسيب 5 Agents يكتبوا في المشروع بدون رقابة.
الـOrchestrator يفضل مسؤول عن:
التخطيط → توزيع المهمة → مراجعة النتيجة → القرار النهائي.
والمشروع نفسه يؤكد فكرة أن المستخدم أو الـOrchestrator يظل مسؤولًا عن Review ودمج التغييرات، بدل إعطاء الـImplementer تحكمًا مفتوحًا في كل المشروع. GitHub
مين ممكن يستفيد من Delegate Skills؟
الأداة مفيدة بشكل خاص لو أنت:
تستخدم أكثر من AI Coding Tool
عندك اشتراك Claude وCodex معًا
تعمل على مشاريع كبيرة
تستخدم Vibe Coding بشكل يومي
تريد تشغيل Tasks بالتوازي
تريد تقليل استهلاك النموذج الأغلى
تحتاج مراجعة من Model مختلف
تريد Workflow أقرب لطريقة عمل فريق Development
الخلاصة
الاتجاه الجديد في الـAI Coding مش بالضرورة البحث عن أفضل Model واحد.
الفكرة الأقوى أصبحت:
مين أفضل Model لكل مهمة؟
ثم:
إزاي أخليهم يشتغلوا مع بعض؟
Delegate Skills بتحاول تحل النقطة دي عن طريق تحويل نموذج رئيسي إلى Orchestrator، وتوزيع التنفيذ على مجموعة من AI Agents مع Review واضح قبل اعتماد النتيجة. وده ممكن يخلي اشتراكاتك المختلفة أكثر فائدة بدل ما تستخدمها كأدوات منفصلة. LinkedIn
الفيديو الأصلي:
شاهد الفيديو على YouTube
ولو المقال ده لـCodex Academy، فأنا أخلّي الـCTA في الآخر:
في Codex Academy بنتعلم إزاي نستخدم أدوات الذكاء الاصطناعي كجزء من Workflow حقيقي لتطوير المشاريع، مش مجرد كتابة Prompts. تابع الأكاديمية للمزيد من الشروحات العملية عن Vibe Coding وAI Agents وأدوات البرمجة الحديثة.