غاري تان ينشر إعدادات Claude Code الخاصة به: 23 أداة بأدوار مختلفة و139 ألف نجمة

مشهد مألوف: تطلب من وكيل ذكاء اصطناعي «تنفيذ ميزة جديدة»، فيبتكر في تدفق واحد المنتج، ويرسم الواجهة، ويكتب الشيفرة، ويمتدح نفسه، وينسى التوثيق. وتكون النتيجة عادةً متوسطة في كل الجوانب. يحاول مستودع garrytan/gstack علاج هذه المشكلة تحديدًا، وهو يعود اليوم إلى قائمة الأعلى رواجًا اليومية في GitHub Trending: 139,039 نجمة في المجموع و285 نجمة خلال الـ24 ساعة الماضية.

ما هذه المجموعة؟

يقدّم غاري تان gstack بوصفه الإعداد الدقيق الخاص به لـ Claude Code. يذكر وصف المشروع أنه يضم 23 أداة «حاسمة الرأي» (opinionated) تعمل بوصفها رئيسًا تنفيذيًا، ومصممًا، ومدير هندسة، ومدير إصدارات، ومهندس توثيق، ومختبر جودة. والمشروع مكتوب بلغة TypeScript.

تنبيه مهم: نحن نعتمد على وصف المستودع ومؤشراته. ولا نقدّم هنا تحليلًا سطرًا بسطر لكل أداة من الأدوات الـ23، ويُستحسن إجراء هذا التحليل بنفسك قبل اعتماد المجموعة.

لماذا تعمل الأدوار أفضل من موجّه عام؟

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

تخيّل يومًا عاديًا. تريد إضافة شاشة إعدادات إلى خدمة ما. في نظام الأدوار قد يكون التسلسل كالتالي:

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

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

لماذا يُناقَش هذا المشروع؟

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

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

القيود

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

وهناك كلفة خفية أيضًا: المزيد من الأدوار يعني مزيدًا من استدعاءات النموذج، ومزيدًا من الرموز (tokens)، ومزيدًا من المواضع التي قد يحدث فيها خلل. وإذا كان مشروعك صغيرًا، فقد تكون 23 أداة أكثر من اللازم، ويكفي اثنتان أو ثلاث.

ماذا تفعل عمليًا؟

لا تثبّت المجموعة كاملةً على مستودع العمل منذ اليوم الأول. الأفضل أن تفعل التالي:

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

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

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