المهارات team-collaboration-issue
🔧

team-collaboration-issue

آمن

حل مشكلات GitHub بشكل منهجي

حوّل تقارير الأخطاء الغامضة وطلبات الميزات إلى كود جاهز للإنتاج من خلال التحقيق المنهجي، والتطوير القائم على الاختبار، وسير عمل طلبات السحب الاحترافية التي تتبع ممارسات CI/CD الحديثة.

يدعم: Claude Codex Code(CC)
📊 71 كافٍ
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "team-collaboration-issue". ساعدني في تحقيق المشكلة #456 حيث لا يستطيع المستخدمون تسجيل الدخول بعد آخر نشر.

النتيجة المتوقعة:

  • تم استرداد تفاصيل المشكلة #456: تأثر 47 مستخدماً، المصادقة تفشل مع خطأ 'invalid token'
  • تم إنشاء فرع hotfix: hotfix/issue-456-auth-failure
  • تشغيل git bisect لتحديد التزام التراجع...
  • تم العثور على: Commit abc123d قدم خطأ التحقق من الرمز المميز قبل يومين
  • تم تنفيذ الإصلاح: أضيف فحص انتهاء صلاحية الرمز المميز بشكل صحيح مع تغطية الاختبار
  • تم إنشاء PR #789 مع hotfix ونشره على staging
  • التحقق: المصادقة تعمل الآن لجميع حسابات الاختبار

استخدام "team-collaboration-issue". نفذ ميزة تخصيص ملف المستخدم من المشكلة #789.

النتيجة المتوقعة:

  • تم إنشاء خطة تنفيذ مع 4 مراحل: المخطط، API، الواجهة الأمامية، الاختبار
  • تم إنشاء الفرع: feature/issue-789-profile-customization
  • اكتملت المرحلة 1: أُضيف نموذج قاعدة بيانات UserProfile مع حقول theme و language و timezone
  • اكتملت المرحلة 2: نُفذت نقاط نهاية GET/PUT /api/profile مع المصادقة
  • اكتملت المرحلة 3: أُضيف مكون إعدادات ملف التعريف للواجهة الأمامية
  • اكتملت المرحلة 4: تم تحقيق تغطية اختبار 95% مع اختبارات الوحدة والدمج
  • تم إنشاء PR #812 مرتبطاً بالمشكلة #789 مع توثيق شامل
  • جميع فحوصات CI تمر، جاهز للمراجعة

التدقيق الأمني

آمن
v1 • 2/25/2026

All 77 static findings are false positives. The skill contains only documentation with code examples in markdown code blocks (git commands, GitHub CLI usage, testing patterns). No executable code, scripts, or runtime behavior present. The external commands, network patterns, and cryptographic references are purely illustrative examples for developers to follow during issue resolution workflows.

2
الملفات التي تم فحصها
681
الأسطر التي تم تحليلها
0
النتائج
1
إجمالي عمليات التدقيق
لا توجد مشكلات أمنية
تم تدقيقه بواسطة: claude

درجة الجودة

38
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
32
المجتمع
100
الأمان
91
الامتثال للمواصفات

ماذا يمكنك بناءه

إصلاح خطأ إنتاجي حرج

فرز وحل مشكلات الإنتاج P0 بسرعة التي تؤثر على المستخدمين من خلال تحليل السبب الجذري المنهجي باستخدام git bisect، وتنفيذ الإصلاحات العاجلة مع اختبار شامل، والنشر مع خطوات التحقق.

تنفيذ ميزة من مشكلة

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

تحسين جودة الكود والعمليات

أنشئ سير عمل فريق متسق لحل المشكلات مع إدارة الفروع المناسبة، والاختبار الشامل، والتوثيق الذي يتوسع عبر فرق التطوير.

جرّب هذه الموجهات

تحقيق المشكلة الأساسي 
ساعدني في حل مشكلة GitHub [ISSUE_NUMBER]. ابدأ بعرض تفاصيل المشكلة والتعليقات لفهم المشكلة.
تحليل السبب الجذري 
تبدو المشكلة [ISSUE_NUMBER] كتراجع. ساعدني في استخدام git bisect لتحديد أي التزام قدم الخطأ، بدءاً من [BAD_COMMIT] كخاطئ و [GOOD_COMMIT] كعامِل.
تنفيذ الميزة الكامل 
نفذ الميزة الموضحة في المشكلة [ISSUE_NUMBER]. أنشئ فرع ميزة، وقسّم التنفيذ إلى مراحل، واكتب الاختبارات أولاً باستخدام TDD، وأنشئ طلب سحب مع توثيق شامل.
إنشاء ومراجعة PR 
راجع تغييراتي للمشكلة [ISSUE_NUMBER] وساعدني في إنشاء طلب سحب احترافي مع وصف شامل يتضمن نهج الاختبار، وتأثير الأداء، وقائمة مرجعية.

