قد ينهي الوكيل البرمجي المهمة التي فهمها، بينما تبقى أجزاء من المهمة التي قصدتها أنت غير مكتملة. توجد آلية للتخزين المؤقت، لكنها تعيد تنزيل الصورة نفسها. تعمل عملية الشراء في المسار المعتاد، لكن إغلاق التطبيق يفقد المستخدم اختياراته. ويقول تقرير التسليم «تم»، مع أن حالات الاختبار على الجهاز الفعلي لم تُنفذ.
أردت طريقة متكررة تكشف هذه الفجوات قبل قبول التسليم. لذلك أعددت Ironclad-mudrae: مهارة أستخدمها حين أحتاج إلى وكيل يتولى دور مالك المشروع والقائد التقني في التخطيط والمراجعة. يحدد القرارات، ويكتب للمطور أمر عمل يمكن تنفيذه، ثم يطلب الأدلة المناسبة لقبول النتيجة.
تتضمن حزمة المصدر إرشادات لدورة التطوير، وعقداً لتنفيذ المطور، وقواعد للمراجعة واحتساب الإنجاز، وأداة Python اختيارية لفحص اكتمال ملفات التسليم. تتبع المهارة صيغة Agent Skills وترخيصها MIT. ويمكن تنزيل الحزمة بالإصدار 2.1.0 مباشرة.
حدد دور الوكيل قبل أن يبدأ
الوضع الافتراضي هو PLAN. يقرأ الوكيل المصدر والتوثيق اللازمين، ثم يكتب الخطة وأوامر العمل ومعايير القبول. لا يبدأ تنفيذ التطبيق لمجرد امتلاكه الأدوات.
عند عودة تقرير المطور، يعمل وضع REVIEW على فحص النطاق المتفق عليه والتغييرات والأدلة الفعلية. تكون النتيجة قبول النطاق المحدد، أو طلب تعديلات واضحة، أو تحديد عائق يمنع قبول جزء من العمل.
أما EXECUTOR فهو للمطور الذي يكلفه الإنسان صراحة بالتنفيذ. يتبع أمر العمل وحدود الصلاحية الموجودة فيه. مجرد تحميل المهارة لا يمنحه إذناً بالنشر أو إرسال الرسائل أو إجراء عمليات لدى مزود خارجي.
هذا الفصل يسمح لي بطلب خطة إصدار دون أن يتحول الطلب إلى إصدار فعلي. ويحافظ أيضاً على دور المراجع: يحدد الخلل وما يلزم لإغلاقه، بدلاً من إصلاح التسليم بصمت ثم نسب النتيجة إلى المطور الأصلي.
لا تترك القرارات المهمة داخل عبارة «طبق أفضل الممارسات»
طلب مثل «أضف التخزين المؤقت واجعل التطبيق سريعاً» يترك قرارات كثيرة للمطور. ما الذي سيُخزن؟ ما هوية الصورة؟ كيف تُكتشف التحديثات؟ ماذا يبقى بعد إعادة التشغيل؟ وأي بيانات يجب أن تؤخذ مباشرة من الخادم؟
في مهمة لتخزين صور المنتجات، يمكن أن يتضمن أمر العمل القرارات التالية:
| القرار | السلوك المطلوب |
|---|---|
| هوية الصورة | معرف ثابت مع إصدار للمحتوى؛ تعديل السعر لا يغير هوية صورة لم تتغير |
| إعادة الاستخدام | القائمة والتفاصيل والسلة تستخدم الملف المحلي نفسه بدلاً من تنزيل نسخ مستقلة |
| التحديث | فحص بيانات صغيرة للإصدارات، وتنزيل الوسائط التي تغيرت فقط |
| التعافي | إصلاح الملف الناقص بأمان، ومنع تنزيل قديم من استبدال إصدار أحدث |
| مصدر الحقيقة | السعر المخزن للتصفح لا يستبدل عرض السعر الحالي من الخادم عند الدفع |
هذه أمثلة لمتطلبات يمكن تكليف المطور بها، وليست ادعاء بأن تطبيقاً معيناً يحققها بالفعل. يجب أن يحدد أمر العمل أيضاً البيئة والحدود المقبولة للتخزين والسرعة وحداثة البيانات، وحالات الفشل، والأدلة المطلوبة.
يتخذ المخطط القرارات التي تؤثر في صحة النظام. ويمكن إبقاء التفاصيل التنفيذية العادية للمطور ما دامت تحافظ على العقد. أما تعديل نص صغير قابل للتراجع، فيحتاج إلى تكليف قصير ودليل مرئي مناسب، لا إلى برنامج ترحيل وتدقيق إصدار كامل.
اطلب دليلاً يناسب ما يريد المطور إثباته
لقطة الشاشة تثبت أن السلة الممتلئة ظهرت بطريقة صحيحة، لكنها لا تثبت أنها ستبقى بعد إنهاء عملية التطبيق. واختبار الوحدة قد يختبر منطق إعادة المحاولة، لكنه لا يثبت أن مزود الدفع أكمل استرداد المبلغ.
تفصل المهارة بين تنفيذ الميزة، ونجاح الاختبارات الآلية، وصحة الواجهة المعروضة، وسلوك الجهاز الفعلي، وقراءة حالة المزود، والنشر، والإتاحة العامة. لكل ادعاء نوع الدليل الذي يناسبه.
في مثال الصور، ينبغي أن يسجل المطور التنزيل الأول، ثم يفتح المحتوى نفسه عبر الشاشات ويعيد تشغيل التطبيق، ويثبت عدم وجود طلبات مكررة للصور المحفوظة التي لم تتغير. وعند استبدال صورة من لوحة التحكم، يثبت تنزيل الإصدار الجديد وحده دون إعادة تنزيل بقية الصور. تسجيل التفاعل وحركة الشبكة يجيبان عن هذا السؤال أفضل من اسم مكتبة للتخزين المؤقت.
يربط تقرير التسليم كل متطلب بالمصدر الذي تغير والحالات التي اختُبرت والأدلة الفعلية. ويسجل هوية النسخة والبيئة والأوامر ونتائجها والإخفاقات والحالات المتروكة والعوائق. التغيير المؤثر يبطل الأدلة التي تأثرت به؛ فلا تثبت لقطة قديمة صحة نسخة جديدة بصمت.
ماذا تفحص أداة التسليم؟
للمهام الكبيرة، يكتب المخطط عقد قبول بصيغة JSON ويثبت بصمة SHA-256 له قبل التنفيذ. يعيد المطور ملفاً يصف التقارير والأدلة المرفقة.
تفحص الأداة المحلية وجود المعرفات والتقارير المطلوبة، وتطابق النسخة والبيئة، وبصمات الملفات، وأنواع الأدلة، والحالات الآلية المسماة في العقد. وتكشف حالات مثل غياب حالة اختبار، أو مسار ملف غير آمن، أو أمر فاشل استُخدم لدعم ادعاء النجاح. تقرأ الملفات فقط ولا تشغل أوامر تجدها داخل تقرير.
يعطي المثال الاصطناعي المرفق هذه النتيجة:
{
"verdict": "STRUCTURALLY_COMPLETE_PENDING_REVIEW",
"release_authorized": false,
"semantic_review_required": true
}المعنى محدد: ملفات التسليم اجتازت الفحص البنيوي، وما زالت المراجعة الفعلية مطلوبة. تطابق البصمات لا يثبت أن الصورة تعرض الحالة المقصودة، أو أن إيصال المزود حقيقي. الأداة لا تحسب الإنجاز المقبول ولا تتحقق من سلطة صاحب الموافقة.
اجتازت أداة الإصدار 2.1.0 عدد 29 اختباراً محلياً أثناء تجهيز الحزمة. هذه اختبارات للأداة نفسها، وليست مقارنة لقدرات النماذج أو شهادة بجودة تطبيق. يتضمن المستودع الاختبارات والمثال الاصطناعي الموسوم بوضوح حتى يستطيع القارئ فحص هذه الحدود بنفسه.
احسب الإنجاز على نطاق ثابت
في التكليف الكبير، تثبت أوزان معايير القبول قبل التنفيذ. لا يتغير المقام لأن الوصول إلى حساب أو جهاز أو مزود أصبح معطلاً.
إذا كان أمر العمل من 100 نقطة، وقُبلت 72 نقطة، وأعفى المالك صراحة ثماني نقاط، وتعطلت 12 نقطة، وفشلت ثماني نقاط، فالنتيجة 72% إنجاز موثق ومقبول، وثماني نقاط معفاة، و20 نقطة غير مغلقة. لا تصبح النتيجة 80% موثقة، ولا يُحذف العمل المتعطل من الحساب.
يبقى تقدير المطور لما نفذه منفصلاً عن اكتمال المرفقات، وكلاهما منفصل عن الإنجاز الذي قبله المراجع. ولا تسمح نسبة مرتفعة بتجاوز شرط مالي أو متعلق بخصوصية العملاء. حتى اكتمال الجاهزية بنسبة 100% لا يمنح إذناً بالنشر.
توجد بدائل منشورة بالفعل
هذه ليست أول محاولة لتنظيم عمل الوكلاء البرمجيين. راجعت التوثيق الأصلي للمشاريع التالية في 2 نوفمبر 2026. المقارنة تصف نطاقها المعلن، ولا تمثل اختبار تفوق بينها.
| المشروع | التركيز الموثق | متى يستحق المقارنة؟ |
|---|---|---|
| Superpowers | مجموعة مهارات للتخطيط والتنفيذ والتشخيص والتحقق | عندما تريد مسار تطوير أوسع للوكيل المنفذ |
| Planning with Files | حفظ التخطيط والتقدم في ملفات واستمرارية السياق | عندما تكون المشكلة الأساسية فقدان الخطة خلال الجلسات الطويلة |
| Compound Engineering | التخطيط والتنفيذ والمراجعة وحفظ الدروس للعمل اللاحق | عندما يكون تراكم معرفة الفريق جزءاً أساسياً من طريقة العمل |
| BMAD | مسارات للمنتج والهندسة والتنفيذ بوجهات نظر متخصصة | عندما تحتاج إلى منهج أوسع لإدارة تطوير المشروع |
| BMAD-Speckit-SDD-Flow | عقود متطلبات وتنفيذ محدود وأدلة مترابطة وشروط إغلاق بشرية | عندما تكون عقود التسليم وشروط الإغلاق هي حاجتك الأساسية |
تجمع Ironclad-mudrae طريقة عملي في التخطيط الإداري وأوامر العمل وقبول التسليم داخل مهارة قابلة للنقل، مع أداة محلية صغيرة للفحص. يوجد تداخل واضح مع الأفكار السابقة. لا أدعي أنها تتفوق عليها، ولا أن تركيبها جميعاً ينتج بالضرورة نتيجة أفضل. إذا جمعت أكثر من مسار، حدد أيها يملك الخطة وصلاحية التنفيذ ومعايير القبول حتى لا تتعارض التعليمات.
التثبيت وتجربة تكليف واحد
باستخدام Skills CLI:
pnpm dlx skills add yasircs4/ironclad-mudrae --skill ironclad-mudrae -gيعتمد اكتشاف المهارة وتشغيلها على بيئة الوكيل. احتفظ بالمجلد كاملاً، بما فيه المراجع والسكربتات، واتبع تعليمات التثبيت الخاصة ببيئتك. تحتاج أداة الفحص الاختيارية إلى Python 3.9 أو أحدث ومكتبته القياسية؛ ولا تحتاج تعليمات التخطيط إلى Python أو حساب مستضاف.
ابدأ بطلب محدد:
استخدم $ironclad-mudrae في وضع PLAN.
اقرأ مستودع المشروع ومواصفاته الحالية دون تنفيذ التطبيق.
اتخذ القرارات التقنية اللازمة للتغيير المطلوب.
اكتب أمر عمل للمطور يتضمن حالات الفشل ومعايير قبول قابلة للقياس،
والأدلة المطلوبة ومكاناً واضحاً لتقرير التسليم.أعط الوكيل المستودع الحقيقي والقيود الفعلية، ثم راجع قراراته قبل إسناد التنفيذ. تستطيع المهارة جعل النواقص أوضح، لكنها لا تمنح النموذج قدرة أو أدوات أو وصولاً غير موجود. النتيجة المفيدة هي تكليف أدق وقرار قبول يمكن الرجوع فيه إلى أدلة فعلية.