20/06/2026
📚 الدليل الشامل لأنظمة AI Agent Orchestration (2026)
SDD_Pro vs GSD vs Agent OS vs BMAD vs SpecKit vs Superpowers
🎯 مقدمة: 4 فلسفات مختلفة
هذه الأنظمة ليست أدوات برمجة متنافسة، بل تمثل 4 مدارس فكرية مختلفة في كيفية توجيه الـ AI Agents:
الفلسفة المحور الأنظمة
🎯 Governance التحكم الصارم، الجودة، القابلية للتدقيق SDD_Pro
⚡ Ex*****on السرعة، التوازي، الإنتاجية GSD
🧩 Specification التخطيط، التصميم، التتبعية SpecKit
🏗️ Organization Simulation محاكاة فرق العمل BMAD, Agent OS
🪶 Lightweight Skills المرونة، البساطة Superpowers
1️⃣ SDD_Pro (Spec-Driven Development Pro) v7.0.0 GA
🏷️ الإصدار الحالي: v7.0.0 GA — تم وسمه في 2026-06-07
🏷️ LTS المحتفظ به: v6.10.4-LTS للمشاريع القديمة
🧭 الفكرة الأساسية (التصحيح)
SDD_Pro هو إطار حوكمة هندسي صارم يعمل داخل Claude Code فقط (ليس مستقل، ليس multi-model)، يحوّل دورة التطوير إلى pipeline قابل للتدقيق:
FEAT (مواصفة وظيفية)
→ User Stories (تقطيع ذري)
→ Architecture + ADRs
→ Backend Code (سلسلة)
→ API Gate (in-memory tests)
→ Frontend Code (موازي مع backend منتهي)
→ QA (tests + coverage + quality)
→ Auditors (Two-Stage Gate)
→ Final Verdict
القاعدة الذهبية: قراءة انتقائية (selective reading)، مقاومة الانحراف (anti-drift)، عزل صارم لكل US.
⚙️ الأوضاع الحقيقية (تصحيح)
❌ خطأ شائع: "3 أوضاع SDD-FULL / SDD-SELECTIVE / SDD-POC"
✅ الحقيقة: يوجد فعلياً وضعان رئيسيان + موجِّه ذكي:
🔴 /sdd-full {n} — الوضع الإنتاجي الصارم
12 LLM agents + 1 deterministic rubric
Two-Stage Gate v7.0.0+ (Stage A: spec-compliance → Stage B: code/security/arch in parallel)
API Gate إلزامي بين Backend و Frontend
4 auditors نشطة افتراضياً + 1 opt-in (adversarial-reviewer)
Coverage threshold + UI tokens + 174 classes خطأ مصنفة
مناسب: Enterprise, FinTech, HealthTech
🔵 /sdd-poc {n} — الوضع المختصر
يتخطى: US generation, QA, review, API gate
pipeline: FEAT → arch → backend → frontend فقط
مناسب: MVPs، prototypes، أفكار سريعة
🧠 complexity_router.py (موجِّه حتمي، 0 توكن)
Python pure (~50ms)
يحلل FEAT ويوصي بـ /sdd-poc أو /sdd-full أو /sdd-full --adversarial
ليس وضع تشغيل — بل سكريبت توصية قبل الاختيار
🏗️ المعمارية الحقيقية
┌─────────────────────────────────────────┐
│ Claude Code Runtime (Opus 4.7 / Sonnet) │
├─────────────────────────────────────────┤
│ 12 LLM Agents (.md prompts) │
│ • Core: po, arch, dev-back, dev-front│
│ • Support: elicitor, constitutioner, qa │
│ • Audit: 5 reviewers │
├─────────────────────────────────────────┤
│ Deterministic Python Layer (0 tokens) │
│ • complexity_router.py │
│ • phase_planner.py │
│ • preflight.py / validate_plan.py │
│ • detect_capabilities.py │
├─────────────────────────────────────────┤
│ State & Audit (SQLite console.db) │
│ • context_budget per agent │
│ • lock files (LibName, status) │
│ • auditor_runs ledger │
├─────────────────────────────────────────┤
│ 34 Stack Definitions (.md + .libs.json) │
│ • 25 🟢 validated (13 SLA combos) │
│ • 8 🟡 experimental + 1 🟡 POC-only │
└─────────────────────────────────────────┘
👥 الـ Agents الحقيقية (12 + 1)
الفئة Agent Model الدور
Core po Sonnet 4.6 Product Owner — تقطيع FEAT → User Stories
arch Sonnet 4.6 Architect — bootstrap + scaffolding DB
dev-backend Opus 4.7 تنفيذ backend لكل US
dev-frontend Opus 4.7 تنفيذ frontend مع UI fidelity
Support elicitor Sonnet 4.6 إثراء FEAT بـ 15 تقنية elicitation
constitutioner Sonnet 4.6 إدارة ADRs + constitution.md
qa Sonnet 4.6 Tests + coverage + API Gate
Auditors code-reviewer Sonnet 4.6 Anti-patterns cross-fichier
security-reviewer Sonnet 4.6 OWASP Top 10 + 8 hard-blocking
spec-compliance-reviewer Sonnet 4.6 AC-by-AC verification
arch-reviewer Sonnet 4.6 Layer violations + ADR drift
adversarial-reviewer Sonnet 4.6 Opt-in — Devil's advocate
Rubric complexity_router.py 0 tokens Python pure — توصية وضع التشغيل
🔄 دورة العمل الحقيقية
Phase 0 : Discovery (اختياري للمشاريع > 3 FEATs)
Phase 1 : /feat-generate → FEAT.md
Phase 1.5: /feat-deepen → elicitor (15 تقنيات)
Phase 2 : /us-generate → User Stories
Phase 2.6: /feat-validate → Readiness Gate (0-token, GO/NO-GO)
Phase 2.7: /dev-plan → خطط تقنية inline
Phase 3 : /arch-init → DB scaffolding + Project Config
Phase 4 : Backend ALL US → API Gate (in-memory)
Phase 5 : Frontend ALL US (موازي بعد API Gate) → fidelity check
Phase 6 : /qa-generate → tests + coverage
Phase 7 : /sdd-review → Two-Stage Audit (Sonar-style)
🧩 نقاط القوة الفعلية
✅ حوكمة عميقة: 174 class خطأ مصنفة، 13 contract load-bearing في INVARIANTS.yml
✅ Two-Stage Auditor Gate: يوفر ~3 invocations Sonnet عند فشل spec
✅ Backend-First: API Gate يمنع توليد frontend ضد contract مكسور
✅ Cost Cap: MaxCostPerRun (default $50) + BuildLoopMaxCostUsd ($15)
✅ File ownership matrix: تنفيذ موازي آمن (locks atomiques + atomic writes)
✅ Stack catalogs: 25 🟢 stacks + 13 combos SLA validated end-to-end
✅ Reverse Engineering: workflow منفصل لتحويل legacy → FEATs
⚠️ القيود الحقيقية
❌ مرتبط بـ Claude Code فقط (لا multi-model)
❌ تكلفة /sdd-full معتبرة على FEATs كبيرة (يخففها cost cap)
❌ Learning curve مرتفع — 13 commands + 8 rules + 12 agents
❌ يفترض stack من القائمة المدعومة (34 stack، خارجها = STOP)
🎯 الاستخدام الأمثل
✅ Enterprise systems قابلة للتدقيق
✅ FinTech / HealthTech / GovTech (compliance صارم)
✅ مشاريع طويلة العمر (constitution + ADRs)
✅ فرق متعددة على repo واحد (file ownership)
✅ Brownfield migration (عبر /sdd-discover-stack + workflow reverse)
2️⃣ GSD (Get S**t Done)
🧭 الفكرة
محرك تنفيذ موزع وسريع يستغل git worktrees لتشغيل agents بالتوازي على branches مستقلة.
🏗️ المعمارية
TypeScript SDK + Anthropic Agent SDK
State في .planning/ (git-tracked)
Multi-runtime: Claude / GPT / Gemini / Codex
Parallel waves via git worktrees
🔄 دورة العمل
Project → Research (multi-agents) → Planning
→ Parallel Ex*****on (waves) → Verification → Ship
✅ نقاط القوة
سرعة قصوى (worktree-level parallelism)
Multi-model (لا يلتزم بمزود واحد)
تكلفة منخفضة في التجارب
مرونة عالية
⚠️ القيود
Governance خفيف
لا audit gates إلزامية
مخاطر تصميم على المشاريع الكبيرة
🎯 مناسب لـ
Solo devs، startups، MVPs، AI experimentation
3️⃣ Agent OS
🧭 الفكرة
تحويل المشروع إلى نظام تشغيل للمعرفة بطبقات:
Vision → Product → Architecture → Tasks → Ex*****on
✅ نقاط القوة
إدارة context طويل المدى ممتازة
Persistence قوي
مناسب لـ SaaS متطور
⚠️ القيود
أبطأ من GSD
أقل صرامة من SDD_Pro
لا QA gates مدمجة
4️⃣ BMAD Method
🧭 الفكرة
محاكاة فريق شركة كامل داخل agents:
Role المهمة
Product Manager متطلبات + roadmap
Architect تصميم تقني
Developer تنفيذ
QA اختبار
Scrum Master تنسيق
✅ نقاط القوة
Enterprise workflow كامل
مناسب للفرق الكبيرة
تنظيم role-based قوي
⚠️ القيود
ثقيل (overhead دائم)
معقد على المشاريع الصغيرة
استهلاك توكنات عالٍ
5️⃣ SpecKit
🧭 الفكرة
Specification-First Development — كل شيء يبدأ بـ PRD.
✅ نقاط القوة
PRD + user stories + architecture
Traceability ممتازة
جودة تخطيط عالية
⚠️ القيود
لا ex*****on engine قوي
يعتمد على أدوات خارجية للتنفيذ
يتوقف عند مرحلة التصميم
6️⃣ Superpowers
🧭 الفكرة
نظام skills خفيف — يجمع workflows من سكريبتات بسيطة (بدون governance ثقيل).
✅ نقاط القوة
بساطة شديدة
مرونة عالية
سريع للتجربة
⚠️ القيود
لا governance
لا audit
محدود للمشاريع الصغيرة
📌 ملاحظة تاريخية: SDD_Pro v7.0.0 استعار بعض المفاهيم من Superpowers v5.1 (TDD skill، "do not trust the report" pattern، Two-Stage Gate principle)، لكن طبّقها داخل إطار حوكمة صارم.
⚔️ المقارنة الهندسية (CTO View)
1. مقاومة الهلوسة (Hallucination Resistance)
النظام التقييم السبب
SDD_Pro 🟢 9.5 174 error class + spec-compliance gate + INVARIANTS
SpecKit 🟢 9 (في مرحلة التخطيط فقط)
Agent OS 8.5 Context persistence جيد
BMAD 8 Role separation يقلل الانحراف
GSD 7 Verification stage اختياري
Superpowers 6.5 لا gates إلزامية
2. كفاءة التوكنات (Token Efficiency)
النظام التقييم ملاحظة
GSD 🟢 10 parallelism + multi-model
Superpowers 9 minimal overhead
SDD_Pro POC 9 skips QA/review/US
SDD_Pro FULL 6 Two-Stage Gate يوفر ~30% vs legacy parallel
SpecKit 7 كثيف في PRD
BMAD 4 role overhead دائم
3. السرعة (Speed)
النظام التقييم
GSD 🟢 10
SDD_Pro POC 9
Agent OS 7
BMAD 6
SDD_Pro FULL 5
4. جودة الكود النهائي
النظام التقييم السبب
SDD_Pro FULL 🟢 10 4 auditors + spec gate + API gate + coverage
Agent OS 9 layered design
BMAD 9 QA role
SpecKit 8.5 جودة التخطيط تنعكس
GSD 8 يعتمد على verification stage
Superpowers 7 بدون gates إلزامية
5. التوازي (Parallelism)
النظام التقييم الآلية
GSD 🟢 10 git worktrees
SDD_Pro 7 --max-parallel N (default 3) + file ownership locks
BMAD 7 role concurrency
Agent OS 7 task-level
SpecKit 5 sequential
6. القابلية للتدقيق (Auditability) ⭐ بُعد جديد
النظام التقييم الأدلة
SDD_Pro 🟢 10 ADRs + INVARIANTS + console.db + 174 error classes
BMAD 8 role logs
SpecKit 8 PRD traceability
Agent OS 7 knowledge layers
GSD 6 git history فقط
Superpowers 4 logs خفيفة
🧠 الخلاصة الحقيقية (بدون تسويق)
لا يوجد "أفضل نظام" — بل أفضل نظام لكل مرحلة من دورة حياة المنتج:
المرحلة النظام الموصى به السبب
💡 الفكرة + PRD SpecKit يلمع في التخطيط
⚡ MVP / Prototype GSD أو SDD_Pro POC سرعة + مرونة
🏗️ منتج SaaS Agent OS إدارة معرفة طويلة المدى
🏢 شركة كبيرة BMAD محاكاة فرق
🔒 إنتاج حرج SDD_Pro FULL الحوكمة الصارمة + audit gates
🔄 Legacy migration SDD_Pro Reverse workflow مخصص
🔥 Architecture Hybrid Design (الأقوى في 2026)
أقوى setup يستخدمه المتقدمون: دمج GSD و SDD_Pro في نفس المشروع.
📐 التصميم
┌──────────────────────────────────────────────────┐
│ GSD Layer (Experimentation) │
│ • Research multi-agents (multi-model) │
│ • Prototypes في git worktrees │
│ • تجارب سريعة، throw-away │
└──────────────────┬───────────────────────────────┘
│ promotion gate
▼
┌──────────────────────────────────────────────────┐
│ SDD_Pro Layer (Production) │
│ • FEAT formal من نتائج GSD │
│ • /feat-validate → Readiness Gate │
│ • /sdd-full → Two-Stage Audit │
│ • ADRs + constitution + INVARIANTS │
└──────────────────────────────────────────────────┘
🎯 القاعدة
GSD للاستكشاف والتجارب (workspace/experiments/)
SDD_Pro لكل ما يدخل workspace/output/src/ (production)
promotion gate: تجربة GSD ناجحة → تحويلها إلى FEAT.md → دخول pipeline SDD_Pro
✅ الفوائد
سرعة تجريبية + حوكمة إنتاجية
لا تعارض في الملفات (GSD في experiments/، SDD_Pro في output/src/)
ROI أعلى: لا تدفع cost SDD_Pro على أفكار قد لا تنجح
لا تشحن experimentation code إلى production
📌 ملاحظة ختامية
هذا الدليل مُصحَّح بناءً على معرفة مباشرة بـ SDD_Pro v7.0.0 GA (انظر CLAUDE.md + 8 rules + 12 agents). الأنظمة الأخرى (GSD، Agent OS، BMAD، SpecKit، Superpowers) موصوفة بناءً على معرفة عامة بفلسفتها — التفاصيل الدقيقة قد تتطلب مراجعة وثائقها الرسمية.
رقم 174 (error classes) و13 (SLA combos) وv7.0.0 GA (2026-06-07) كلها أرقام canonical من SDD_Pro نفسه، مُحَقَّقة بواسطة tests/test_invariants_manifest.py و framework_smoke.py.
