DEMIURGOS يضيف وضع تصحيح القواعد لوكلاء AI ودعم أكثر من 20 أداة

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

لماذا يرتكب الوكلاء أخطاء

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

كيف يعمل DEMIURGOS

يحل DEMIURGOS هذه المشكلة من خلال نظام ثلاثي الطبقات. في قلبه يوجد المجلد .rules/، الذي يخزن مصدر الحقيقة حول المشروع: المجموعة التكنولوجية، الأنماط المعمارية، القيود، صيغة الاستجابات ومستويات الوصول.

فوقه يتم إنشاء محولات لأدوات محددة. بالنسبة إلى Cursor توجد ملفات قواعد خاصة بها، بالنسبة إلى Claude Code — CLAUDE.md، بالنسبة إلى GitHub Copilot — **.

github/copilot-instructions.md، وبالنسبة للآخرين يمكن استخدام AGENTS.md** كصيغة عامة.

الامتدادات المنفصلة مثل subagents و hooks و MCP تظهر فقط عندما تكون مطلوبة حقاً، وليس "للمستقبل". النهج لا يعتمد على مجلد جميل، بل على قابلية نقل القواعد بين الوكلاء وبيئات التطوير المتكاملة. يمكن لمطور واحد أن يعمل في Cursor، وآخر في Claude Code، وقائد فريق في Copilot، لكنهم جميعاً يحصلون على نفس الرؤية للمشروع بدون مزامنة يدوية للطلبات.

يدمج المؤلف أيضاً الحد الأدنى في النظام: قبل إنشاء ملف جديد، يتحقق ما إذا كان يحل مشكلة حقيقية أو ما إذا كان من الممكن الاكتفاء بسطر واحد في مستند موجود.

• مجموعة واحدة من القواعد تُخزن في المستودع وتدخل إلى git مع الكود
• تتيح المحولات ربط نفس التعليمات بـ Claude Code و Cursor و Copilot و Windsurf و Zed و Codex و Cline وأدوات أخرى
• قبل الإخراج، يشغل النظام 3–5 سيناريوهات نموذجية مثل إضافة نقطة نهاية واجهة برمجة تطبيقات أو إعادة هيكلة وحدة أو إصلاح خطأ في التفويض
• إذا كانت القاعدة تعيق أو تتداخل أو تكرر السياق المعروف بالفعل، يُقترح تخفيفها أو الارتقاء بها أو حذفها

ما يوفره /debug

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

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

md. في الأساس، /debug لا يقيّم القواعد من أجل التقييم، بل يساعد على رؤية تغطيتها بعد سلسلة من الطلبات الحقيقية. بعد 10–20 مهمة، من الواضح بالفعل أين يعتمد الوكيل بثقة على **.

rules/**، أين ينشط الاستدلالات الأصلية للنموذج، وأين يبدأ بالارتجال. هذا النمط مفيد بشكل خاص للفرق التي تبني تدريجياً نظام قواعدها الخاص ولا تريد إعادة كتابته بعمى بعد كل خطأ.

"القواعد ليست 'ضبط وانسيان'". هذا يحدد أيضاً منطق التحديثات: إذا حدث

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

ما يعنيه هذا

سوق وكلاء البرمجة ينتقل من الطلبات الفردية إلى البنية الأساسية الكاملة حولها. DEMIURGOS مثير للاهتمام ليس كمحادثة أخرى، بل كطبقة لإدارة سلوك الوكلاء في المستودع: مع المراجعة والمحولات والتدقيق والتغذية الراجعة. بالنسبة للفرق التي تعيش بالفعل في Claude Code أو Cursor أو Copilot أو Windsurf، هذه طريقة عملية لتقليل عدد الشروحات المتكررة وتقليل الضوضاء في الكود وجعل وكلاء الذكاء الاصطناعي يعملون بشكل متوقع أسرع.