يمكن أن يرشد Superpowers مستخدم Claude Code خلال تغيير كبير في مستودع Git يملكه: الاتفاق على التصميم، واعتماد خطة مهام، والتنفيذ مع الاختبارات، ومراجعة كل مهمة وفحص الفرع المنجز. يتبع هذا الدليل أدلة Superpowers 7.0.0 الرسمية التي راجعناها في 20 أكتوبر 2026. راجعت BIG CHANGE الوثائق؛ ولم نثبت الإضافة أو ننفذ مشروعاً من خلالها.

التغيير الكبير

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

قبل البدء

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

تحتاج إلى Git، وتثبيت Claude Code مسجل الدخول، وإذن لتثبيت الإضافات وإنشاء فرع أو worktree، وسعة كافية في الخطة أو API لاستخدام Claude Code ووكلائه الفرعيين. راجع قواعد مؤسستك للوصول إلى الشيفرة المصدرية واستخدام الإضافات. افحص محتويات الإضافة، وأذوناتها الفعلية، وشروط بيانات المزود وضوابط الإنفاق قبل تفعيلها. تحذر Anthropic من أن hooks الإضافات وعمليات الخادم قد تعمل بصلاحيات المستخدم خارج البيئة المعزولة لاستدعاءات الأدوات؛ ولا تشمل مطالبات أذونات الأدوات العادية كل هذه الشيفرة. أبقِ الأسرار والتبعيات والكتابات الخارجية وعمليات الدفع والإصدار ضمن صلاحياتك الفعلية. وثائق أمان إضافات Claude Code تشرح هذا الحد.

يستخدم المسار أدناه مهارة Superpowers المسماة subagent-driven-development لتغيير يتضمن مهام متعددة. وتصف الأدلة أيضاً مساراً داخل السياق باسم executing-plans وتسمح باتفاقات تصميم أبسط للأعمال الصغيرة. اختر المسار مع المالك قبل التنفيذ، بدلاً من افتراض أن كل مشروع يحتاج إلى التسلسل الكامل.

1. ثبّت الإضافة وتحقق من الإصدار النشط

في جلسة Claude Code تفاعلية، أدخل أمر السوق الرسمي:

Text
/plugin install superpowers@claude-plugins-official

يفتح Claude Code لوحة تفاصيل الإضافة قبل التثبيت. افحص المحتويات واختر نطاقاً مأذوناً به. يفعّل النطاق المحلي الإضافة لك في هذا المستودع؛ ويؤثر نطاق المشروع في إعدادات مستودع المتعاونين. اقرأ ملخص التثبيت وعلامة Errors. اتبع تعليمات تفعيل الجلسة أو أعد التشغيل، ثم افحص علامة Installed وشغّل claude plugin list في الطرفية. دوّن Version وScope وStatus الظاهرة، وتأكد من توفر مهارات Superpowers في الجلسة النشطة. لا يثبت أمر السوق تثبيت Git البحثي الذي استند إليه هذا الدليل. إن اختلف الإصدار المثبت أو نص المهارة عن 7.0.0، فطابق الإجراء مع ذلك الإصدار قبل المتابعة. توقف عند فشل التثبيت أو تعطيله؛ فهذه ليست قرينة على تحميل سير العمل. دليل تثبيت Claude Code يوثق هذه الفحوص.

2. اعتمد التصميم ثم الخطة

أخبر Claude Code بالتغيير الحقيقي، ومعايير القبول، ونتيجة البداية، والتعديلات المحظورة. استخدم عملية Superpowers المسماة brainstorming لتسوية الغرض وخيارات التصميم والقيود. في هذا التغيير متعدد الخطوات، افحص التصميم المكتوب وملاحظات فحص المنفّذ، واحسم الأسئلة التي تتطلب قرار المالك، ثم اعتمد الوصف كاملاً. يجب أن يحدد الاعتماد السلوك المراد بناؤه؛ ولا يُستنتج من استمرار الوكيل في الحديث. دليل التصميم يسمح باتفاق أخف أو استثناء صريح للأعمال الأصغر، لذا فاتباع المسار الكامل هنا اختيار مقصود لمهمة كبيرة.

بعد ذلك، اطلب من عملية writing-plans تحويل التصميم إلى مهام. راجع حدود الملفات والواجهات والقيود العامة وأوامر الاختبار وReview Focus في الخطة. اجعل كل مهمة صغيرة بما يكفي للفحص، وأن يقيس اختبارها السلوك المتفق عليه. اعتمد الخطة وطريقة التنفيذ بالوكلاء الفرعيين قبل بدء تعديل الشيفرة. دليل التخطيط يحدد التسليم. لا تعتبر الخطة المعقولة إذناً لإضافة تبعيات أو تعديل ملفات غير مرتبطة.

