IDD Skill: قالب سير عمل التطوير الموجّه بالقضايا

لمن هذا

• المطورون والفرق الصغيرة الذين يديرون تطويرهم اليومي في مستودع Git خاص بهم ويريدون تثبيت «من القضية إلى الدمج» كإجراء متكرر: بعد الاستيراد، يتّبع وكيل البرمجة بالذكاء الاصطناعي داخل المستودع سير العمل الموصوف رسميًا — اكتشاف القضايا الجاهزة، والاستحواذ عليها، والتنفيذ في فرع، وفتح طلب سحب (PR)، ومعالجة ملاحظات المراجعة، وانتظار CI، والدمج وفق سياسة الدمج المختارة في المستودع ثم التنظيف. ويوصف هذا سير العمل رسميًا بأنه «قابل للنقل»: يُستورد مع المستودع بدل أن يكون مرتبطًا بأداة واحدة.
• المطورون الذين يستخدمون عدة أدوات برمجة بالذكاء الاصطناعي ولا يريدون حصر سير العمل في عميل واحد: وفق الشرح الرسمي، تعمل الحلقة الأساسية عبر GitHub Copilot وClaude Code وOpenAI Codex CLI وOpenCode وAntigravity CLI (المعروف سابقًا باسم Gemini CLI).
• الفرق التي تحتاج إلى جلسات عمل متعددة تتقدم في قضايا مختلفة بالتوازي: يبيّن الشرح الرسمي أن السياسة الافتراضية للوضع الموزع هي fully_autonomous_merge التي تسمح لجلسات العمل بالمضي حتى الدمج؛ أما كيفية التنسيق بين الجلسات وتجنّب التعارض فلا يوجد له شرح رسمي.
• ما ينبغي التأكد منه قبل التبني: لا تذكر الصفحة الرسمية ما إذا كانت منصات الاستضافة غير GitHub مدعومة — وهذه نقطة غير مؤكدة؛ وإذا كان فريقك لا يقبل الدمج التلقائي الكامل، فسيلزم تقييم السياسة الافتراضية أو تعديلها أولًا، ولا يشرح المصدر الرسمي طريقة تعديلها.

أول تجربة خلال 3 دقائق

• المتطلبات: مستودع Git تملك فيه صلاحية إنشاء الفروع وفتح طلبات السحب؛ وبيئة مهيأة بكل تبعيات الحلقة الكاملة التي سردها المصدر الرسمي — git، وgh CLI موثّق (أو تكامل GitHub MCP مكافئ، ويكفي تحقّق أحد الاثنين)، وjq، وعميل REST مثل curl.
• مكان التثبيت وطريقته: لا حاجة لنسخ الملفات يدويًا. الطريقة الرسمية هي توجيه أمر الاستيراد مباشرة إلى وكيل الذكاء الاصطناعي داخل المستودع الهدف، ويتولى دليل الإعداد (onboarding) نسخ القالب.
• التشغيل: افتح وكيلًا مدعومًا في المستودع وأدخل هذا الأمر الرسمي حرفيًا:

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

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

حالات الاستخدام

الحالة الأولى: تسليم قضية جاهزة من البداية إلى النهاية. السيناريو: في قائمة الأعمال المتراكمة (backlog) قضايا موسومة كجاهزة، وتريد التحقق من الحلقة المغلقة من الاستحواذ إلى الدمج. وجّه للوكيل: «استحوذ على قضية جاهزة وأكمل تنفيذها.» سيسلك الحلقة الرسمية الكاملة — قراءة دليل سير العمل، والاستحواذ على القضية، والتنفيذ في فرع، وفتح PR، ومعالجة ملاحظات المراجعة، وانتظار CI، والدمج وفق السياسة المختارة في المستودع ثم التنظيف. المحطات المرئية بالترتيب: ظهور فرع، وإنشاء PR، وتغيّر حالة CI، ثم الدمج وتنظيف الفرع؛ وكل خطوة تقابل مرحلة ثابتة من الحلقة الرسمية. وتحت السياسة الافتراضية fully_autonomous_merge يمكن لجلسة العمل أن تمضي حتى الدمج؛ لذا تحقق قبل أول تشغيل من وجود بوابات CI وحماية الفروع، أو نصّ صراحة في الأمر على التوقف هذه المرة عند PR.

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

حدود الاستخدام

• الآثار الجانبية ونقاط التأكيد: الاستيراد ينسخ ملفات القالب إلى المستودع، ولا يذكر المصدر الرسمي إن كان يقتصر على إضافة ملفات جديدة أم يعدّل ملفات موجودة أيضًا؛ لذا راجع بعد الاستيراد قائمة التغييرات التي يقدمها الوكيل أولًا. الحلقة الكاملة تنشئ فروع وتُجري commits وتفتح PRs وتمضي حتى الدمج تحت السياسة الافتراضية fully_autonomous_merge. لا يُفصّل المصدر الرسمي أي الإجراءات تطلب تأكيدًا مسبقًا؛ لذا حدّد صراحة نطاق المسموح في كل أمر.
• الوصول الشبكي والوصول إلى الأوامر: تتطلب الحلقة الكاملة gh CLI موثّقًا أو تكامل GitHub MCP مكافئًا، وتسمّ عملاء REST مثل curl؛ أي أن الوكيل يصل إلى واجهات GitHub عبر هذه الأدوات أثناء الحلقة (قراءة القضايا وإنشاء PRs ودمجها وغير ذلك). لا يُفصّل المصدر الرسمي أي الواجهات تُستدعى تحديدًا ولا وجود وصول شبكي آخر.
• بيئة التشغيل ومتطلبات العميل: يسردها المصدر الرسمي بأن الحلقة الأساسية تعمل عبر GitHub Copilot وClaude Code وOpenAI Codex CLI وOpenCode وAntigravity CLI (المعروف سابقًا باسم Gemini CLI)؛ أما إمكانية استخدام وكلاء خارج القائمة، وهل هناك متطلبات إضافية لنظام التشغيل، وهل يعمل بشكل متدهور عند نقص التبعيات، فلا شرح رسمي لها.
• القيود الرسمية الصريحة والمجهول: لا تذكر المواد الرسمية الدعم لمنصات استضافة غير GitHub، ولا تشرح ما هي سياسات الدمج الأخرى غير fully_autonomous_merge ولا كيفية التبديل بينها؛ وسلوك إعادة المحاولة بعد فشل CI غير مؤكد أيضًا. في هذه التفاصيل، المرجع هو نص دليل سير العمل المستورد إلى المستودع.