دليل قراءة MuseAI-Skills: تحليل مهارات Muse AI والصلاحيات وسير عمل الوكلاء

شنو هو المشروع

MuseAI-Skills هو snapshot ديال بيئة Muse / Hatch الشخصية ديال AI Agent، مرتبط بـ muse.ai. الريبو كيحتافظ بوثائق المنتج، وتعريفات المهارات، ولائحة صلاحيات الـ connectors، وسيناريوهات تقييم السلوك، وسكريبتات التشغيل على Linux، وزيد عليهم بعض البرامج والاعتماديات المرفقة.

حدود مهمّة: هاد الريبو ماشي مستودع كامل ديال السورس كود، وماشي package قابل للتثبيت بكليك وحدة. البرامج الأساسية كيتقدمو أساساً فشكل binaries ديال Linux x86-64 ELF، بينما source ديال البناء، وconfig ديال الـ host كاملة، وrootfs، وبعض موارد التشغيل ما داخلينش فيه.

لهذا، هاد الريبو مناسب أكثر لـالقراءة الساكنة، ودراسة workflows ديال الـ Agent، وتحليل نموذج الصلاحيات، والرجوع ليه فتصميم التعليمات، وماشي للتثبيت المباشر ديال خدمة Muse AI. مواد الريبو كتستعمل أسماء Muse وHatch وJarvis، ولكن الأرشيف بوحدو ما كيمثلش نشر رسمي، ولا اعتراف، ولا توثيق للمصدر من طرف الجهة الرسمية.

شنو تقدر تتعلم من الريبو

البنية الكاملة ديال workflow ديال المهارات

الريبو فيه 72 مسار ديال SKILL.md، منهم 68 ملف مهارة مستقل و4 aliases على شكل symbolic links. المهارات كتغطي workflows ديال الـ Agent، والوثائق الناتجة، وحجوزات السفر، وأدوات المكتب، والمنصات الاجتماعية، وبيانات الصحة، وتوليد الميديا، والتحكم فالأجهزة، وعمليات منتجات Muse وغيرها.

هاد الوثائق ديال المهارات كتعاون غالباً فدراسة هاد الأسئلة:

• شنو هو طلب المستخدم اللي خاصو يفعّل المهارة.
• واش خاص المهمة يتكلف بها المنسّق، ولا worker، ولا connector خارجي.
• شنو هي connections ديال الحسابات، ولا OAuth scope، ولا موافقة المستخدم المطلوبة قبل التنفيذ.
• كيفاش يتم التعامل مع الفشل ديال الأدوات، ولا نقص المعطيات، ولا عدم كفاية الصلاحيات.
• كيفاش يتحدد format ديال النتيجة ويتدار التحقق من الـ deliverable النهائي.

مواد الصلاحيات والتقييم

الريبو فيه حتى 40 مسار ديال manifests و12 ملف eval بصيغة YAML. manifest.yaml يقدر يعاونك تفهم metadata ديال الـ connectors، والقيم الافتراضية ديال الصلاحيات، ومتطلبات الـ scope، والربط ديال الأوامر؛ أما eval/scenarios.yaml كيسجل سيناريوهات تقييم السلوك، وأهداف المستخدم، والسلوك المتوقع.

ملاحظة: وجود manifest ما كيعنيش بالضرورة أن الحساب مربوط، ووجود سيناريوهات التقييم ما كيعنيش أن التقييم تدار أو داز.

إشارات ساكنة على بيئة التشغيل

السكريبتات اللي فـ opt/hatch/runtime-cell/ كيبينو بعض مراحل دورة حياة بيئة التشغيل، ومنها تحديد مسارات rootfs، والتحضيرات اللي كتدار قبل الإقلاع، وفحص kernel modules، وتشغيل containers ديال systemd-nspawn، وتجميع overlays ديال المهارات والـ binaries. ولكن الـ host units كاملة، وconfig ديال nspawn، وrootfs الفعلي ما كاينينش فـ الريبو.

نظرة سريعة على بنية المجلدات

