Superpowers: منهجية في مجلد Markdown تحكم وكلاءك

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

Superpowers، من Jesse Vincent، عند نحو 311,000 نجمة بإضافة 5,900 في الأسبوع الماضي. ووصفه هو: منهجية كاملة لتطوير البرمجيات لوكلاء البرمجة، مبنية على مجموعة مهارات قابلة للتركيب مع تعليمات أولية تضمن أن الوكيل يستخدمها فعلاً.

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

الخطوة الأولى هي ألا تبدأ

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

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

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

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

ما في الصندوق فعلاً

خمس عشرة مهارة أو نحوها، مجمّعة بحسب الوظيفة.

الاختبار له مدخل واحد، وهو المهم: test-driven-development، دورة الأحمر-الأخضر-إعادة الهيكلة، مع مستند مرجعي عن أنماط الاختبار المضادة. والتنقيح له systematic-debugging، عملية من أربع مراحل للسبب الجذري مع تقنيات للتتبع والدفاع متعدد الطبقات والانتظار المشروط، إضافة إلى verification-before-completion التي لا وظيفة لها سوى منع الوكيل من إعلان النصر على شيء لم يُصلح.

والتعاون هو حيث الثقل الحقيقي: brainstorming لاستخراج النية، وwriting-plans، وexecuting-plans، وdispatching-parallel-agents، وطلب مراجعة الكود وتلقيها، وusing-git-worktrees، وfinishing-a-development-branch، وsubagent-driven-development بمراجعتها ذات المرحلتين — مطابقة المواصفة أولاً، ثم جودة الكود.

ومهارتان ميتا يغلقان الحلقة: writing-skills لإنشاء مهارات جديدة، وusing-superpowers، المقدمة التي تحث النموذج على تحميل المنظومة في بداية المحادثة. ولأن المهارات تُستدعى تلقائياً، فالنظرية أنك لا تحتاج تذكّر أي من هذا. وكيلك يملكه فحسب.

التثبيت، لكل منظومة، ست عشرة مرة

هذا هو الجزء الذي يخبرك بمدى تشرذم سوق أدوات الوكلاء. يشحن Superpowers تعليمات لـClaude Code، وAntigravity، وتطبيق Codex وسطر أوامره، وCursor، وDevin CLI، وFactory Droid، وGemini CLI، وGitHub Copilot CLI، وGrok Build، وKimi Code، وOpenCode، وPi، وQwen Code، وHermes، وMuse.

Claude Code، عبر السوق الرسمي:

/plugin install superpowers@claude-plugins-official

أو عبر سوق Vincent نفسه:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

وCursor، في دردشة الوكيل: /add-plugin superpowers. وGemini CLI: gemini extensions install https://github.com/obra/superpowers. وCopilot CLI: سجّل السوق، ثم copilot plugin install superpowers@superpowers-marketplace. وAntigravity: agy plugin install https://github.com/obra/superpowers. وDevin: devin plugins install obra/superpowers. وFactory Droid: سجّل، ثم ثبّت. وتطبيق Codex وسطر أوامره كلاهما عبر سوق الإضافات الرسمي.

وإن كنت تستخدم أكثر من منظومة، فأنت تثبّته لكل واحدة على حدة. ما يعني أن المهارات الاثنتي عشرة نفسها موجودة كاثنتي عشرة نسخة بلا مسار تحديث مشترك، ونصيحة README للتحديث هي «يعتمد إلى حد ما على وكيل البرمجة، لكنه تلقائي غالباً». وهذا ليس نقداً للمشروع. إنها حال المنظومة اليوم، ومشاهدة مستودع منهجية يتعامل معها مفيدة بحق.

سياسة المساهمة هي الدليل

مدفون في قسم المساهمة: لا يقبلون عموماً مساهمات بمهارات جديدة، وتحديثات المهارات يجب أن تعمل على كل الوكلاء المدعومين، ولا يقبلون طلبات PR يكتبها وكيل تصلح مشكلات فتحها شخص آخر ما لم يطلبها مشرف، حتى لو صادفت المشكلة نفسها.

فكّر في الغرض من القاعدة الأخيرة. نمط الفشل البديهي لمستودع كهذا أن يُدفن في مهارات تبدو معقولة يولّدها الوكلاء أنفسهم الذين يُفترض أن تحكمهم المهارات. رأى Vincent ذلك قادماً فاستبقه، بثمن أن يبدو غير ودود.

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

أين تنكسر المنهجية

أربعة أشياء، بترتيب كثرة ما رأيتها تعضّ.

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

اقتصاد الرموز. مواصفة، ومراجعة بكتل، وخطة، وإرسال وكلاء فرعيين، ومراجعة بمرحلتين لكل مهمة، وتحقق قبل الإكمال. في مهمة صغيرة هذا قدر هائل من الكلفة الإضافية. والمنهجية مصممة لعمل يُقاس بالأيام، وستبدو عبثية في إصلاح من سطر واحد.

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

والصادق منها: المهارات توجيهات، والتوجيهات اقتراحات. كل شيء هنا يعتمد على اختيار النموذج اتباع المهارة بدل خمسة أشياء أخرى يعرفها أيضاً. لهذا يوجد using-superpowers كنقطة إقلاع — إنه توجيه مهمته أن يجعل توجيهات أخرى تُحمَّل.

لمن هذا

إن كنت تشحن كوداً يعتمد عليه آخرون، ورأيت وكيلاً يعلّم بثقة على شيء منتهٍ وهو ليس كذلك، فهذه مجموعة حواجز معقولة وتكلفة تجربتها أمر واحد. ابدأ بـtest-driven-development وverification-before-completion وتجاهل الباقي أسبوعاً. هاتان تغيّران السلوك أكثر من غيرهما.

وإن كنت تبني نموذجاً أولياً، تجاوزه. المنهجية محسّنة لعدم شحن هراء، وهذا هدف مختلف عن معرفة هل الفكرة تعمل.

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