كيفاش تبني سيرورات متناسقة للبرمجة بالذكاء الاصطناعي باستعمال Viserys

شنو هو Viserys؟

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

المشروع كينظّم الخدمة البرمجية فدورة حياة من ست مراحل:

DEFINE -> PLAN -> BUILD -> VERIFY -> REVIEW -> SHIP

كل مسار عمل كاين فملف SKILL.md وكيشمل خطوات إجرائية، ومعايير الخروج، وتوجيهات ضد التبرير غير المنطقي. وحيت المهارات مكتوبة بـ Markdown عادي، يقدرو وكلاء البرمجة اللي كيدعمو المهارات يحمّلوها، أو تتقرا مباشرة كتعليمات مستقلة.

أهم المزايا

• تغطية دورة الحياة: المسارات كتشمل المتطلبات، والتخطيط، والتنفيذ، والاختبار، والمراجعة، والتحضير للإصدار.
• 26 مهارة جاهزة: المجلد skills/ فيه مسارات عمل هندسية قابلة لإعادة الاستعمال.
• شخصيات ديال المراجعين: وكلاء متخصصون كيقيّمو جودة الكود، والاختبارات، والأمان، وأداء الويب.
• التكامل مع OpenCode: كاين وكيل Viserys فالنمط الرئيسي، وكيحمّل المهارات بلا إعدادات عامة.
• مراجع مشتركة: يمكن تحميل لوائح التحقق وقت الحاجة بلا ما تبقى ديما داخل سياق الوكيل.
• التحقق والتقييم: سكريبتات Node.js كتفحص المهارات، والأوامر، ومسارات المخرجات، وروابط المراجع، والإصدارات، وحالات التقييم.

فهم بنية المستودع

• skills/ فيه مسارات عمل المهارات.
• agents/ فيه أربع شخصيات متخصصة لمراجعة الكود.
• references/ كيوفّر لوائح تحقق مشتركة عند الطلب.
• commands/ كيعرّف أوامر دورة الحياة.
• evals/ فيه حالات تقييم المهارات وملفات الاختبار.
• scripts/ فيه أدوات التحقق ومشغّل التقييم.
• hooks/ كيوفّر خطافات دورة حياة الجلسة.
• docs/ فيه التوثيق الداخلي.
• .opencode/agent/viserys.md كيعرّف وكيل OpenCode.
• .opencode/opencode.json كيسجّل مسارات المهارات فـ OpenCode.

التثبيت والإعداد

الخيار 1: تفعيل Viserys فـ OpenCode

1. نزّل مستودع Viserys باستعمال Git.
2. حلّ مجلد المستودع اللي نزّلتيه فـ OpenCode.
3. ضغط على Tab باش تفتح اختيار الوكيل.
4. اختار viserys.

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

الخيار 2: استعمال Viserys مع وكيل آخر كيدعم المهارات

بالنسبة لـ Claude Code أو Cursor أو أي وكيل آخر كيدعم المهارات القابلة لإعادة الاستعمال، وجّه الوكيل لمجلد skills/ ديال المستودع. ويمكن كذلك تنسخ هاد المجلد للمكان الأصلي ديال المهارات فالأداة.

المكان الدقيق كيعتمد على وكيل البرمجة. Viserys ما كيحتاجش تحويل مسارات Markdown ديالو لصيغة أخرى، ولكن خاص الأداة المضيفة تعرف فين تلقاهم.

الخيار 3: استعمال المهارات كسياق عادي

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

اختيار مسار العمل المناسب

بدا بالمهارة الوصفية using-agent-skills إلا ما كنتيش متأكد شنو هو مسار العمل المناسب. وإلا، اختار المهارة حسب مرحلة دورة الحياة الحالية.

DEFINE: وضّح الخدمة

• استعمل idea-refine ملي كتكون الفكرة غامضة وكتحتاج استكشاف منظّم.
• استعمل interview-me ملي خاص جمع المتطلبات سؤال بسؤال.
• استعمل spec-driven-development قبل ما تبدا مشروع أو ميزة أو تغيير مهم بلا مواصفات.
• استعمل constraint-driven-development ملي ما كاين حتى معيار للجودة أو كيتحايلو على الفحوصات غير باش يدوز البناء.

