معظم الـ skills تنفّذ شيئاً واحداً.
/arib-engine يشغّل حملة كاملة.
الفكرة بجملة واحدة
أعطه ملكية هدف — “استلم كخبير”، “صلّب الـ codebase”، “اصنع كل شيء” — فيُحوّل “حسّن هذا المشروع” إلى حملة تُدير نفسها وتُنهي نفسها:
- تكتشف الـ backlog بنفسها
- تُقرّر بنفسها ماذا تفعل الآن
- تتوقف حين يقول الدليل إنها انتهت — لا حين تأمرها
الحلقة التي يعمل عليها
discover → ship → verify → integrate → record
مكرّرة عبر PRs صغيرة وقابلة للتراجع، حتى يجتاز اختبار الإغلاق.
┌─────────────────────────────────────────┐
│ /arib-engine loop │
│ │
│ 1. DISCOVER → يجد العمل المتحقق منه │
│ ↓ │
│ 2. SHIP → PR صغير قابل للتراجع │
│ ↓ │
│ 3. VERIFY → يختبر بالدليل │
│ ↓ │
│ 4. INTEGRATE → يدمج إذا نجح │
│ ↓ │
│ 5. RECORD → يسجّل للذاكرة │
│ ↓ │
│ اختبار الإغلاق → نجح؟ توقّف. فشل؟ كرّر│
└─────────────────────────────────────────┘
ما الذي يجعله مختلفاً عن الـ 26 skill الأخرى؟
كل skill آخر يفعل شيئاً واحداً محدوداً — يراجع PR، يفحص الأمان، يُشغّل اختباراً. /arib-engine هو الوحيد الذي يفعل الثلاثة معاً:
١. يكتشف عمله بنفسه
لا تُخبره بقائمة المهام. يُجري مسح adversarial:
find → refute → confirm
عبر أبعاد متعددة — الأمان، حسابات المال، الأداء، الـ accessibility — ليُحدّد بنفسه ما يستحق الشحن.
٢. يعمل بشكل مستمر
مُقيَّد بـ /loop، يُكمل دورة بعد دورة بدلاً من الانتهاء في جولة واحدة. طالما اختبار الإغلاق لم يُجتَز، يواصل.
٣. يملك حكم “هل انتهينا؟”
يتوقف على اختبار إغلاق قائم على الدليل:
- الـ backlog مُستنفَد
- ما تبقّى قرارات للمشغّل فقط
- الـ trunk أخضر
ثم يُسلّمك قائمة القرارات — لا يُعيد السؤال “هل انتهينا؟” إليك.
الحدود التي يحترمها
الـ engine مستقل في ماذا يفعل بعد ومتى يُنهي — لكنه غير مستقل في القرارات الخطيرة:
- الـ merge إلى main يبقى بوابة بشرية أو branch protection
- قرارات الامتثال والتسعير والأمان تُصعَّد، لا تُتخذ بشكل منفرد
حالات الاستخدام — كيف تستدعيه
| تريد… | الأمر | ما يحدث |
|---|---|---|
| جولة واحدة مُركّزة | /arib-engine harden auth + payments | دورة discover→ship→verify واحدة، ثم يتوقف |
| حملة مستمرة | /loop /arib-engine <goal> | /loop يضبط الإيقاع؛ الـ engine يعمل حتى يجتاز اختبار الإغلاق |
| “اصنع كل شيء” | /arib-engine | Autonomous mode — يجد ويشحن كل تحسين مُتحقق، نزولاً بالخطورة |
| تنسيق الـ toolkit | /arib-engine --with-arib-family <goal> | يصبح المايسترو: يقود arib-check-* وarib-dev-* وarib-docs-* في كل مرحلة |
| دمج PRs الخضراء | /arib-engine --auto-merge <goal> | Opt-in فقط — أبداً لـ PRs المال والمصادقة والامتثال |
مستقل بشكل افتراضي
بدون --with-arib-family، الـ engine مكتفٍ بنفسه وقابل للنقل — ينفّذ كل مرحلة داخلياً ولا يمتد لمهارات أخرى حتى لو كانت مثبّتة.
تنسيق العائلة opt-in صارم.
متى هو الأداة الصحيحة؟
استخدمه لجهد مستمر — “افحص / صلّب / استمر في شحن القيمة عبر مخاوف متعددة.”
استخدم wave حين تعرف الخطة مسبقاً.
افعل الإصلاح مباشرة لمهام منفردة — محرّك الحملة مبالغة هنا.
الفرق عن wave overlay
| Wave | /arib-engine | |
|---|---|---|
| الخطة | تكتبها أنت | يكتشفها الـ engine |
| الإيقاع | جولة واحدة | مستمر حتى الإغلاق |
| “هل انتهينا؟” | تُقرّر أنت | يُقرّر الدليل |
| المناسب لـ | PLAN معروف | مشكلة مفتوحة |
المصدر
اعتُمد من منهجية AEPG (ADR-026). المرجع الكامل في:
reference/AUTONOMOUS_ENGINEERING_METHODOLOGY.md داخل claude-code-methodology
نُشر يونيو 2026