• README.md: المدخل بالصينية، وفهرس المهارات، وشرح الحدود.
• README.en.md: المدخل بالإنجليزية.
• PROJECT_ANALYSIS.md: الاستنتاجات المعمارية، والمكونات الناقصة، والمخاطر، وفهرس الأدلة.
• SHA256SUMS: لائحة التحقق من محتوى الملفات العادية، ولكنها ماشي توقيع للمصدر.
• home/hatch/docs/: وثائق على المنتج، والـ connectors، والخصوصية، والجدولة، والملفات، والأجهزة، والميديا وغيرها.
• home/hatch/config/: إعدادات مرتبطة بحالة الـ Agent والمهارات.
• opt/hatch/skills/: مداخل المهارات، وmanifests ديال الصلاحيات، وسيناريوهات التقييم، والمواد المرجعية.
• opt/hatch/runtime-cell/: سكريبتات دورة حياة بيئة التشغيل وقوالب الإعداد.
• opt/hatch/bin/: البرامج المرتبطة بـ Hatch.
• opt/hatch-image/: أدوات جانب image، وnpm، وBun، ومكونات أخرى مرفقة.

الجذر ديال الريبو غير هو جذر الأرشيف، وماشي جذر Linux اللي خدام دابا. home/hatch/ فالأرشيف كيقابل /home/hatch فـ البيئة الأصلية، بينما /run و/var/lib و/etc المذكورين فوثائق التشغيل كيشيرو غالباً لأنظمة ملفات runtime ناقصة.

الحصول على الريبو وتحضيرو

الخيار الأول: غير دراسة المهارات والوثائق

إلا كان الهدف هو تحليل ملفات Markdown وYAML وShell، تقدر تتجاوز binaries الكبيرة ديال Git LFS. هادي هي الطريقة الموصى بها أكثر للقراءة.

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills

هاد الطريقة ما كتحتاجش تشغّل البرامج المرفقة. منين تدخل للريبو، حل أولاً PROJECT_ANALYSIS.md وopt/hatch/skills/.

الخيار الثاني: تشوف كائنات الأرشيف كاملة

غير إلا كنت محتاج فعلاً تفحص برامج ELF الموجودة فـ LFS ولا ملفات كبيرة أخرى، خاصك تثبّت Git LFS وتجيب الكائنات المعنية. تحميل الـ binaries ما غاديش يكمل source الناقص، ولا rootfs، ولا credentials، ولا إعدادات الـ host، وما غاديش يحوّل الريبو لنظام قابل للنشر.

git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills
git lfs pull

بالنسبة للـ binaries اللي المصدر ديالها ما متوثقش بشكل مستقل، الأفضل تبدا بفحص ساكن offline، وما تشغّلهاش مباشرة فـ production ولا فبيئة فيها credentials حساسة.

التحقق من الملفات العادية

من بعد ما تجيب الملفات المعنية كاملة، تقدر تستعمل SHA256SUMS اللي جا مع الريبو باش تتحقق من سلامة المحتوى:

sha256sum -c SHA256SUMS

لائحة التحقق ما كتغطيش الملف ديال اللائحة نفسو ولا symbolic links، وماشي توقيع تشفيري لهوية الناشر ولا لصحة المصدر. كتعاون غير فمعرفة واش الملفات العادية المحلية مطابقة للـ digest المسجل فـ اللائحة.

الاستعمال الأساسي: بنِي workflow ديال قراءة المهارات

الخطوة الأولى: اختار مدخل ديال مهارة

فأول قراءة، تقدر تبدا بهاد المهارات:

• wide-research: منسّق البحث، والـ workers، وعقد الإخراج الموحد، وتغطية حالات الفشل.
• skill-creator: وصف تفعيل المهارة، وتقسيم المجلدات، والتحميل عند الحاجة للمواد المرجعية.
• artifacts/testing: التمييز بين “التوليد نجح” و“الـ deliverable قابل للاستعمال”.
• goals: التمييز بين إنشاء الهدف لأول مرة والمتابعة من بعد.
• forget: التعامل مع النسخ، والحالة المشتقة، والمعطيات اللي ممكن تعاود تكتب.
• travel-planning: فصل البحث على الرحلة، والاستعلامات الآنية، وتنفيذ المعاملة.
• gmail: تحليل الـ connector بجمع نص المهارة، والصلاحيات على مستوى الطريقة، وسيناريوهات التقييم.

مثلاً، باش تشوف مدخل مهارة Gmail:

sed -n '1,240p' opt/hatch/skills/gmail/SKILL.md

الخطوة الثانية: استخرج شروط التفعيل والحدود

منين كتقرا SKILL.md، ما تسجلش غير “شنو كتقدر تدير”، ولكن جاوب بالترتيب على هاد الأسئلة:

1. شنو هي الطلبات اللي خاصها تفعّل هاد المهارة؟
2. شنو هي الطلبات المشابهة اللي ما خاصهاش تفعّلها؟
3. كيفاش كنميّزو بين العمليات اللي غير كتقرا والعمليات اللي كتكتب؟
4. واش العمليات ذات التأثير الكبير بحال الإرسال، والحذف، والشراء، ولا الحجز كتحتاج تأكيد؟
5. كيفاش خاص يتدار التعامل مع نقص الصلاحيات، ولا غموض الهدف، ولا فشل الأداة؟
6. شنو هي الحقول ولا الأدلة اللي خاصها ترجع فالنتيجة النهائية؟

رتّب هاد العناصر فستة أجزاء: “التفعيل، والمدخلات، والتفويض، والتنفيذ، والفشل، والقبول”، باش يسهل نقلها لتصميم Agent ديالك.

الخطوة الثالثة: قارن مع permission manifest

بالنسبة لمهارات الـ connectors، كمّل بقراءة manifest.yaml اللي كاين فنفس المجلد:

sed -n '1,260p' opt/hatch/skills/gmail/manifest.yaml

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

نسخ SKILL.md لبيئة Agent أخرى ما كيمنحكش أوتوماتيكياً الولوج لـ Gmail ولا Google Drive ولا Notion ولا أي خدمة أخرى. التنفيذ الفعلي باقي متعلق بـ CLI ولا MCP المناسب، وربط الحساب، وOAuth scope، والتفويض فـ runtime.

الخطوة الرابعة: قرا سيناريوهات التقييم

إلا كانت المهارة فيها eval/scenarios.yaml، تقدر تشوف كيفاش كتتحول القواعد لسلوك قابل للاختبار:

sed -n '1,260p' opt/hatch/skills/gmail/eval/scenarios.yaml

سيناريوهات التقييم مناسبة باش تفحص هاد السلوكات:

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

ما تعتبرش ملفات السيناريوهات تقريراً على نجاح الاختبارات. إلا بغيتي تحكم على مشاكل تاريخية، تقدر حتى تقرا سجلات الاكتشاف بحال opt/hatch/skills/flightaware/eval/findings.md، ورد بالك للنسخة وبيئة الاختبار.

الخطوة الخامسة: فحص المواد المرجعية المرافقة

بعض المهارات كتقسم القواعد التفصيلية على references/ ولا guide/ ولا creation/ ولا guides/. هاد البنية كتبيّن مبدأ تصميم مهم: الملف الرئيسي ديال المهارة يبقى مختصر، وكتتحمّل المواد الأكثر تحديداً غير ملي كتحتاجها المهمة.

مثلاً، تقدر تبدا طريقة كتابة المهارات من هاد الملف:

sed -n '1,260p' opt/hatch/skills/skill-creator/references/authoring_guide.md

مثال عملي: تحليل مهارة Gmail

تقدر تستعمل هاد القالب باش تسجل تصميم مهارة Gmail بلا ما تربط ولا تستعمل البريد الإلكتروني فعلياً:

مدخل المهارة: opt/hatch/skills/gmail/SKILL.md
تعريف الصلاحيات: opt/hatch/skills/gmail/manifest.yaml
سيناريوهات التقييم: opt/hatch/skills/gmail/eval/scenarios.yaml

محاور التحليل:
1. شروط تفعيل البحث وقراءة الرسائل
2. حدود عمليات إنشاء المسودة والإرسال والرد
3. مسار الوسوم وإلغاء الاشتراك
4. الصلاحيات على مستوى الطريقة وOAuth scope
5. التعامل مع غموض المرسل إليهم، أو سلسلة الرسائل، أو نية العملية
6. طريقة الإبلاغ من بعد فشل الأداة
7. النتيجة ومعلومات التحقق اللي خاص المستخدم يتوصل بها فالآخر

من بعد، تقدر تحوّل النتيجة لمواصفات Agent ديالك:

• قواعد التفعيل: حدّد شنو هي الصيغ اللغوية اللي كتدخل لمهارة البريد.
• الأولوية للقراءة فقط: عالج البحث والقراءة بشكل منفصل على العمليات اللي كتغيّر المعطيات بحال الإرسال والحذف.
• عتبة التفويض: عاود عرّف قواعد التأكيد وOAuth حسب بيئة التشغيل المستهدفة.
• عقد الإخراج: حدّد شنو خاص يرجع فحالة النجاح، والنجاح الجزئي، والفشل.
• سيناريوهات القبول: زِد اختبارات للطلبات العادية، والطلبات الغامضة، وعدم كفاية الصلاحيات، وأعطال الـ connector.