عند التنفيذ، تتحقق مهارة using-git-worktrees من وجود مساحة عمل مناسبة أو تُعدّ مساحة معزولة بالموافقة المطلوبة. دوّن الفرع الفعلي، وتثبيت الأساس، والحالة الأساسية النظيفة. استخدم دعم worktree المدمج في Claude Code حين يتوفر. إذا احتوت المساحة على تعديلات غير مرتبطة، فاحسم ملكيتها قبل المتابعة. دليل worktree يوضح مسار الفحص والإنشاء.

3. راقب كل اختبار ومراجعة مهمة

مع الخطة المعتمدة، استخدم subagent-driven-development للمهام التي يمكن مراجعتها مستقلةً. يعيّن الدليل الحالي منفّذاً للمهمة، ثم يمرر التنفيذ والفروق إلى مراجع واحد للمهمة. يقدم هذا المراجع حكمين: مدى مطابقة المهمة للمواصفات، ومدى قبول جودة التنفيذ. إنهما حكمان من مراجعة واحدة، لا وكيلان للمراجعة يعملان بالتتابع. ويمكن تجميع المهام الصغيرة المتشابهة وفق قواعد الدليل. سير المهام وتعليمات المراجع يحددان هذا التسلسل.

لكل سلوك مناسب لكتابة الاختبار أولاً، اطلب دورة فشل ثم نجاح قابلة للملاحظة: أضف اختبار السلوك وشغّله ولاحظ الفشل المتوقع؛ نفّذ الحد الأدنى ثم أعد التشغيل ولاحظ النجاح؛ وبعدها حسّن بنية الشيفرة مع استمرار نجاح الفحوص. خطأ الاستيراد أو إطار اختبار معطّل ليس نتيجة الفشل المتوقعة. احتفظ بالأمر والمخرجات وتثبيت Git أو الفروق ذات الصلة لكل مهمة. دليل test-driven-development يصف استثناءات تتطلب موافقة بشرية؛ ويفترض هذا الدليل مهمة تلائم مساره المعتاد القائم على الاختبار أولاً.

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

بعد انتهاء المهام، افحص المراجعة المنفصلة للفرع كله. يمكنها كشف التفاعلات بين المهام وإعادة فحص الملاحظات المؤجلة التي لم يستطع مراجع المهمة حسمها من مجموعة فروق واحدة. اطلب الدليل والحكم لكل مسألة مفتوحة. احتفظ بالتصميم والخطة ومخرجات الاختبارات وتقارير المراجعة والفروق كاملة قبل تنظيف مساحة العمل المؤقتة للإضافة. إن لم تُفعّل مهارة متوقعة، فافحص حالة الإضافة النشطة وإصدارها ومسار التشخيص الموثق؛ ولا تفترض أن سير العمل فُرض لمجرد تثبيت الإضافة.

4. افحص الفرع وحدد مصيره

أعد تشغيل أمر القبول الأصلي على الشيفرة النهائية، مع مجموعة اختبارات المشروع كاملة. افحص المخرجات الحديثة والفروق الكاملة للفرع وكل الملاحظات المتبقية. دليل التحقق في Superpowers يشترط دليلاً من الحالة الحالية قبل ادعاء الاكتمال. إن فشلت المجموعة، فحدد الفشل بدقة وأصلحه أو اترك الفرع للمراجعة؛ ولا يصل المسار الموثق إلى قائمة إنهاء الفرع عند فشل المجموعة.

على فرع مسمى، تقدم مهارة finishing-a-development-branch الدمج المحلي، أو الدفع وإنشاء pull request، أو إبقاء الفرع كما هو. في detached HEAD يتوفر خيارا pull request والإبقاء. لا يُنفذ الإلغاء إلا بعد طلب صريح من المالك وتأكيد مكتوب باليد؛ وليس خياراً رابعاً روتينياً. دليل إنهاء الفرع يوضح هذه الخيارات. اعرض على المالك الفحوص والفروق والملاحظات المتبقية قبل قراره. فالدمج أو الدفع أو الحذف أو الإصدار يتطلب الصلاحية المناسبة لكل إجراء.

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

المصادر وقراءات إضافية

لإصلاح أضيق نطاقاً لفحص قبول فاشل، راجع دليل BIG CHANGE للتحقق من فحص واحد فاشل في المستودع. تبدأ العملية هنا في مرحلة أبكر، بتصميم تغيير متعدد المهام والتخطيط له.