أعلنت GitHub يوم 17 يوليو 2026 تحديثًا مهمًا على تخصيص مراجعة GitHub Copilot يجعل تجربة المراجعة الآلية أكثر مرونة للفرق الهندسية، خصوصًا تلك التي تريد فرض معايير داخلية دقيقة بدل الاكتفاء بإعدادات عامة. ووفق الشرح الرسمي، لم تعد مراجعة Copilot مجرد تعليقات تلقائية على طلبات السحب، بل أصبحت قابلة للضبط عبر تعليمات مخصّصة، خطوات إعداد مستقلة، وإعدادات تشغيل منفصلة عن الوكيل السحابي.

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

ما الجديد في تخصيص مراجعة GitHub Copilot؟

بحسب GitHub Changelog، أضاف التحديث أربع نقاط رئيسية: قراءة التعليمات المخصصة من head branch بدل base branch، دعم ملفات إرشادية إضافية، ملف إعداد مستقل باسم copilot-code-review.yml، وجدار حماية خاص بمراجعة الكود يمكن ضبطه بشكل منفصل. هذه المجموعة تجعل تخصيص مراجعة GitHub Copilot أقرب إلى نظام قابل للإدارة، لا مجرد زر لتفعيل المراجعة الآلية.

اللافت هنا أن GitHub تحاول فصل طبقة “كيف يراجع Copilot الكود” عن طبقة “كيف يعمل الوكيل السحابي عمومًا”. وهذا مهم للفرق التي تريد الاستفادة من مراجعات Copilot دون منح الوكلاء الآخرين الإعدادات نفسها أو صلاحيات الشبكة ذاتها.

قراءة التعليمات من فرع العمل لماذا هي مهمة؟

قبل هذا التحديث، كانت الفرق بحاجة غالبًا إلى الاعتماد على ملفات موجودة في الفرع الأساسي حتى تلتقطها المراجعة. الآن تؤكد GitHub أن تخصيص مراجعة GitHub Copilot يقرأ التعليمات من الفرع الجاري مراجعته نفسه. هذا يعني أن بإمكان فريق التطوير تعديل ملفات مثل copilot-instructions.md أو AGENTS.md داخل فرع الميزة، ثم مراقبة تأثيرها فورًا على التعليقات الناتجة من Copilot.

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

ما الملفات الجديدة التي يفهمها Copilot الآن؟

توضح GitHub أن النظام لم يعد يقتصر على ملفات الإرشادات التقليدية فقط، بل أصبح يقرأ أيضًا REVIEW.md وGEMINI.md وCLAUDE.md. هذه الخطوة مفيدة لأن كثيرًا من الفرق صارت تحتفظ بإرشاداتها في ملفات مختلفة بحسب الأداة أو بحسب ما اعتادت عليه داخليًا، وكان توحيدها فقط لإرضاء المراجع الآلي أمرًا مرهقًا أحيانًا.

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

ملف copilot-code-review.yml يفتح بابًا لإعدادات أدق

من أبرز الإضافات أيضًا دعم ملف copilot-code-review.yml داخل مجلد .github/workflows/. هذا الملف يتيح للفرق تعريف خطوات إعداد خاصة بمراجعة Copilot نفسها، مثل تثبيت تبعيات، تجهيز أدوات lint أو تحليل إضافية، أو إعداد بيئة التشغيل بحيث تصل المراجعة إلى السياق الذي تحتاجه فعلًا.

الفكرة هنا أن تخصيص مراجعة GitHub Copilot لم يعد يعتمد فقط على النصوص والتعليمات المكتوبة، بل يمكن دعمه أيضًا بخطوات تشغيل عملية تساعد المراجع على فهم المشروع بشكل أفضل قبل التعليق. وإذا لم يوجد هذا الملف، تقول GitHub إن النظام يمكنه الرجوع إلى copilot-setup-steps.yml إن كان موجودًا، ما يخفف الاحتكاك عند الانتقال إلى الهيكل الجديد.

جدار الحماية الجديد ماذا يغيّر للفرق؟

من أكثر الأجزاء حساسية في التحديث أن Copilot code review أصبح يعمل خلف جدار حماية مفعّل افتراضيًا، مع إمكانية ضبطه بشكل منفصل عن Copilot cloud agent من إعدادات Copilot → Internet access. بحسب توثيق GitHub، الهدف من ذلك هو تقليل مخاطر تسرب البيانات ومنح المؤسسات سيطرة أوضح على الاتصالات المسموح بها أثناء المراجعة.

هذا البعد مهم خصوصًا للفرق التي تعمل في بيئات مؤسسية أو تنظّم الوصول للشبكة بعناية. فبدل التعامل مع Copilot كمكوّن واحد بإعداد شبكي موحّد، بات بالإمكان تخصيص قواعد الاتصال الخاصة بالمراجعة وحدها. وإذا كنت تتابع تحركات GitHub الأخيرة، فهذه الخطوة تكمل مسار الحوكمة الذي رأيناه أيضًا في مقالنا عن GitHub Code Quality، حيث باتت المنصة تربط السرعة بإعدادات رقابية أكثر وضوحًا.

هل هناك قيود يجب الانتباه لها؟

نعم، وهناك قيد مهم ذكرته GitHub صراحة: أجهزة التشغيل الذاتية لا تدعم جدار الحماية حاليًا في مراجعة Copilot. وهذا يعني أن الفرق التي تعتمد self-hosted runners ستحصل على المراجعات، لكن بدون طبقة الحماية الشبكية نفسها. لذلك لا ينبغي قراءة التحديث باعتباره حلًا موحدًا لكل البيئات، بل خطوة قوية لبيئات GitHub-hosted أولًا، مع استمرار الحاجة إلى سياسات داخلية إضافية عند الاعتماد على البنية الذاتية.

كما أن فصل إعدادات نوع المشغّل على مستوى المؤسسة بين Copilot code review وCopilot cloud agent يمنح المؤسسات مرونة أكبر، لكنه يضيف أيضًا طبقة جديدة من التعقيد الإداري. الفرق الصغيرة قد لا تشعر بالفارق بسرعة، أما الفرق الكبيرة فستستفيد من هذه الاستقلالية عند ضبط الأداء، الكلفة، والامتثال.

لماذا يهم هذا التحديث عمليًا؟

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

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

الخلاصة

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

إذا كانت مؤسستك تستخدم GitHub Copilot بالفعل، فهذه التحديثات تستحق المتابعة الجدية، لأنها تنقل المراجعة الآلية من وضع “تشغيل عام” إلى وضع يمكن هندسته وضبطه بما يتناسب مع قواعد العمل الداخلية، وهو ما تحتاجه الفرق التي تريد الاستفادة من الذكاء الاصطناعي دون خسارة السيطرة على معايير المراجعة.