PLAN: حوّل المواصفات لمهام

من بعد ما تستقر المتطلبات، استعمل planning-and-task-breakdown. هاد المهارة كتحوّل المواصفات لمهام مرتبة وقابلة للتحقق، ومع كل مهمة معايير القبول ديالها.

BUILD: نفّذ بشكل مدروس

• incremental-implementation كتعاون باش التغييرات اللي كتمس ملفات متعددة تدخل على دفعات صغيرة.
• test-driven-development كتستعمل ملي كتطبّق منطق، أو كتصلّح خطأ، أو كتبدّل السلوك.
• context-engineering كتعاون فتهيئة الجلسة، وتبديل المهام، أو استرجاع الجودة ملي كتنقص جودة المخرجات.
• source-driven-development مناسبة ملي كتتوقف صحة النتيجة على التوثيق الرسمي الحالي.
• doubt-driven-development كتشجّع على التحقق ملي كتكون المخاطر كبيرة والتحقق دابا أرخص من تصحيح الأخطاء من بعد.
• frontend-ui-engineering كتوجّه خدمة الواجهات اللي كيشوفها المستخدم.
• api-and-interface-design كتعاون فتصميم واجهات API، وحدود الوحدات، والواجهات العامة.

VERIFY: برهن بلي التغيير خدام

• استعمل browser-testing-with-devtools فالتنفيذ أو تصحيح الأخطاء المرتبط بالمتصفح.
• استعمل debugging-and-error-recovery ملي كيفشل اختبار، أو كيتعطل البناء، أو كيكون سلوك وقت التشغيل غير متوقع.

REVIEW: قيّم الجودة والمخاطر

• خاص تستعمل code-review-and-quality قبل ما تدمج أي تغيير.
• code-simplification مفيد ملي كيكون الكود خدام ولكن صعيب يتفهم ولا يتصاين.
• security-and-hardening كيتطبق على مدخلات المستخدم، والمصادقة، وتخزين البيانات، والتكاملات الخارجية.
• performance-optimization كيتطبق ملي كاينة متطلبات ديال الأداء ولا كاين شك فشي تراجع.

الشحن: وجّد للإنتاج

• git-workflow-and-versioning كيوجّه تغييرات الكود وتدبير الإصدارات.
• ci-cd-and-automation كيساند تغييرات مسار البناء والنشر.
• deprecation-and-migration كيساعد تحيد الأنظمة القديمة ولا ترحّل المستخدمين.
• documentation-and-adrs كيسجّل القرارات المعمارية والتغييرات فواجهات API العمومية.
• observability-and-instrumentation كيغطي السجلات، والمقاييس، والتتبعات، والتنبيهات.
• shipping-and-launch كيوجّه التحضيرات النهائية للنشر فالإنتاج.

مثال أساسي على الاستعمال

فرضاً طلبتي من وكيل برمجة بالذكاء الاصطناعي يزيد نقطة نهاية جديدة فـ API محمية بالمصادقة. بلا ما يقفز مباشرة للتنفيذ، طبّق دورة الحياة بالترتيب.

1. التعريف: شغّل interview-me إلا كانت قواعد المصادقة، أو المدخلات، أو الاستجابات ماشي واضحة. من بعد استعمل spec-driven-development باش تحدد السلوك المنتظر.
2. التخطيط: طبّق planning-and-task-breakdown باش تخرج بمهام مرتبة ومعايير القبول.
3. البناء: استعمل api-and-interface-design لعقد نقطة النهاية، وtest-driven-development للسلوك. إلا كان خاص يتبدلو بزاف ديال الملفات، استعمل حتى incremental-implementation.
4. التحقق: إلا فشلات الاختبارات ولا تصرفت نقطة النهاية بشكل غير متوقع، تبع debugging-and-error-recovery.
5. المراجعة: طبّق code-review-and-quality وsecurity-and-hardening حيث الميزة كتتعامل مع المصادقة والمدخلات.
6. الشحن: استعمل مسارات Git والتوثيق وقابلية المراقبة والإطلاق المناسبة قبل النشر فالإنتاج.