قراءة بنية المنتج والنظام

فهم سريع لعقد المنتج

من الأفضل تقرا بالترتيب:

1. home/hatch/docs/muse.md: نظرة عامة على المنتج.
2. home/hatch/docs/goals.md: الأهداف، التقدّم، والحدود ديال الخدمة فالخلفية.
3. home/hatch/docs/scheduling-and-watching.md: الاستطلاع، الجدولة، تاريخ التشغيل والإشعارات.
4. home/hatch/docs/self_improvement.md: الذاكرة فالخلفية، البحث، المراجعة وتتبع الأدلة.
5. home/hatch/docs/connectors.md: حالة الربط، OAuth، صلاحيات الطرق ومعالجة الفشل.
6. home/hatch/docs/privacy-and-credentials.md: مراجع بيانات الاعتماد، Vault، قواعد التصدير والحذف.

هاد الملفات كتوصّف عقد المنتج فداك snapshot. القدرات الخاصة بالحساب وشرح التوفّر التاريخي ما خاصّهاش تتعتبر مباشرة حقائق متوفّرة عند جميع حسابات Muse الحالية.

سلسلة تشغيل بيئة البحث

إلى كنت مهتم ببيئة العزل ديال Linux، تقدر تبني علاقات الاستدعاء انطلاقاً من السكريبتات التالية:

opt/hatch/runtime-cell/pre-start.sh
opt/hatch/runtime-cell/ensure-rootfs.sh
opt/hatch/runtime-cell/resolve-rootfs-path.sh
opt/hatch/runtime-cell/require-modules.sh
opt/hatch/runtime-cell/launch-daemon.sh
opt/hatch/runtime-cell/post-start.sh

resolve-rootfs-path.sh كيرجّع /var/lib/hatch-runtime/rootfs، وهو مسار فبيئة التشغيل الأصلية، وماشي مجلد مرفق مع المستودع. launch-daemon.sh كيشغّل حاوية systemd-nspawn وكيركّب overlay؛ وما يقدرش بوحدو يشكّل درس تشغيل مستقل بلا إعدادات المضيف وrootfs الناقصين.

تقنيات متقدمة فالتحليل

التمييز بين المهارات، الأسماء البديلة ومجلدات الموارد

فالمستودع كاينين 4 ديال الأسماء البديلة على شكل روابط رمزية: facebook كيشير لـ facebook-cli، وmeta-threads كيشير لـ threads، وpodcast كيشير لـ generate_podcast، وvoice-calls كيشير لـ voice-selector.

فحص الهدف الحقيقي ديال الروابط كيعاون على تفادي الإحصاء المكرّر:

find opt/hatch/skills -type l -name SKILL.md -print -exec readlink {} \;

وبالخصوص، ما يمكنش نستنتجو من اسم voice-calls أنه عندو القدرة على إجراء مكالمات هاتفية نيابةً عن Agent؛ هاد المدخل كيشير فعلياً لدليل صوتي ثابت. spaces فيه وثائق وقوالب ديال وقت التشغيل، ولكن ما فيهش SKILL.md فالمستوى الأعلى، وبالتالي ما خاصّوش يتحسب كمهارة إضافية.

التحقق في نفس الوقت من التصريحات والصلاحيات والاعتماديات القابلة للتنفيذ

ملي كتْحلّل شي مهارة، تقدر تعتمد طريقة التحقق من ثلاث طبقات:

1. طبقة السلوك: فحص التفعيلات، الحدود والمخرجات المصرّح بها فـ SKILL.md.
2. طبقة الصلاحيات: فحص الطرق، النطاقات والصلاحيات الافتراضية فـ manifest.
3. طبقة التنفيذ: التأكد واش CLI وMCP والبرامج المساعدة وربط الحساب وموارد وقت التشغيل المطلوبة موجودة.

المستودع كيوضّح أنه ناقص بعض الاعتماديات الأساسية، من بينها سكريبتات التحقق ديال Artifacts، وscaffolding ديال الموصلات فـ skill-creator، والبرنامج التنفيذي mm ديال Magic Moment، وزيد بعض SDK وموارد البناء اللي محتاجاها Spaces. لذلك، «الوثائق قابلة للقراءة» ما كتعنيش أن «سلسلة التنفيذ كاملة».

