بنية ~/.claude لمكتبة تضم أكثر من 200 مهارة: كيف نحافظ على موجّه النظام ضمن 50 ألف رمز وندفع 0.15 دولار للجلسة

• حجم بادئة النظام: 40-50 ألف رمز (CLAUDE.md بحجم 8 آلاف رمز + القواعد (rules) بحجم 20-30 ألف رمز + الأوصاف بحجم 15 ألف رمز)
• التوفير عبر التخزين المؤقت للموجّهات (prompt caching): بمقدار 10 مرات (0.15 دولار للجلسة بدلاً من 1.50 دولار دون تخزين مؤقت)
• سرعة إنجاز العرض التقديمي: 6 دقائق و14 ثانية لإنتاج 12 شريحة (3.8 ميغابايت بصيغة PPTX)
• الحماية من حقن الموجّهات (prompt injections): 5 أطواق عزل مستقلة و3 عمليات حظر صارمة عبر PreToolUse

في ربيع عام 2025، حين لم يكن مصطلح «فايب كودينغ» (vibe coding) قد ظهر إلا للتو، ولم يكن عدد عمليات تثبيت Claude Code قد تجاوز الخمسة عشر مليونًا بعد، كنت أواجه مهمة إدارية بالمعنى الدقيق. فبصفتي رئيس المنتجات (CPO) في AlpinaGPT، كنت أغرق يوميًا في عشرات المكالمات ومسارات البريد الإلكتروني ومحادثات العمل: كانت الاتفاقات تضيع عند نقاط التقاء القنوات المختلفة. كنت بحاجة إلى عقل رقمي يعمل على مدار الساعة فوق قاعدة بيانات متجهة (vector database) واحدة، يربط بنفسه الوعود المنبثقة من اجتماعات Zoom بالرسائل الإلكترونية ويُنبّه مسبقًا بالمواعيد النهائية - وهذا هو النموذج الأولي لما تطوّر لاحقًا إلى بنية OpenClaw.

الوكيل الطرفي (terminal agent) الخام خارج الصندوق لا يعرف سوى عمليات القراءة والكتابة الأساسية للملفات. ولتحويله إلى منظومة هندسية متكاملة، قمت على مدار عام من التجارب ببناء نظام معياري من سبع طبقات داخل الدليل `~/.claude/`: ملف تنقّل `CLAUDE.md`، وقواعد ثابتة في `rules/`، ومهارات يتم تحميلها عند الطلب في `skills/`، ووكلاء فرعيين معزولين في `agents/`، وأوامر شرطة مائلة (slash commands) واضحة في `commands/`، وموصّلات خارجية `mcp.json`، ومعترضات مرتبطة بالأحداث (event hooks) في `hooks/`.

لماذا لا تُفرِط مكتبة تضم أكثر من 200 مهارة في ملء نافذة السياق ولا

تُفلس الميزانية في استهلاك الرموز؟

الخطأ الرئيسي عند تهيئة الوكيل هو جمع كل التعليمات في ملف `CLAUDE.md` الجذري، وتضخيمه حتى يبلغ 4000 سطر. فأي تعديل على هذا الملف الضخم الموحّد يُفرغ ذاكرة التخزين المؤقت (cache) لبادئة Anthropic، مما يفرض دفع السعر الكامل عند كل خطوة من الحوار. وفي بنيتي، ينفصل حجم مكتبة المهارات على القرص تمامًا عن حجم السياق النشط.

عند بدء الجلسة، لا يتم تحميل في الذاكرة سوى خريطة مكثّفة للموقع: ملف `CLAUDE.md` الجذري بحجم 200-300 سطر (نحو 8 آلاف رمز)، و20-25 ملف قواعد أساسية في `rules/` (20-30 ألف رمز)، وتعليقات توضيحية مختصرة للمهارات وخوادم MCP (15 ألف رمز أخرى). وتنحصر بادئة البدء الكاملة ضمن 40-50 ألف رمز، بينما تنتظر الكتلة الأساسية من التعليمات والنصوص البرمجية التي تزن نحو 300 ألف رمز دورها على القرص. ولأن البادئة تبقى ثابتة من طلب إلى آخر، تُفعَّل آلية التخزين المؤقت للموجّهات (prompt caching): فتُكلّف الجلسة 0.15 دولار بدلاً من 1.50 دولار، وتستغرق الاستجابة 1-2 ثانية. والقاعدة الأساسية للتشغيل هي عدم تحرير الملفات في `rules/` أبدًا في منتصف حوار جارٍ، واستخدام أمر `/compact` لضغط السجل بدلاً من مسحه بالكامل.

كيف يعمل التوجيه عبر routing.md والتوليد التلقائي للمهارات؟