مع تفعيل تكامل OpenCode، وكيل Viserys مصمم باش يقلب أولاً على المهارات المطابقة. فإعداد عادي بلا سياق مدمج، كتقوم بهاد الاختيار بنفسك وكتطلب من الوكيل يتبع كل مسار Markdown اخترتيه.

استعمل شخصيات المراجعين

Viserys فيه أربع شخصيات ديال المراجعين داخل agents/. كيعطيو وجهات نظر مركزة كتكمّل مهارات دورة الحياة.

• agents/code-reviewer.md كيدير مراجعة على خمسة محاور وفق معيار الموافقة ديال مهندس رئيسي.
• agents/test-engineer.md كيفحص استراتيجية الاختبارات والتغطية باستعمال نمط «برهن لي».
• agents/security-auditor.md كيغطي اكتشاف الثغرات، ونمذجة التهديدات، وتقييم OWASP.
• agents/web-performance-auditor.md كيراجع Core Web Vitals فأنماط سريعة ولا معمقة.

اختار الشخصية حسب المخاطر ديال التغيير. مثلاً، جمع مراجع الأمان مع security-and-hardening فخدمة المصادقة، ولا استعمل مراجع أداء الويب من بعد ما تبدل واجهة كيتعامل معها المستخدم.

تحقق من حزمة مسارات العمل

شغّل سكريبتات Node.js المرفقة من بعد ما تبدل المهارات، أو الأوامر، أو المراجع، أو الإصدارات، أو تركيبات التقييم:

node scripts/validate-skills.js
node scripts/validate-commands.js
node scripts/validate-artifact-paths.js
node scripts/validate-reference-links.js
node scripts/validate-versions.js
node scripts/run-evals.js

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

نصائح متقدمة

جمع المهارات بلا ما تفوّت مراحل دورة الحياة

ممكن مهمة تحتاج لأكثر من مهارة وحدة. ميزة ديال المتصفح، مثلاً، تقدر تجمع بين frontend-ui-engineering وtest-driven-development وbrowser-testing-with-devtools. خليهُم واضحين معايير الخروج ديال كل مهارة باش ما يتحولش جمع مسارات العمل إلى طلبات غير منظمة.

حمّل المراجع غير ملي تحتاجها

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

استعمل المصادر الرسمية فالأعمال الحساسة للإصدارات

طبّق source-driven-development ملي كتكون تفاصيل التنفيذ مرتبطة بالتوثيق الحالي. جمعو مع doubt-driven-development ملي يكون افتراض معقول ولكن غلط مكلف.

رجع للمسار ملي كتراجع جودة الوكيل

إلا ولات جلسة طويلة غير متناسقة، استعمل context-engineering. هاد المهارة مخصصة لإعداد الجلسة، وتبديل المهام، والحالات اللي كتنقص فيها جودة المخرجات.

راجع التوثيق المرفق

• docs/README.md كيشرح الحزمة وخريطة دورة الحياة.
• docs/skill-anatomy.md كيحدد صيغة SKILL.md.
• evals/README.md كيشرح كيفاش كيخدم تقييم المهارات.

قرا مواصفة بنية المهارة قبل ما تزيد مسارات العمل ولا تعاود تنظمها، ومن بعد شغّل أدوات التحقق والتقييمات باش تتأكد من النتيجة.

الخلاصة

Viserys كيحوّل التطوير بمساعدة الذكاء الاصطناعي إلى عملية هندسية قابلة للتكرار. بدا بربط مجلد skills/ بوكيل متوافق، ولا اختار وكيل Viserys المرفق فـ OpenCode. من بعد دوز بشكل مقصود عبر DEFINE وPLAN وBUILD وVERIFY وREVIEW وSHIP، واستعمل الشخصيات المتخصصة وسكريبتات التحقق فالأماكن اللي كيضيفو فيها قيمة.