إدارة مشاريع Claude Code: من المشكلة إلى المراجعة

Claude Code أداة برمجة وكيلية (agentic) تقرأ قاعدة الشيفرة لديك، وتعدّل الملفات، وتنفّذ الأوامر، وتتعامل مباشرة مع git. وبالنسبة لمطوّر واحد في طرفية واحدة، فهي لا تحتاج إلى أي إدارة على الإطلاق: تصف العمل، وتراقبه وهو يحدث، وتراجع الـ diff. تلك الحلقة سريعة، ولا شيء في هذا الدليل يطلب منك التخلي عنها.

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

إدارة مشاريع Claude Code هي ممارسة إدارة هذا العمل كعمل مشروع مُتتبَّع وقابل للمراجعة: تتحول المشكلة (issue) إلى مهمة (Task) محددة النطاق، وتُسنَد المهمة إلى وكيل (Agent) ينفّذ عبر Claude Code، ويجري التنفيذ في worktree معزول على جهاز تتحكم به، ثم تعود النتيجة إلى إنسان للمراجعة. يستعرض هذا الدليل هذا المسار باستخدام Sharkly، وهي ليست بديلًا عن Claude Code. إنها تضيف طبقة المهام والسياق والتحكم والمراجعة المشتركة حول الأداة التي يستخدمها فريقك بالفعل.

باختصار (TL;DR)

لإدارة عمل Claude Code كعمل مشروع، اكتب المشكلة على هيئة مهمة (Task) محددة النطاق لها هدف وحدود ومعايير قبول؛ وأسنِدها إلى وكيل (Agent) تكون بيئة تشغيله (Runtime) هي Claude Code؛ ودَع التنفيذ يجري على حاسوب (Computer) متصل داخل git worktree معزول مع بثّ التقدّم لحظيًا؛ ثم راجع الأدلة على المهمة واقبل العمل أو اطلب تعديلات أو أعد الإسناد. Claude Code ينفّذ. أما Sharkly فتدير الإسناد والسياق والتقدّم والعوائق والنتائج والمراجعة البشرية حوله، لتبقى التنفيذات المتوازية مرئية للفريق بأكمله بدل أن تختفي في طرفيات خاصة. وتبقى الجلسات الفردية في الطرفية الأداة المناسبة للأعمال السريعة والمحلية منخفضة المخاطر.

ما الذي تضيفه المهمة المُدارة إلى جلسة Claude Code الخام

الجلسة الخام والمهمة المُدارة تشغّلان Claude Code نفسه في العمق. الفرق في كل ما يحيط بالتنفيذ، وهو يقع في أربع قدرات لا تستطيع الطرفية توفيرها.

رؤية مشتركة. تحفظ المهمة المتطلبات وحالة المهمة والنقاش وسجلات التنفيذ والمراجعة في مكان واحد بدلًا من تفريقها بين مطالبات وجلسات خاصة. يمكن لزميل أن يفتح SH-214 فيرى ما طُلب، وما يجري تنفيذه، وما عاد من نتائج.

تحديد المسؤولية. تفصل المهمة بين مسؤولية الإنسان وتنفيذ الوكيل. الإنسان مسؤول عن النتيجة، والوكيل أو الطاقم (Crew) هو المُسنَد إليه التنفيذ. ويُسجَّل الاثنان، فيكون لسؤال «من المسؤول عن هذا؟» جواب دائم.

أدلة المراجعة. ينتج كل تنفيذ أثرًا تنفيذيًا (execution trace): متى بدأ، وما الأدوات التي استدعاها، ولماذا انتظر في قائمة الانتظار، وكيف انتهى. ويُحفظ تقرير الوكيل كتعليق مرتبط بذلك الأثر. فتصبح المراجعة «قراءة السجل» بدل «الثقة بمن تصادف أنه كان يراقب الطرفية».

تنفيذات متوازية بلا تصادم. تحصل كل مهمة على دليل معزول، ويمكن للعمل المرتبط بمستودع أن يستخدم git worktree منفصلًا لكل تنفيذ، فيمكن لعدة مهام تعديل قاعدة الشيفرة نفسها في الوقت ذاته. وللآلية المتوازية دليلها الخاص: كيفية تشغيل عدة وكلاء Claude Code بالتوازي.

حدّ صادق واحد قبل الشرح التفصيلي. ليست كل جلسة Claude Code بحاجة إلى هذا. استخدم محادثة وكيل مستقلة (Agent Chat) أو جلسة طرفية عادية لاستكشاف سؤال، أو رسم خطة، أو إجراء تعديل محلي سريع. واستخدم المهمة (Task) عندما يحتاج العمل إلى مسؤولية أو حالة أو سجل تنفيذ أو مراجعة.

الخطوة 1: حوّل المشكلة إلى مهمة يستطيع الوكيل تنفيذها

يبدأ المسار قبل تشغيل أي وكيل. يضع Claude Code خطة للنهج انطلاقًا مما تعطيه إياه، لذا فمهمة غامضة تُنتج تنفيذًا واثقًا في الاتجاه الخطأ.

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