حلقة الوصل في كل التهيئة هي جدول التوجيه `rules/routing.md` الذي يتجاوز 300 سطر، ويعمل وفق مبدأ «محفّز رئيسي ← أداة محددة». فإذا كانت مهمة ما تحدث أقل من مرة واحدة يوميًا، فلا مكان لها في القواعد الدائمة - بل تُصاغ كحزمة مستقلة في `~/.claude/skills/<name>/SKILL.md` مع نصوص برمجية تشغيلية داخلها.

مثال واضح على ذلك هو مولّد العروض التقديمية `manus-slides`. فعندما أكتب في الطرفية (terminal) طلبًا لعرض ترويجي للمستثمرين من 12 شريحة بأسلوب السبورة البيضاء (`whiteboard`)، يتولى جهاز التوجيه بثقة تبلغ 0.94 رصد المحفّز، ويُحمّل تعليمات بحجم 4.2 آلاف رمز، ويُشغّل خط المعالجة. يُنشئ Claude البنية، ويرسل بالتوازي 12 طلبًا إلى `gemini-3.1-flash-image-preview`، ثم يجمع عبر نصوص بايثون (Python) الملف النهائي `presentation.pptx` بحجم 3.8 ميغابايت. وتستغرق الدورة الكاملة 6 دقائق و14 ثانية بدلاً من يوم عمل كامل.

وبنفس المبدأ تعمل الغلاف البرمجي (wrapper) المبني على مكتبة Telethon (`tg_client.py` بأكثر من 50 أمرًا) لاستخراج التحليلات والإشارات من قنوات Telegram إلى ملفات CSV، وكذلك المهارة الفوقية (meta-skill) `skill-creator`. يكفي أن أطلب من الوكيل مرة واحدة إنشاء مهارة لتحليل كشوف حسابات بنكية بصيغة PDF - فيقوم تلقائيًا بإنشاء مجلد، وكتابة ترويسة YAML (YAML-frontmatter) تتضمن المحفّزات، ووضع نص برمجي مرافق، وتسجيل سطر في `routing.md`. وهذه هي البنية نفسها لمنظومة الذكاء الاصطناعي الشخصي المتكاملة التي نتناولها عمليًا في [Hamidun Academy](https://academy.hamidun.com) ونطوّرها داخل مجتمع المهندسين [Vibe Club](https://hamidun.com/club).

كيف نحمي وكيلًا مستقلًا يعمل في وضع bypassPermissions من حذف قاعدة

البيانات وحقن الموجّهات؟

أعمل في وضع `bypassPermissions` دون تأكيد يدوي على كل خطوة، لأن شبكة الأمان منقولة إلى مستوى بيئة التنفيذ. فعندما يقرأ الوكيل بريدًا إلكترونيًا لا يملكه، أو صفحات ويب، أو كودًا برمجيًا، تُعامَل البيانات الخارجية دائمًا كمحتوى غير موثوق، لا كأوامر.

يرتكز الأمان على خمسة خطوط دفاع: 1. عزل مادي للمفاتيح: تُخزَّن جميع الأسرار في ملف `~/.claude/.

credentials.master.env` خارج المستودع (repository)، وتُمرَّر إلى النصوص البرمجية عبر `os.

getenv()` - ولا يرى النموذج قيم `TELEGRAM_API_ID` أو مفاتيح الدفع داخل الحوار. 2. معترضات PreToolUse صارمة: مُسجَّلة في `settings.

json` ثلاثة معترضات خفيفة تُعيد فورًا `exit 1` عند أي محاولة استدعاء لأمر `rm -rf` أو `DROP DATABASE` أو `DROP TABLE`. 3. طوق قراءة فقط للمراجعين: يحصل الوكلاء الفرعيون المسؤولون عن تدقيق الكود والأمان، ضمن القائمة البيضاء، على صلاحيات `Read` و`Glob` و`Grep` فقط، دون حق الكتابة أو استدعاء الصدفة (shell).

4. تعقيم التدفق الوارد: يحذف النص البرمجي `gmail_search.py`، قبل تمرير نص البريد الإلكتروني إلى النموذج، عبارات مثل `ignore previous instructions`، ويستبدلها بعلامة `[REDACTED:injection]`.

5. القبول العدائي (adversarial acceptance) وتفويض المهام: قبل إطلاق أي روبوت (bot) جديد، أُجري عليه مجموعة اختبارات هجومية، وأوزّع المهام على الوكلاء الفرعيين من المستوى 0 (التنفيذ الذاتي) إلى المستوى 3 (منظّم مركزي + وحدات عمل في `git worktree` مع تحديد دقيق للملف والسطر).