Superpowers
نشط ومستقريعمل محلياً ✓بدون اشتراك APISuperpowers مهارات تنظّم عمل وكيل البرمجة من توضيح الطلب إلى خطة واختبارات ومراجعة، لتعرف ما سيُنفّذ وكيف تتحقق منه.
/plugin install superpowers@claude-plugins-officialالاستخدام المثالي لهذه الأداة
تناسب مطوّرًا أو صاحب مشروع يريد تنفيذ ميزة كبيرة أو إصلاح عطل تتداخل فيه قرارات التصميم مع الكود. تساعده على توضيح المطلوب واعتماد خطة ثم مراجعة الاختبارات وفروقات الملفات. قيمتها أن خطوات التنفيذ ودليل اكتماله تصبح واضحة. التعديل النصي البسيط قد لا يحتاج المسار الكامل.
التفاصيل والميزات المصورة
تطلب من وكيل البرمجة إضافة ميزة، فيبدأ بتعديل الملفات قبل أن يحسم معك ما المطلوب؟ هنا تفيدك Superpowers: مجموعة مهارات ومنهج عمل لوكلاء البرمجة، طوّرها Jesse Vincent ومساهمون، تقود المهمة من توضيح الفكرة إلى التصميم والخطة والتنفيذ والاختبار والمراجعة. قيمتها أن القرارات وخطوات التحقق تصبح واضحة قبل إعلان اكتمال العمل. وهي طريقة لتنظيم الوكيل، وليست ضمانًا لصحة الكود.
🧭 ما Superpowers وكيف تعمل؟
بعد تثبيتها في أداة البرمجة المدعومة، يستدعي الوكيل المهارات الملائمة أثناء العمل. تبدأ مهارة brainstorming بتوضيح الطلب وعرض تصميم للموافقة؛ ثم تحول writing-plans التصميم إلى مهام صغيرة محددة. عند التنفيذ يمكن استخدام executing-plans داخل الجلسة أو subagent-driven-development التي توزع المهام على وكلاء مستقلين مع مراجعة. تتبع ذلك مهارات للاختبار، فحص التغيير، والتحقق من النتيجة.

🎯 كيف ستفيدك؟ وما القيمة المضافة؟
لو أردت إضافة صلاحيات لمشروعك، فقد يكون طلب «أضف صلاحيات» غير كافٍ: هل يستطيع صاحب المشروع رؤية كل المهام؟ وهل يحق للعضو تعديل مهام غيره؟ تساعدك Superpowers على كشف هذه الأسئلة أولًا، واعتماد قواعد الوصول، ثم تحويلها إلى خطوات تطوير يمكن اختبارها. ستعرف ما اتُّفق عليه، وما الذي غيّره الوكيل، وما الدليل على نجاحه. تبقى مسؤولًا عن القرارات المهمة ومراجعة النتائج.
🌟 الميزات وطريقة استخدامها
1. حوّل الطلب الغامض إلى تصميم
المشكلة: قد يكتب الوكيل ميزة صحيحة تقنيًا لكنها لا توافق حاجتك. كيف تعمل؟ تسأل brainstorming عن الهدف والقيود، وتعرض أجزاء التصميم للموافقة قبل كتابة الكود. في مثال الصلاحيات، حدد الأدوار وحالات القراءة والتعديل والاستثناءات. الفائدة: تستطيع تصحيح المسار بينما التعديل ما زال فكرة. القيد: يلزم منك حسم الأسئلة التي لا يجيب عنها المستودع.

2. اكتب خطة قصيرة لكل خطوة
بعد الموافقة، تضع writing-plans مهامًا صغيرة فيها الملفات المقصودة وطريقة التحقق. اطلب من الوكيل عرض الخطة قبل التنفيذ: هل حدد ملفات الصلاحيات واختبارات الوصول؟ يمكنه تنفيذ الخطة في الجلسة عبر executing-plans، أو توزيع مهامها عبر subagent-driven-development مع مراجعة لكل مهمة. الفائدة: يسهل اكتشاف ما نُفذ وما بقي، بدل طلب عام يصعب تدقيقه. القيد: التوزيع على وكلاء قد يزيد استهلاك النموذج وليس مطلوبًا للتعديل البسيط.

3. اختبر السلوك وابحث عن سبب الخطأ
توجه test-driven-development الوكيل إلى كتابة اختبار يفشل للسلوك المطلوب، ثم أقل تعديل يجعله ينجح، ثم تحسين الكود مع استمرار نجاح الاختبار. لمشكلة صلاحيات، جرّب حالة عضو لا يملك حق تعديل مهمة غيره قبل إصلاح المنطق. عند تعثر التنفيذ، تدفع systematic-debugging إلى تشخيص السبب بدل تعديل متكرر بلا فرضية، وتطلب verification-before-completion دليلًا قبل إعلان الإنجاز. الفائدة: يصبح الادعاء «تم الإصلاح» قابلًا للفحص. القيد: نجاح اختبار واحد لا يغني عن تغطية الحالات المهمة أو مراجعتك.

