Agent Teams.
فريق تقني حقيقي، مكتوب مسبقًا.

Claude subagents هي تفويضات مضمّنة من جلسة Claude واحدة. الجلسة الأب تقرر متى تستدعي subagent، يعمل subagent في نافذة سياق معزولة، يعيد نتيجة، وتستمر الجلسة الأب. AgentsRoom Teams مستوى أعلى: كل عقدة هي جلسة Claude Code على المستوى الأعلى بطرفيتها وحالتها وسجلها الخاص. ترى كل وكيل يعمل مباشرة في علامة تبويبه، يمكنك التحدث إلى أي منهم في أي لحظة، يمكنك إيقاف الفريق، تغيير سير العمل ثم المتابعة. ليست بديلًا عن Claude subagents، يمكنك استخدام كليهما تمامًا. عقدة فريق يمكن أن تستخدم subagents داخليًا.

يعمل مع كل أدوات CLI الوكلاء الـ 14 التي يدعمها AgentsRoom (Claude Code وCodex CLI وGitHub Copilot CLI وCursor و10 أخرى). كل عقدة فريق تختار مزوّدها ونموذجها. أدوات تنسيق الفريق المعتمدة على MCP تعمل بشكل متطابق عبر المزوّدين لأنها مكشوفة عبر Model Context Protocol القياسي. يمكنك تشغيل فريق مع Codex على عقدة backend الثقيلة وHaiku على عقدة QA إذا كان ذلك يناسب ميزانيتك وزمن استجابتك.

كائن منظم ينتقل من وكيل إلى التالي. الحقول: featureSummary (وصف قصير لما تم شحنه)، changedFiles (git diff name-status)، touchedAreas (UI وAPI وDB وconfig)، risks (أي شيء يجب أن يقلق منه الوكيل التالي)، testHints (أولويات لـ QA)، flags (قيم بوليانية مثل qaPassed، تستخدمها الحواف الشرطية). يستدعي الوكيل team_complete_step بهذه الحمولة، يتحقق منها المشغّل على الخادم، ويستقبلها الوكيل التالي كسياق ابتدائي.

نعم. عند إعادة دخول عقدة (دورة أكبر من 1)، لا يُطلق AgentsRoom وكيلًا جديدًا. يُعيد استخدام وكيل الدورة الأصلية الأول، يكتب حمولة التسليم الجديدة مباشرة في طرفيته الموجودة، ويحتفظ الوكيل بكامل ذاكرة جلسة Claude للدورات السابقة. هذا حاسم: وكيل Dev يعرف فعلًا ما حدده QA المرة الماضية يصلح الخطأ. وكيل Dev جديد بدون ذاكرة سيكرر الخطأ نفسه فقط.

تكوين الفريق لديه حدّ أقصى للدورات، افتراضي 3. عند الوصول إلى الحدّ، يتوقف التشغيل بحالة 'blocked' وينتظرك. يمكنك اعتماد التشغيل، أو التسليم يدويًا مرة أخرى، أو إلغاء كل شيء. لا حلقات لانهائية، ولا فواتير ليلية مفاجئة.

نعم. يعمل الفريق في مساحة عمل واحدة وفرع واحد (أو worktree إذا استخدمت ميزة AgentsRoom Worktrees). يرى كل وكيل عمل السابق عبر git. تتضمن حمولة التسليم git diff مقابل خط أساس التشغيل ليعرف الوكيل التالي بالضبط ما هو جديد.

لا. Teams جزء من AgentsRoom. تحضر مفاتيح المزوّد الخاصة بك (Claude وCodex وGitHub Copilot CLI وCursor و10 أدوات CLI أخرى للوكلاء) وتدفع فقط مقابل التوكنز التي تستخدمها، كما هو الحال مع وكيل واحد. تشغيل فريق Dev إلى QA على تذكرة صغيرة يكلّف عادةً نفس تشغيل وكيل Fullstack منفرد، لأن Haiku/Sonnet على خطوة QA رخيص.

فرق المشروع تعيش مع الغرفة، متزامنة مع حسابك ومخزنة في {project}/.agentsroom/teams-cache.json (ضمن gitignore). الفرق العامة متزامنة مع حسابك أيضاً: مكتبتك تتبعك من جهاز لآخر، مع ~/.agentsroom/teams/ ذاكرة تخزين دون اتصال. القوالب المضمنة تبقى محلية: كل جهاز يثبتها بلغته.

تُحفظ حالة التشغيل على القرص في {workspace}/.agentsroom/team-runs/{runId}/ (state.json و NOTES.md و inbox/ و timeline.jsonl)، بكتابات ذرّية وملاحظات بالإلحاق فقط. يُستأنف التشغيل المقطوع عند إعادة تشغيل التطبيق: يدخل المنسق الخطوة النشطة من جديد، يعيد فتح الطرفية، ويستعيد الوكيل سياقه من الملاحظات وأدوات الفريق. التشغيل الذي حُذف فريقه يُغلق تلقائياً بدل أن يبقى معلقاً إلى الأبد.

نعم. كل تشغيل مستقل ويعرَّف بـ runId. يمكنك تشغيل ثلاثة فرق مختلفة على ثلاث تذاكر في المشروع نفسه. داخل التشغيل الواحد يتبع التنفيذ مخططك: تسلسلي افتراضياً، متوازٍ حيث ترسم فروعاً متوازية (مثل QA و Security يراجعان معاً)، ودائماً بالتقاء حتمي.

نعم. ارسم رابطين بلا شرط من عقدة واحدة فيعمل الهدفان كفرعين متوازيين، كل في وكيله وطرفيته. عمق الفرع عقدة واحدة ويجب أن تلتقي الفروع في عقدة التقاء مشتركة، وهو ما يتحقق منه المحرر قبل السماح بالتشغيل. عند اكتمال كل الفروع تتلقى عقدة الالتقاء حمولة مدمجة واحدة: ملخصات موسومة بالدور، ومخاطر وتلميحات اختبار بلا تكرار، وعلامات مدموجة بقاعدة أمان (يُحسم التعارض المنطقي إلى false).

تكتب أمر shell على العقدة، مثلاً npm test، واختيارياً اسم علامة (checkPassed افتراضياً). عندما يعلن الوكيل انتهاء خطوته ينفذ AgentsRoom الأمر في مساحة العمل بسقف خمس دقائق. رمز الخروج 0 يكتب true في العلامة، وأي رمز آخر يكتب false متجاوزاً ما صرّح به الوكيل عن نفسه. عند الفشل تنتقل آخر كيلوبايتات من الخرج إلى الوكيل التالي: تهبط العودة ومعها تتبع المكدس الحقيقي، وتظهر النتيجة في الخط الزمني للتشغيل.

نعم. يمكن لكل عقدة تثبيت مهارات من Skills Library لديك، للمشروع أو عامة. يُطلب من الوكيل تحميل كل منها قبل بدء الخطوة: قائمة مراجعة أو دليل نشر أو إجراء اختبار يطبَّق في كل تشغيل، بدل الاعتماد على ذاكرة الوكيل.

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

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

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

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

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

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

نعم، وهذا هو الافتراضي. مع تعطيل المحادثة الحرة، لا يكتب الزميل إلا للأدوار التي تشير إليها عقدته في المخطط، فلا يمكن الالتفاف على بوابة جودة بسؤال طرف آخر. فعّلها حين تريد فريقًا حقيقيًا : كل واحد يكتب لأي واحد، في أي اتجاه، ولعدة زملاء في آنٍ واحد. وفي الحالتين يظل المخطط هو من يبدأ التشغيل ومن ينهيه.