التذكرة مكتوبة بالفعل. لها عنوان ووصف ومعايير قبول ومكان في السبرنت. والشيء الوحيد الذي يفصلها عن أن تصبح تعديلًا برمجيًا فعليًا هو شخص يفتح الطرفية، ويلصق التذكرة في وكيل برمجة، ويراقب التنفيذ، ثم ينسخ النتيجة يدويًا إلى Jira. العمل وسجل العمل يعيشان في نافذتين مختلفتين، وإبقاء الاثنين متزامنين يستهلك بعد ظهر أحدهم بالكامل.
إسناد تذكرة Jira إلى وكيل ذكاء اصطناعي يعني إغلاق هذه الفجوة: تتحول المشكلة إلى وحدة عمل يستطيع الوكيل التقاطها وتنفيذها على مستودعك وإعادتها كتغيير قابل للمراجعة، دون مغادرة أداة التتبع التي يعمل عليها فريقك بالفعل. أنت لا تنقل الفريق بعيدًا عن Jira، بل تضيف طبقة يمكن أن يُنفَّذ فيها العمل فعليًا.
تلك الطبقة هي Sharkly، منصة متكاملة لإدارة الوكلاء وإصدار الأوامر لهم. تتصل بـ Jira، وتحوّل المشكلات إلى مهام (Tasks) قابلة للإسناد، وتوجّهها إلى وكلاء البرمجة لديك (Claude Code وCodex وGemini وغيرها من أدوات سطر الأوامر)، وتشغّل كل وكيل في بيئة معزولة، ثم تعيد النتيجة إلى المهمة. يشرح هذا الدليل الحلقة كاملة: تذكرة تدخل، ووكيل يُسند إليها، وعمل يُنفَّذ في worktree معزول، وطلب سحب ونقاش يعودان إلى السجل.
الحلقة كاملة في جملة واحدة
مهمة Sharkly هي السجل المشترك لأي قطعة عمل، وعند ربط Jira تتحول كل مشكلة في Jira إلى إحدى هذه المهام. ومن هنا تصبح القاعدة بسيطة: الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون تقاريرهم؛ أما البشر فيحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وما تبقّى من هذا المقال ليس سوى تفاصيل هذه القاعدة.
أبقِ Jira، وأضف طبقة التنفيذ
Sharkly ليست بديلًا عن Jira. إنها تضيف المهمة المشتركة، والجهاز المتصل (Computer)، وطبقة التنفيذ والمراجعة حول أداة التتبع التي يستخدمها فريقك بالفعل. لا حاجة لأي شخص أن يتعلم لوحة جديدة أو ينقل تراكم المهام (backlog) للبدء.
تربط بينهما عبر رابط مزامنة. افتح تكامل Jira، واربط الحساب (يستخدم Jira Cloud مضيف *.atlassian.net وبريد الحساب ورمز Atlassian API؛ أما Server وData Center فيستخدمان عنوان URL الأساسي واسم المستخدم ورمز وصول شخصي)، ثم اقرن مشروع Jira واحدًا بمساحة Sharkly واحدة. أما التعيينات الأساسية فهي كما تتوقع:
- مشكلة Jira تتحول إلى مهمة Sharkly
- ملحمة (epic) Jira تتحول إلى مشروع Sharkly
- المُكلَّف بالعمل والحالة والتعليقات والمرفقات تنتقل معها
وهذا هو الاختيار الحقيقي بين أمرين. استخدم المزامنة عندما تريد أن يبقى مشروع حي متصلًا، بحيث تتدفق التغييرات بين Jira وSharkly من هذه اللحظة فصاعدًا. واستخدم الاستيراد عندما تريد نسخ المشكلات التاريخية لأغراض ترحيل محكوم؛ فالمزامنة وحدها لا تستعيد ماضي المشروع. معظم الفرق في البداية تريد رابط مزامنة ثنائي الاتجاه على مشروع نشط واحد ولا شيء أكثر. الإعداد الكامل، بما في ذلك خطوة الـ webhook التي يتولاها مسؤول Jira مرة واحدة، موجود في وثائق Sharkly.
أسنِد التذكرة إلى وكيل
بمجرد ربط المشروع، تظهر المشكلة كمهمة في المساحة. وإسنادها إلى وكيل يتم بالطريقة نفسها التي تُسند بها إلى زميل: تختار الوكيل بدلًا من الشخص.
الوكيل أكثر من مجرد اختيار نموذج. فتعليماته وبيئة التشغيل (Runtime) ومستودعاته وإعدادات تشغيله تحدد كيف يتعامل مع العمل، تمامًا كما يشكّل الوصف الوظيفي ما يفعله الموظف الجديد. بيئة التشغيل هي المحرك الأساسي: Claude Code أو Codex أو أي وكيل يعمل بسطر الأوامر يستخدمه فريقك بالفعل. ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيأة في تلك الأدوات، فيبقى وصولك إلى الوكلاء وشيفرتك على عتادك الخاص. Sharkly تنسّق الإسناد، لكنها لا تتولى حفظ بيانات اعتمادك.
إن كانت هذه أول تجربة لك، فأبقِ النطاق صغيرًا والحدود واضحة. فكتابة مهمة يستطيع الوكيل تنفيذها فعليًا مهارة قائمة بذاتها، ويستحق الأمر إتقانها قبل أن توجّه وكيلًا إلى أي شيء حساس. التذكرة المحكمة ذات تعريف الإنجاز الواضح تُنتج تعديلًا محكمًا؛ والتذكرة الغامضة تُنتج تعديلًا غامضًا.
التنفيذ داخل worktree معزول
عندما يبدأ الوكيل، يجري التشغيل على جهاز متصل (Computer) داخل worktree معزول خاص به. هذا العزل هو ما يجعل تكرار الأمر آمنًا. فكل تشغيل يحصل على دليل عمل جديد تمامًا، بحيث لا يكتب وكيلان يعملان على تذكرتين في المستودع نفسه فوق ملفات بعضهما، ولا يتنازعان على فرع (branch). إنه الانضباط نفسه الذي تطبقه يدويًا مع git worktrees لوكلاء البرمجة بالذكاء الاصطناعي، لكنه يُدار عنك وقابل للتكرار في كل مهمة.
وهذا أيضًا ما يسمح لسير العمل بالتوسع لما هو أبعد من تذكرة واحدة. فبمجرد أن يصبح العزل تلقائيًا، يتوقف تشغيل عدة وكلاء بالتوازي عن كونه عملية موازنة صعبة، لأن العامل الذي يسبب الانهيار عادةً (الحالة المشتركة على القرص) مُستبعَد بالتصميم. وإن كنت جديدًا على هذا النموذج كله، فإن إسناد مهمتك الأولى إلى وكيل ذكاء اصطناعي هو المدخل الألطف قبل أن تربط Jira.
أعِد طلب السحب (PR) إلى السجل
يعود عمل الوكيل إلى المهمة: المحادثة وسجلات التنفيذ والعقبات والتغيير الناتج كلها تصل إلى مكان واحد بدلًا من التشتت بين الطرفية وخيط محادثة. وعندما يفتح الوكيل طلب سحب، تربطه بالمهمة بكتابة معرّف المهمة (Task ID) في اسم الفرع أو عنوان طلب السحب أو نصه. يلتقط تكامل Sharkly مع GitHub هذا المعرّف، ويربط طلب السحب بالمهمة، ويمكنه ترك تعليق برابط عكسي حتى يستطيع أي شخص في التذكرة الانتقال مباشرة إلى الشيفرة.
ولأن رابط المزامنة مع Jira ثنائي الاتجاه، يستمر هذا النشاط في التدفق نحو المشكلة الأصلية أيضًا. فيرى من أنشأ التذكرة العمل يتقدّم دون أن يفتح طرفية واحدة. وهذه هي الثمرة الحقيقية لتوجيه العمل عبر مهمة مشتركة بدلًا من أمر خاص (prompt): السياق والتقدم والعقبات والنتائج والمراجعة كلها تبقى ظاهرة من الطلب حتى الإصدار.
الحد الصريح: الإنسان هو من يقبل
لا شيء يُدمج من تلقاء نفسه. هذا مقصود، ويستحق التوضيح صراحةً لأن القارئ قد يفترض العكس: دمج طلب سحب لا يغيّر حالة المهمة، ولا يحدث تلقائيًا أبدًا. الأتمتة تتوقف حيث يلزم حكم الفريق.
ويستمر تقسيم العمل هذا حتى النهاية. يشغّل الوكيل العمل، ويفتح طلب السحب، ويقدّم تقريرًا بما فعله وما تحقق منه وأين يشك. ثم يقرأ شخص التعديل مقابل معايير القبول الأصلية، ويطلب تغييرات أو يقبل، ويتخذ قرار الدمج والإصدار. الوكيل سيملأ الصمت بمبادرات من عنده بكل سرور، لذا فإن خطوة المراجعة ليست شكليات؛ إنها الضابط الذي يجعل الجزء التلقائي جديرًا بالثقة. أما قرارات القبول النهائي والإصدار فتبقى بيد البشر.
تلك هي الحلقة كاملة. تدخل تذكرة Jira، فيلتقطها وكيل، ويُنفَّذ العمل في عزلة ثم يعود إلى السجل كطلب سحب يمكنك قراءته، ثم تقرر أنت ما إذا كان سيُصدَر. ولمنظر أوسع لكيفية انسجام هذا مع فريق من الوكلاء لا مع تشغيل واحد، راجع ما تعنيه تنسيق وكلاء الذكاء الاصطناعي لفرق التطوير، أو نظرة عامة على Sharkly للمنصة بأكملها.
لتجربته على تذكرة حقيقية واحدة: نزّل Sharkly، وسجّل الدخول على app.sharkly.ai، واربط جهازًا (Computer)، واربط مشروع Jira واحدًا منخفض المخاطر.
الأسئلة الشائعة
هل تحل Sharkly محل Jira؟ لا. تضيف Sharkly طبقة التنفيذ والمراجعة حول Jira. تبقى مشكلاتك وملاحمك وحالاتك وسير عملك كما هي؛ ويحافظ رابط المزامنة على اتصالها بينما يدفع الوكلاء العمل إلى الأمام.
ما إصدارات Jira المدعومة؟ كلاهما. يتصل Jira Cloud عبر المضيف وبريد الحساب ورمز Atlassian API. ويتصل Jira Server وData Center عبر عنوان URL الأساسي واسم المستخدم ورمز وصول شخصي.
هل يجب أن أُرحّل تراكم المهام أولًا؟ لا. يربط رابط المزامنة مشروعًا حيًا ويُبقي التغييرات المستقبلية متدفقة دون استيراد السجل. لا تُجرِ استيرادًا منفصلًا إلا عندما تريد تحديدًا نسخ المشكلات السابقة.
هل سيؤدي دمج طلب السحب إلى إغلاق التذكرة؟ لا. دمج طلب السحب لا يغيّر حالة المهمة، بحكم التصميم. يقبل شخص النتيجة ويقرر خطوة الدمج والإصدار. راجع إسناد مهمتك الأولى إلى وكيل ذكاء اصطناعي لمعرفة كيفية عمل حلقة المراجعة.
أين توجد شيفرتي وإمكانية الوصول إلى النماذج؟ على عتادك الخاص. يعمل الوكلاء على جهاز تتصل به، باستخدام الاشتراكات أو مفاتيح API المهيأة مسبقًا في أدوات البرمجة لديك. تنسّق Sharkly الإسناد والسياق والمراجعة؛ لكنها لا تستضيف مستودعك ولا حصتك من النماذج.