الفصل بين إنشاء المخرجات وقبولها

artifacts/testing كيستاهل يتدرس كنمط عام ديال Agent. كيشدّد على أنه من بعد إنشاء الملفات، خاصها تتفحص حسب نوع المخرج، ويتعاود تصييرها، وتتراجع بصرياً، ويتدار مسح للـ placeholders. ملي كتطبّق هاد الشي فالنظام ديالك، تقدر تقسّم المسار هكذا:

1. إنشاء وثائق، جداول، PDF أو عروض تقديمية.
2. إعادة فتح أو تصيير النتيجة المُنشأة.
3. فحص البنية، التخطيط، الصيغ، الروابط والموارد الناقصة.
4. البحث على placeholders والنصوص المؤقتة اللي ما تبدلاتش.
5. غير من بعد ما يدوز الملف القبول، يتعلّم بأنه قابل للتسليم.

دراسة التعاون بين عدة Agents

wide-research كيعرض القيود الأساسية فالبحث الموازي متعدد المدخلات: تحديد مسؤوليات المنسّق والـ worker، توحيد حقول المخرجات، الإبلاغ على نسبة التغطية، والاحتفاظ بالعناصر الفاشلة. فالتطبيق ديالو فمشروع آخر، خاصك تبدّل أسماء الأدوات ومسارات مساحة العمل حسب إطار التنسيق ديالك، مع الحفاظ على عقد موحّد للمخرجات وإمكانية رؤية حالات الفشل.

فحص شرح قاعدة البيانات بدل البحث على قاعدة البيانات

opt/hatch/skills/muse_db/references/schema.md كيشرح قواعد SQL المقيّدة، المعرّفات والعلاقات فعدة schemas، وكيقدر يعاون على فهم نموذج البيانات وطريقة التتبع بين الجداول. هاد الملف ماشي قاعدة البيانات الفعلية، وماشي مصدر ديال الترحيل، وما يمكنش نعتمدو عليه لاسترجاع الخدمة كاملة.

الحفاظ على المصدر والرخص وحدود الأدلة

ملي كتنقل workflow لمشاريع أخرى، خاصك تحافظ على نسب المصدر وتتحقق من الرخص اللي كتنطبق. من الأحسن تميّز فالسجل الداخلي ديال التحليل بين:

• الحقائق اللي كيصرّح بها المستودع مباشرة.
• الاستنتاجات التقنية المبنية على المجلدات أو السكريبتات أو manifest.
• تصريحات المنتج اللي مازال ما تْتحقّقش.
• السلوكيات اللي ما يمكنش التأكد منها بسبب غياب بيئة التشغيل.

«ظاهر فالأرشيف» ما كتعنيش «مصادق عليه من المصدر الرسمي» أو «قابل للتشغيل بشكل مستقل» أو «يمكن إعادة ترخيصه بلا قيود».

مسار تعلّم مقترح

1. ملي كتعمل clone للمستودع، تخطّى LFS باش تتفادى تحميل الثنائيات بلا حاجة.
2. قرا PROJECT_ANALYSIS.md باش تفهم التقييم المعماري والعناصر الناقصة.
3. اختار skill-creator أو wide-research لتعلّم بنية الـ workflow.
4. اختار gmail وحلّل مع بعض النص الكامل ديال المهارة وmanifest وeval.
5. قرا artifacts/testing وبني عقلية التحقق من المخرجات قبل التسليم.
6. قرا وثائق المنتج وميّز بين قواعد المهارات وعقد المنتج.
7. وفالأخير، راجع سكريبتات runtime-cell باش تفهم إشارات وقت التشغيل والاعتماديات الناقصة.

الخلاصة

القيمة الرئيسية ديال MuseAI-Skills ماشي فالنشر المباشر، ولكن فإظهار كيفاش يقدر Agent شخصي بالذكاء الاصطناعي ينظّم تفعيل المهارات، توجيه المهام، صلاحيات الموصلات، معالجة الفشل وقبول النتائج. ملي كتقرا SKILL.md وmanifest.yaml وسيناريوهات التقييم واعتماديات التشغيل مجموعين، تقدر تستخرج أنماط تصميم صالحة لنظام Agent ديالك، وفنفس الوقت تتفادى اعتبار snapshot مصدراً كاملاً أو منتجاً قابلاً للتنفيذ.