4. اعزل التعديل وراجع نهايته
تستخدم using-git-worktrees مساحة عمل منفصلة لفرع المهمة، ثم تفحص requesting-code-review التغييرات مقابل الخطة، وتعرض finishing-a-development-branch خيارات إنهاء الفرع بعد التحقق. اطلب من الوكيل أن يريك فروقات Git ونتائج الاختبارات قبل اختيار الدمج أو طلب المراجعة. الفائدة: تستطيع تتبع نطاق التغيير ومراجعته. القيد: مهارات Git تحتاج مستودعًا مناسبًا وصلاحيات للأداة المضيفة؛ لا تدمج تلقائيًا لمجرد وجود المراجعة.

🪜 مثال استخدام خطوة بخطوة
مثال توضيحي لم ننفذه: اطلب «أضف دور عضو يستطيع قراءة مهام مشروعه، ولا يستطيع تعديل مهمة غيره». يسألك الوكيل عن دور المشرف والاستثناءات؛ توافق على التصميم؛ يحدد خطة الملفات والاختبارات؛ ينفذ اختبار منع التعديل؛ يعدل المنطق؛ يعيد الاختبار؛ ثم يعرض التغيير للمراجعة. إذا تغيرت قاعدة العمل أثناء التنفيذ، أعدها إلى التصميم قبل مواصلة الخطة.
⚖️ ماذا تضيف مقارنة بالعمل اليدوي؟
| من دون المنهج | مع Superpowers |
|---|---|
| تعيد تذكير الوكيل بتوضيح المتطلبات | brainstorming تنظم أسئلة التصميم والموافقة |
| تطلب خطة واختبارات في كل مرة | writing-plans وtest-driven-development تحددان الخطوات |
| تراجع نتيجة عامة مثل «تم» | verification-before-completion تطلب دليلًا |
| تنظم الفرع والمراجعة بنفسك | مهارات worktrees والمراجعة وإنهاء الفرع توجه الوكيل |
هذه مقارنة لطريقة العمل، وليست قياسًا لتوفير الوقت أو ضمانًا للجودة.
🚀 التثبيت والبدء
يختلف التثبيت بحسب أداة الوكيل، ويجب تثبيت Superpowers في كل أداة تستخدمها على حدة. في Claude Code يذكر المستودع هذا الأمر داخل واجهة الإضافات:
/plugin install superpowers@claude-plugins-official
في Codex CLI افتح /plugins ثم ابحث عن Superpowers واختر Install Plugin. وفي تطبيق Codex افتح Plugins واختر Superpowers. توجد تعليمات مستقلة لـCursor وOpenCode وGemini CLI وأدوات أخرى في README؛ راجع قسم منصتك والإصدار قبل نسخ أمر منها. لم أختبر التثبيت أو أشغّل الأمر هنا.
⚙️ الإعداد والتوافق والتكلفة والخصوصية
لا تحتاج لضبط كل مهارة يدويًا لبدء المسار؛ لكن يمكنك اختيار أسلوب تنفيذ الخطة المناسب، ومراجعة صلاحيات الأداة المضيفة قبل السماح لها بقراءة الملفات أو تشغيل الأوامر. ترخيص كود المشروع MIT، بينما اشتراك أداة البرمجة وتكلفة النموذج أو API منفصلة. وجود المهارات محليًا لا يعني عمل الأداة المضيفة دون اتصال بالشبكة.
يذكر README أن الرفيق المرئي الاختياري لـbrainstorming يحمّل شعار Prime Radiant يتضمن رقم إصدار Superpowers، وأن متغير SUPERPOWERS_DISABLE_TELEMETRY يعطّل ذلك. هذا لا يصف كل حركة شبكة تقوم بها أدوات Claude أو Codex وغيرها. دعم DeepSeek Harness غير مثبت في README الأصلي؛ يوجد مشروع تكييف مستقل باسم superpowers-dsh، ولا ينبغي الخلط بينهما.
⚠️ الحدود ومتى لا تستخدم الدورة كاملة
إصلاح نص صغير قد لا يستحق جولة تصميم وخطة ومراجعات. تعدد المراحل أو الوكلاء قد يزيد زمن العمل وتكلفة النموذج. كما أن المنهج لا يعرف متطلبات مشروعك من تلقاء نفسه ولا يعفيك من اعتماد التصميم وفحص صلاحيات الوكيل والاختبارات الفعلية.
📚 المصادر وتاريخ التحقق
المستودع الأصلي وREADME · تعليمات التثبيت · خطوات العمل · الترخيص. تحققت في 23 سبتمبر 2026؛ عرضت واجهة GitHub وقت الفحص 290,468 نجمة و25,988 تفرعًا. هذه أرقام شعبية متغيرة وليست تقييمات جودة أو أمان. لم أختبر التثبيت أو المثال على مشروع حقيقي.