مشكلاتك موجودة بالفعل في GitHub. وكذلك الكود، ومراجعة طلبات السحب، وقواعد الفروع التي قضى فريقك ربع سنة في الاتفاق عليها. لا أحد يريد لوحة ثانية يحرص على بقائها متزامنة مع الأولى. ما ينقصك هو طريقة لتسليم إحدى هذه المشكلات إلى Agent برمجي واستعادة طلب سحب قابل للمراجعة، من دون مغادرة المستودع الذي جاءت منه.
وهذا بالضبط ما يفعله ربط GitHub بـ Sharkly. فـ Sharkly منصة شاملة لإدارة الـ Agents والتحكم بها: تحوّل مشكلة GitHub إلى Task قابلة للإسناد، وتوجّهها إلى Agent برمجي (Claude Code أو Codex أو Gemini أو أي Runtime يشغّله فريقك)، وتنفّذ العمل على Computer داخل worktree معزول، ثم تعيد النتيجة على هيئة طلب سحب تراجعه بالطريقة المعتادة. وهناك أمران يحملان أهمية قصوى هنا: من يملك فعلًا صلاحية لمس المستودع، وأين يبقى على الإنسان أن يقول «نعم».
الحلقة كاملة في جملة واحدة
اربط GitHub، واربط مستودعًا بـ Space، وستتحول المشكلة الجديدة إلى Task. أسنِدها إلى Agent، ويسري العقد نفسه في كل مكان داخل Sharkly: الـ Agent يبحث وينفّذ ويختبر ويرفع تقريره؛ وشخص بشري يراجع الفروقات ويقرر ما الذي يُطلق.
اتصالان، ولماذا لا يعني أحدهما الآخر
لتكامل GitHub طبقتان، والخلط بينهما هو أسرع طريق إلى الحيرة بشأن من يمكنه رؤية ماذا.
الطبقة الأولى هي اتصال المؤسسة (Organization). يفتح مالك المؤسسة أو المشرف قسم Integrations، ويجد GitHub، ويثبّت تطبيق GitHub على المستودعات التي ينبغي أن يراها. هذا الاتصال هو ما يجعل ربط طلبات السحب وتعليقات linkback ممكنًا. ويمكن للأعضاء أيضًا ربط حساب GitHub شخصي، لكن ذلك لا يغيّر سوى هوية من تظهر أسماؤهم على التعليقات المتزامنة، لا ما يفعله اتصال المؤسسة أصلًا.
الطبقة الثانية هي ربط أحد هذه المستودعات بـ Space. وبمجرد ذلك، تبدأ مشكلات GitHub الجديدة بالظهور كـ Tasks؛ أما المشكلات القائمة فلا تُستورد. ويمكن للمستودع أن يغذّي الـ Space في اتجاه واحد (تدخل تغييرات المشكلات ولا تعود أبدًا) أو في الاتجاهين (تبقى المشكلات والـ Tasks متزامنة في كلا الاتجاهين)، ولا يحصل الـ Space إلا على مستودع واحد ثنائي الاتجاه في المرة الواحدة، فاختر بعناية.
وهنا الحد الذي يوقع كثيرين في الالتباس: لا شيء من هذا هو ما يمنح الـ Agent صلاحية استنساخ الكود الخاص بك. فتكامل GitHub يغطي روابط طلبات السحب، ومزامنة المشكلات، وتعليقات linkback. لكنه لا يمنح أي Agent صلاحية القراءة أو الكتابة على أي مستودع.
امنح الـ Agent صلاحية الوصول إلى الكود بشكل منفصل
الوصول إلى الكود إعداد منفصل يُضبط على الـ Agent أو على الـ Space، لا على اتصال GitHub. وأي Agent لا يملك مستودعات خاصة به يعود إلى ما هو مضبوط على الـ Space الذي تتبعه الـ Task. قلّص هذه القائمة على الـ Agent نفسه عندما يجب ألا يلمس سوى قاعدة كود واحدة من بين عدة قواعد يشير إليها الـ Space.
وفي كلتا الحالتين، لا يزال التشغيل بحاجة إلى وصول Git عامل على الـ Computer نفسه: مفتاح SSH، أو رمز HTTPS، أو بيانات اعتماد المضيف المُعدّة مسبقًا هناك. فاتصال المؤسسة لا يوفّر هذه الأشياء ولا يحل محل أي منها. وإذا فشل التشغيل في الاستنساخ، فالمشكلة في الـ Computer لا في إعداد تطبيق GitHub.
أسنِد المشكلة إلى Agent
بمجرد ربط المستودع، تصل مشكلة GitHub الجديدة كـ Task (وIssue وBug وFeature وTicket كلها أنواع مهام صالحة، أيًّا كان ما يستخدمه الـ Space لديك). وإسنادها إلى Agent يجري بالطريقة نفسها التي تُسند بها إلى أحد أعضاء الفريق: افتح أداة Assignee واختر الـ Agent بدلًا من الشخص.
الـ Agent إعداد عمل محفوظ، وليس أمرًا لمرة واحدة: فتعليماته وRuntime والمستودعات وإعدادات التشغيل الخاصة به تصوغ العمل، كما يصوغ الوصف الوظيفي ما يفعله الموظف الجديد. وإذا وصلت الـ Task إلى Backlog فلن يُنفَّذ شيء بعد؛ فهي مجرد ساحة انتظار. انقلها إلى حالة عمل، وعندئذٍ يُطلق Sharkly التشغيل بمجرد أن يصبح الـ Computer والـ Runtime جاهزين.
عندما يعمل Agentان على المستودع نفسه
هذا هو الجزء الذي يقلق الفرق أكثر من غيره. الوضع الافتراضي هو Temporary: تحصل كل Task على مجلد معزول، وتُهيّئ عمليات التشغيل المرتبطة بمستودع worktree جديدًا. وعندما يعمل Agentان على مشكلتين مختلفتين في المستودع نفسه، يحصل كل منهما على نسخة مستقلة خاصة به لا نسخة مشتركة، فلا يستطيع أحدهما أن يطمس ملفات الآخر أو يتنازع معه على فرع، حتى على الـ Computer نفسه. إنه الانضباط نفسه الذي يقوم عليه استخدام git worktrees مع وكلاء البرمجة بالذكاء الاصطناعي يدويًا، لكنه تلقائي هنا.
وللتزامن (concurrency) سقف خاص به. فتشغيلات Temporary تبدأ افتراضيًا عند نحو نصف الحد الإجمالي للـ Computer؛ وإذا رفعته يدويًا، ينبّهك المنتج بمجرد أن يتجاوز الرقم سعة المجلدات المتاحة، وهنا تبدأ التصادمات فعليًا. وهناك أيضًا وضع Specified، حيث يعيد الـ Agent استخدام مجلد ثابت واحد بدلًا من worktree جديد، لكنه يخدم تشغيلًا واحدًا في كل مرة، ما يجعله أقل ملاءمة لمستودع تعمل عليه عدة Agents في وقت واحد.
ما الذي يعود إليك: طلب السحب
عندما يفتح الـ Agent طلب سحب، تربطه بالـ Task بكتابة معرّف الـ Task في اسم الفرع أو العنوان أو النص. وأي واحد من الثلاثة يكفي؛ فمعرّف مجرّد مثل SH-312 يعمل تمامًا مثل Fixes SH-312، إذ لا توجد معالجة خاصة لكلمات مثل fixes أو closes أو skip. وفي المستودع العام، لا يُربط إلا مؤلف موثوق، مالكًا كان أو عضوًا أو متعاونًا، حتى لا ينتحل طلب سحب من شخص غريب طريقه إلى الـ Task الخاصة بك.
ويمكن لطلبات السحب المرتبطة أن تحصل أيضًا على تعليق linkback يشير عائدًا إلى الـ Task. وهذا الخيار مُفعّل افتراضيًا في المستودعات الخاصة ومُعطّل افتراضيًا في المستودعات العامة، والمفتاح موجود في إعدادات GitHub، منفصلًا عن كون الـ Space نفسه عامًا أو خاصًا.
بوابة المراجعة: حيث يقع قرار الحكم
دمج طلب السحب لا يغيّر حالة الـ Task، ولا يحدث من تلقاء نفسه أبدًا. وهذا أمر مقصود. فحالة الـ Task وحالة عمل الـ Agent تُتابعان بشكل منفصل، لذا يمكن أن تظهر الـ Task في حالة Started وأيضًا Working أو Waiting for human reply أو Waiting for human review أو Error، وتظهر هذه المؤشرات في Inbox لمن يهمه الأمر. ويمكن لإغلاق مشكلة GitHub الأصلية أو إعادة فتحها أن يحرّك حالة Task مرتبطة ثنائيًا؛ أما دمج طلب السحب فلا يستطيع ذلك.
الـ Agents تبحث وتنفّذ وتختبر وترفع تقاريرها. أما البشر فيقرؤون الفروقات مقابل المشكلة الأصلية، ويطلبون تعديلات أو يقبلونها، ويتخذون قرار الدمج والإصدار بأنفسهم. وهذا التقسيم قائم من البداية إلى النهاية، على GitHub تمامًا كما في بقية Sharkly: تتوقف الأتمتة عند النقطة التي يلزم فيها حكم الفريق بالضبط. ولمزيد من التفاصيل التقنية، يغطي مسار المراجعة بمشاركة العنصر البشري في Sharkly هذه النقطة مباشرة.
متى يكون Agent HQ من GitHub كافيًا؟
إذا كان فريقك يعتمد على GitHub بالكامل — المصدر، وCI، والمراجعة، ومقعد Copilot مدفوع — فإن Agent HQ من GitHub ينسّق الـ Agents داخل تلك المنظومة جيدًا، وقد لا تحتاج إلى أي شيء آخر. أما حجة Sharkly فتظهر عندما يمرّ العمل أيضًا عبر Jira، أو عندما تعمل الـ Agents على Computers خارج سحابة GitHub، أو عندما يمزج فريقك بين عدة Runtimes ولا يريد إعادة بناء مسار عمله كلما تغيّر أفضل خيار منها. وإذا كان Jira جزءًا من هذه الخلطة، فإن إسناد تذكرة Jira إلى وكيل ذكاء اصطناعي يسير في الحلقة نفسها انطلاقًا من تلك الجهة.
لتجربتها على مشكلة حقيقية واحدة: افتح تكاملات Sharkly مع GitHub وJira وSlack، واربط مؤسستك على GitHub، ثم اربط مستودعًا واحدًا قليل الحركة بـ Space، وأسنِد المشكلة الصغيرة التالية إلى Agent بدلًا من نفسك.
الأسئلة الشائعة
هل يمنح ربط مؤسستي على GitHub أي Agent صلاحية الوصول إلى الكود؟ لا. فاتصال المؤسسة يغطي روابط طلبات السحب، ومزامنة المشكلات، وتعليقات linkback. أما الوصول إلى الكود فيُضبط بشكل منفصل على الـ Agent أو على الـ Space، ولا يزال التشغيل بحاجة إلى بيانات اعتماد Git خاصة به على الـ Computer.
هل يمكن أن يتصادم Agentان يعملان على المستودع نفسه؟ لا في الوضع الافتراضي Temporary. فكل تشغيل يحصل على worktree معزول خاص به، لذا لا تتشارك الـ Agents المتزامنة أي نسخة عمل، حتى على الـ Computer نفسه.
هل يؤدي دمج طلب السحب إلى إغلاق مشكلة GitHub أو الـ Task؟ الدمج لا يغيّر حالة الـ Task بمفرده أبدًا. لكن إغلاق مشكلة GitHub الأصلية قد يفعل ذلك في مستودع متزامن في الاتجاهين، وهو إجراء منفصل عن دمج طلب السحب.
ما الفرع الذي يستهدفه طلب السحب الخاص بالـ Agent فعلًا؟ يربط Sharkly طلب السحب عبر معرّف الـ Task في الفرع أو العنوان أو النص، أيًّا كان ما يكتبه الـ Runtime لديك. وهو لا يفرض استراتيجية فروع محددة، لذا تأكد من سلوك الفرع الأساسي الافتراضي في الـ Runtime قبل إسناد أي شيء أعلى مخاطرة من مشكلة تجريبية.
هل يمكنني الاحتفاظ بمشكلات GitHub الحالية، وليس الجديدة فقط؟ ربط المستودع يزامن المشكلات المنشأة حديثًا من تلك اللحظة فصاعدًا. أما المشكلات الحالية فلا تُستورد تلقائيًا.