البند الأخير تحديدًا هو ما تتجاهله أساليب العمل الفردية. كتابة «الإنجاز يعني أن منطق إعادة المحاولة صار له اختبار يفشل مع السلوك القديم» في الوصف تمنح المراجع قائمة تحقق وتمنح الوكيل هدفًا. أبقِ الهدف الثابت والنطاق ومعايير القبول في الوصف، واستخدم التعليقات للنقاش.

وفئة الحالة مهمة هنا أيضًا: المهمة الموجودة في Backlog متوقفة، وإسناد وكيل إليها لا يبدأ التنفيذ. وهذه ميزة. يمكنك تجهيز دفعة من المهام، وإسنادها كلها، ثم إطلاق كل واحدة عن قصد بإخراجها من Backlog عندما تصبح جاهزة.

وإذا كانت مشكلاتك موجودة بالفعل في مكان آخر، فلست مضطرًا لإعادة بناء سير عملك. تشمل تكاملات Sharkly كلا من Jira وSlack وGitHub، فتبقى أدوات التتبع الحالية في مكانها بينما يصبح التنفيذ قابلًا للإسناد والتتبع. وانتظام كتابة أعمال يستطيع الوكلاء تنفيذها جزء من تحوّل أوسع نتناوله في ما هي البرمجة الوكيلية.

الخطوة 2: أسنِدها إلى وكيل تكون بيئة تشغيله Claude Code

في Sharkly، لا تُسند العمل إلى Claude Code مباشرة، بل تُسنده إلى وكيل، وبيئة تشغيل (Runtime) ذلك الوكيل هي Claude Code. وهذا التمييز له ما يبرره.

الوكيل إعداد عمل محفوظ وليس مطالبة عابرة: تعليماته، وبيئة تشغيله، ومهاراته (Skills)، ومستودعاته، ومتغيرات بيئته، وإعدادات تنفيذه، هي ما يحدد طريقة تعامله مع العمل. يضبط شخص واحد وكيلًا باسم «مصلح الواجهة الخلفية» مرة واحدة، ويشاركه مع المساحة (Space)، فيسند الفريق كله العمل إلى الإعداد المُختبَر نفسه بدل أن يبتكر كل مطوّر مطالباته الخاصة. نفصّل هذا المفهوم كاملًا في الوكلاء في Sharkly، بشرح مبسّط.

بيئة التشغيل هي أداة الوكيل الفعلية المتاحة على حاسوب (Computer). وعند ربط جهاز، تكتشف خدمة محلية صغيرة أدوات الوكلاء المدعومة المثبّتة هناك وتُبلّغ عن كل واحدة منها كبيئة تشغيل؛ فيظهر تثبيت Claude Code كبيئة تشغيل متاحة بمجرد أن ترى الخدمة وجوده.

ثلاث حقائق حول هذا الترتيب تحافظ على توقعات سليمة:

• يتبع الوكيل النموذج الافتراضي لبيئة التشغيل. لا تعرض Sharkly اسم نموذج ولا تعِد به، ولا يوجد في الوكيل منتقي نموذج ولا تحكم في عمق التفكير. ولتغيير النماذج، غيّر الإعداد داخل Claude Code نفسه.
• استخدام النموذج مسؤوليتك الخاصة. تستهلك التنفيذات اشتراك Claude أو مفتاح API المهيّأ مسبقًا في Claude Code على ذلك الحاسوب. وتعتمد حصة النموذج على أدوات البرمجة بالذكاء الاصطناعي والخطط وحسابات API التي يربطها فريقك.
• الإسناد صريح. تفتح عنصر التحكم بالمُسنَد إليه في المهمة وتختار الوكيل، تمامًا كما تُسند تذكرة إلى زميل. ويبقى الشخص المسؤول مسجَّلًا بشكل منفصل.

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

الخطوة 3: التنفيذ على حاسوب، داخل worktree معزول

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

ويجدر ذكر فصل المسؤوليات بوضوح: الوكيل يحدد كيف ينبغي التعامل مع العمل؛ والحاسوب يوفّر المضيف والموارد المحلية؛ وبيئة التشغيل تنفّذ جلسة الوكيل الفعلية؛ وتبقى المهمة هي السجل المشترك.

للعمل على المستودعات، وضع دليل العمل المُوصى به هو «Temporary»: تحصل كل مهمة على دليل معزول، ويمكن للخدمة المحلية تجهيز git worktree جديد لكل تنفيذ من بيانات المستودع المخزّنة مؤقتًا. مهمتان تلمسان المستودع نفسه تكتبان في دليلين مختلفين على القرص، ولهذا لا تتصادم التنفيذات المتوازية. وتُغطّى هذه الأولية في كيفية استخدام git worktrees مع وكلاء البرمجة بالذكاء الاصطناعي. أما وضع «Specified»، وهو دليل محلي واحد مهيّأ تعيد التنفيذات استخدامه، فيوجد للاستثناءات المشروعة: مستودع ضخم جدًا، أو ذاكرات تخزين محلية مكلفة، أو أدوات مرتبطة بمسار واحد.