أفضل الممارسات

  • أنشئ دائماً فروع ميزات من الفرع الرئيسي باستخدام تسمية وصفية مثل feature/issue-123-short-description
  • اكتب اختبارات فاشلة قبل تنفيذ الإصلاحات (التطوير القائم على الاختبار) لضمان حل الإصلاح للمشكلة الفعلية
  • استخدم git bisect للبحث المنهجي عن التراجعات عندما أُدخلت الأخطاء في التزامات سابقة
  • أنشئ طلبات سحب شاملة تربط بالمشكلات، وتصف التغييرات، وتتضمن قوائم مرجعية للاختبار
  • تحقق من الإصلاحات في الإنتاج قبل إغلاق المشكلات وأضف تعليقات الحل للرجوع إليها مستقبلاً

تجنب

  • تخطي مرحلة التحقيق والقفز مباشرة إلى تغييرات الكود دون فهم السبب الجذري
  • إجراء التزامات مباشرة على main أو master بدلاً من استخدام فروع الميزات لعمل المشكلات
  • كتابة كود بدون اختبارات مقابلة، مما يجعل التراجعات المستقبلية أكثر احتمالاً
  • إنشاء طلبات سحب بدون ربط بالمشكلات أو تقديم أوصاف واضحة لما تم تغييره
  • إغلاق المشكلات فوراً بعد دمج PRs بدون التحقق من أن الإصلاح يحل فعلياً المشكلة المبلغ عنها

الأسئلة المتكررة

ما الأدوات التي أحتاجها لاستخدام هذه المهارة بفعالية؟
تحتاج إلى تثبيت git محلياً و GitHub CLI (gh) مصادق عليه مع حسابك. تفترض المهارة أيضاً الإلمام بعمليات سطر الأوامر وإطار اختبار مشروعك.
هل يمكن لهذه المهارة المساعدة في المشكلات في مستودعات غير GitHub؟
هذه المهارة مصممة خصيصاً لسير عمل GitHub باستخدام GitHub CLI. بالنسبة لـ GitLab أو Bitbucket أو المنصات الأخرى، ستحتاج إلى تكييف الأوامر مع الأدوات المكافئة.
ماذا يجب أن أفعل إذا استغرق git bisect وقتاً طويلاً للعثور على الالتزام الخاطئ؟
إذا كان bisect بطيئاً، قلّص النطاق بالبدء بالتزامات أقرب إلى وقت الإبلاغ عن المشكلة لأول مرة. يمكنك أيضاً أتمتة bisect بسكربت اختبار يعيد إنتاج المشكلة.
كيف أتعامل مع المشكلات التي تفتقر إلى خطوات إعادة الإنتاج الواضحة؟
ابدأ بإضافة تعليقات على المشكلة طلباً للتوضيح. استخدم إطار الفرز لتصنيف الأولوية. إذا كان هناك حد أدنى من المعلومات، ضع علامة 'needs triage' وابحث عن مزيد من التفاصيل من المبلّغ.
هل يجب أن أتبع دائماً خطة التنفيذ الرباعية للإصلاحات البسيطة؟
لا، كيّف التخطيط حسب التعقيد. الإصلاحات البسيطة أحادية السطر قد لا تحتاج إلى تفصيل مهام مكثف. استخدم المراحل كإرشاد وقلّلها للتغييرات المباشرة.
ماذا لو استمرت الاختبارات التي أكتبها لإصلاحي في الفشل؟
الاختبارات الفاشلة قد تشير إلى أن وصف المشكلة غير مكتمل أو أن هناك أخطاء أخرى. أعد فحص المشكلة، ووضّح المتطلبات، وتأكد من أن اختبارك يعكس بدقة السلوك المتوقع الموصوف في المشكلة.

تفاصيل المطور

المؤلف

sickn33

الترخيص

MIT

المستودع

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/team-collaboration-issue

مرجع

main

بنية الملفات

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md