وأثناء عمل Claude Code، يمرّ التنفيذ بحالات مرئية: في قائمة الانتظار، ثم مُرسَل، ثم قيد التشغيل، ثم مكتمل أو فاشل أو ملغى. وحالة التنفيذ منفصلة عن حالة المهمة، وهذا الفصل مفيد: يمكن أن تبقى المهمة قيد التنفيذ (In Progress) بينما وكيلها يعمل، أو ينتظر ردًّا بشريًا، أو يُبلّغ عن خطأ، دون أن يحتاج أحد إلى مراقبة طرفية ليعرف أيّها يجري.

الخطوة 4: يعود التقدّم والعوائق إلى المهمة

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

تظهر العوائق بدل أن تتعطّل بصمت. يمكن للوكيل أن يترك مهمة في انتظار ردّ بشري أو مراجعة، ويغذّي العمل المتعطّل صندوق الوارد (Inbox)، وهو قائمة الانتظار الشخصية التي تفصل المهام التي تحتاج انتباهك عن التحديثات الأقل أولوية. والفرق بنيوي: الجلسة المتعطلة تنتظر حتى تصادف أن تتفقد التبويب، أما المهمة المتعطلة فتُخبر الشخص المسؤول بأنها متعطلة.

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

الخطوة 5: المراجعة والقبول البشري

ينتهي المسار حيث ينبغي: عند إنسان. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير. أما البشر فيحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة.

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

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

ولا شيء من هذا يحلّ محل مراجعة git لديك. ينشئ Claude Code فروعًا، ويكتب commits، ويفتح طلبات سحب عبر استضافة git المعتادة، وتبقى مراجعة الدمج في مكانها. وتضيف المهمة ما لا تستطيع صفحة طلب السحب رؤيته: الطلب الأصلي، وأدلة التنفيذ، والقبول المسجّل.

الجلسة الفردية مقابل المهمة المُدارة

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

من مهمة واحدة إلى مشروع مُدار

كل ما سبق يتوسّع من مهمة واحدة إلى خطة دون أن يتغير شكله. تتجمّع المهام في مشاريع (Projects) عندما تخدم عدة مهمات نتيجة واحدة، وفي سبرنتات (Sprints) عندما يكون السؤال هو ما الذي سيُسلَّم في هذه الفترة الزمنية. وتحفظ العروض (Views) الأسئلة التي يطرحها الفريق مرارًا، مثل المهام في انتظار المراجعة.

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

ابدأ أصغر مما يبدو ضروريًا. اربط حاسوبًا واحدًا، وتأكد من ظهور Claude Code كبيئة تشغيل متاحة، وأنشئ وكيلًا واحدًا بدور ضيّق، وأسنِد إليه مهمة واحدة منخفضة المخاطر بمعايير قبول حقيقية. وراجع النتيجة كما تراجع أول طلب سحب من زميل جديد. وتغطي وثائق Sharkly كل مفهوم بمزيد من العمق.

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

هل تحل Sharkly محل Claude Code؟

لا. Sharkly ليست بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى. Claude Code يقوم بالتنفيذ: يقرأ قاعدة الشيفرة، ويعدّل الملفات، وينفّذ الأوامر، ويتعامل مع git. أما Sharkly فتضيف الطبقة الخاصة بالفريق حوله، فتدير الإسناد وسياق المهمة والتقدّم والعوائق والنتائج والمراجعة البشرية.

هل أحتاج إلى اشتراك منفصل في النموذج لتشغيل Claude Code عبر Sharkly؟

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

هل ما زال بإمكاني استخدام Claude Code مباشرة في الطرفية؟

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

ماذا يحدث عندما يفشل تنفيذ؟

يُعلَّم التنفيذ كفاشل على المهمة، ويسجّل سجل التنفيذ العنوان مع التفاصيل التقنية الأصلية من خدمة النموذج. وتخطّط إرشادات استكشاف الأخطاء في Sharkly الحالات الشائعة، مثل حدود المعدل ونفاد الحصة وأخطاء المصادقة، إلى خطوات تالية، وتربط بمرجع الأخطاء الخاص بـ Claude Code. أعد المحاولة بعد إصلاح السبب، أو أسنِد المهمة إلى وكيل آخر.

هل يمكن لعدة مهام Claude Code أن تعمل على المستودع نفسه في الوقت ذاته؟

نعم. في وضع دليل العمل «Temporary»، يعمل كل تنفيذ في دليل معزول خاص به، ويمكن للتنفيذات المرتبطة بمستودع أن تحصل كل واحدة على git worktree جديد، فلا تكتب المهام المتزامنة في نسخة عمل مشتركة. وتحدّ حدود التزامن على الوكيل والحاسوب عدد التنفيذات المتزامنة.