كيف تشارك مهارات الوكيل بين المستودعات دون اختلافات

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

لمشاركة مهارات الوكيل بين المستودعات، توقّف عن نسخ الملف وابدأ بالاعتماد عليه. احتفظ بمستودع واحد للمهارات، وأنشئ له tag، ودَع كل مشروع يثبّت tag محدداً. ثم أضف اختبار smoke لكل مهارة، وراجع كل تحديث بالطريقة نفسها التي تراجع بها تحديث dependency.

يتكوّن ذلك من أربعة أجزاء: مصدر موحّد للحقيقة، وإصدار مثبّت لكل مستودع، واختبار smoke لكل مهارة، ومسار للمراجعة. يشرح كل ما يلي سبب وجود كل جزء، وكيف تتعامل الأدوات التي تُصدر في 2026 مع ذلك، وكيف تبني المنظومة كاملة على git remote مستضاف ذاتياً من دون استخدام أي خدمة خارجية.

مهارة الوكيل هي مجلد يحتوي على ملف SKILL.md، إضافة إلى أي scripts وreference files يحتاج إليها. إذا كانت هذه الوحدة جديدة عليك، فاقرأ ما هي مهارة الوكيل وكيف يعمل SKILL.md أولاً. تتناول هذه الصفحة سلسلة التوريد المحيطة بهذه الوحدة.

موضع المهارة، ولماذا يصعب مشاركتها

يحمّل Claude Code المهارات من ثلاثة مواضع، وتذكر وثائق المهارات كل مسار.

• ~/.claude/skills/<skill-name>/SKILL.md شخصي. يُحمَّل في جميع مشاريعك، وليس في مشاريع أي شخص آخر.
• .claude/skills/<skill-name>/SKILL.md على مستوى المشروع. يُحمَّل لكل من يستنسخ ذلك المستودع.
• <plugin>/skills/<skill-name>/SKILL.md مضمَّن داخل إضافة. يُحمَّل أينما كانت تلك الإضافة مفعّلة.

الموضع الثاني هو المفيد للفريق، لأنه يُحفظ في المستودع ويحصل عليه كل من يستنسخه. لكنه أيضاً موضع بداية المشكلة. تنتمي المهارة الموجودة في .claude/skills/ إلى مستودع واحد. لديك ثمانية مستودعات. لذلك تُنسخ المهارة ثماني مرات.

لا تساعدك البيانات الوصفية في بداية الملف. تسمح مواصفة Agent Skills بستة مفاتيح، وتطبع مسارات التوزيع التي تفرض هذه المواصفة القائمة عند استخدام مفتاح آخر:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

لاحظ ما هو غائب: لا يوجد مفتاح version. لا يسجل أي شيء داخل الملف أي نسخة أحدث. وهذا منطقي، لأن المهارة مستند وليست حزمة. لكنه يعني أن إدارة الإصدارات يجب أن تأتي من الطبقة المحيطة بالملف، وهذه الطبقة مسؤوليتك.

المشكلة الأولى: ثماني نسخ تتباعد بصمت

ينجح النسخ واللصق في اليوم الأول، لكنه يفشل في اليوم الستين. يصحح أحدهم تعليمة خاطئة في مستودع payments، ولا يلمس المستودعات السبعة الأخرى. ويضيف شخص آخر قاعدة تتعلق بترقيم الصفحات في orders. الآن يعطي اسم المهارة نفسه مراجعتين مختلفتين، وفقاً للدليل الذي بدأ منه الوكيل، ولا يعرف أيٌّ من المطورين سبب ذلك.

يظل الفشل صامتاً لأنه لا توجد حالة خطأ. المهارة نص نثري. تنتج التعليمة القديمة إجابة واثقة وخاطئة، وهذا هو النوع المكلف من الأخطاء. لا يقارن الوكيل نسختك بنسخ الآخرين، لذلك تكون الإشارة الوحيدة هي أن يلاحظ شخص ما اختلاف مستودعين.

المشكلة الثانية: لا شيء يثبّت الإصدار

حتى عندما يحتفظ الفريق بالمهارات في مكان واحد، تكون طريقة المشاركة المعتادة هي خطوة نسخ: نص إعداد، أو سطر curl في مستند تهيئة الحساب، أو اسم مستعار للصدفة يزامن مجلداً. كل هذه الطرق تثبّت الإصدار الموجود حالياً عند رأس الفرع.

هذا يعني أن مطوّرين يعملان على الالتزام نفسه للتطبيق نفسه قد يشغّلان تعليمات مختلفة، لأنهما نفّذا المزامنة في يومين مختلفين. ويعني أيضاً أنك لا تستطيع الإجابة عن السؤال المهم بعد تشغيل وكيل بشكل سيئ: ما إصدار المهارة الذي أنتج هذه النتيجة؟ من دون مراجعة مسجّلة، لا يمكن إعادة إنتاج التشغيل، ولذلك لا يكون تقرير الخطأ قابلاً لاتخاذ إجراء.

المشكلة الثالثة: لا أحد يعرف ما إذا كانت المهارة ما تزال تعمل

لا تملك المهارة مترجماً برمجياً. فهي تعليمات موجّهة إلى نموذج، ولذلك قد تتوقف عن العمل بينما يبقى الملف مطابقاً تماماً بايتاً ببايت. قد تؤدي ترقية النموذج إلى تغيير مدى التزامه بتعليمات طويلة. وقد تعيد أداة سطر الأوامر التي تستدعيها المهارة تسمية أحد الخيارات. وقد يبدأ عنوان URL في ملف مرجعي بإرجاع 404، فيعمل الوكيل اعتماداً على صفحة الخطأ.

لا يفشل أي من هذه الحالات بطريقة واضحة. يواصل الوكيل تقديم الإجابات. لكنها تصبح أسوأ مما كانت عليه في الشهر الماضي، ومن الصعب ملاحظة ذلك مع كل pull request على حدة.

ما الذي تعالجه الأدوات التي تصدر في 2026

تصل عدة إجابات الآن، لكنها تختلف بشأن المكان الذي يجب أن يوجد فيه الإصدار.

ملفات القفل. أداة سطر الأوامر skills من Vercel Labs (vercel-labs/skills، بترخيص MIT، وإصدارها v1.5.22 في 5 August 2026) تثبّت المهارات من مستودع git في أي دليل يتوقعه وكيلك، وهي تعرف بنية أكثر من سبعين وكيلاً. تنفّذ npx skills add <repo> التثبيت، وتنفّذ npx skills update الترقية، وتعرض npx skills list ما لديك. يُحفظ سجل ما هو مثبت مرة واحدة لكل مستخدم، بدلاً من حفظه مرة واحدة لكل مستودع. ويطلب طلب مفتوح في ذلك المشروع (issue 283) إضافة أمر skills install يعيد تثبيت كل مهارة متتبعة من ملف القفل، بحيث تحصل آلة ثانية على المجموعة نفسها. تعامل مع ذلك الطلب بوصفه تقريراً عن الحالة. فكرة ملف القفل محسومة. أما الجزء الخاص بكل مشروع، فما زال قيد البناء.

المواصفات والاختبارات. تتخذ SkillSpec الاتجاه الآخر. فهي تتعامل مع SKILL.md بوصفه عقداً يجب التحقق منه، لا نصاً يُوثق به، والهدف المعلن هو جعل المهارات "قابلة للاتباع والاختبار والإثبات". يحدد skillspec doctor <path> المواضع التي يُرجح أن يفقد فيها الوكيل سياق التنفيذ. ويحدد skillspec boundary map <path> ما يمكن للمهارة الوصول إليه، بينما يرتب skillspec boundary assess <path> هذه النتائج حسب مستوى الخطر. وهي حزمة Rust بترخيص مزدوج MIT أو Apache 2.0، وإصدارها 0.2.2 في 29 July 2026. ثبّت الإصدار المحدد بدلاً من تثبيت الإصدار الأحدث:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

يُنشئ --locked الحزمة باستخدام إصدارات التبعيات التي نُشرت معها، لذلك لا تتغير نتيجة البناء دون علمك. يجب أن يطبع skillspec --version القيمة 0.2.2. ويعني ظهور رقم مختلف أن ملفاً ثنائياً أقدم في PATH لديك هو الذي يُستخدم.

ممارسات المورّد. شرحت Google كيف تبني المهارات في google/skills ضمن منشور عن كيفية بناء مهارات الوكلاء واختبارها وتوسيع نطاقها. وبعيداً عن حجم العمل، فإن الآلية هي التكامل المستمر المعتاد (CI). تمرر كل مهارة أدوات فحص للبيانات الوصفية في frontmatter، وعدد الأسطر، وبنية الدليل، والتسمية قبل دمجها. وتفشل أداة فحص الروابط عملية البناء عند أي URL يعيد 404، ما يكشف الرابط المعقول الذي اخترعه وكيل. يجب على المؤلفين توفير مجموعة prompts للتقييم ومقياس للتقييم إلى جانب المهارة. ثم تشغّل مهام تقييم مجدولة اختبارات أسبوعية على المكتبة بأكملها لاكتشاف التراجعات، ولكل مهارة مالك محدد يُتوقع منه إصلاحها عند انخفاض الجودة.

النمط المشترك بين الإجابات الثلاث

لست مضطراً إلى اختيار أحدها. يوجد تحتها نمط واحد، ويوفّر لك git الأساسي كل ما تحتاج إليه.

1. مصدر واحد للحقيقة. لكل skill موضع واحد فقط، ويشير كل مستودع إلى ذلك الموضع بدلاً من الاحتفاظ بنسخة.
2. إصدار محدد لكل مستودع. يسجل كل مشروع المراجعة الدقيقة التي يستخدمها، لذلك تصبح الترقية commit في ذلك المشروع، مع مؤلف وتاريخ.
3. اختبار smoke test لكل skill. فحص واحد قابل للتنفيذ يثبت أن skill ما زال ينتج النتيجة التي يَعِد بها.
4. مسار للمراجعة. يمر التغيير الذي يطرأ على skill مشترك عبر المراجعة، ويطّلع كل مستهلك على diff قبل اعتماده.

هذا هو نمط dependency. أصبحت skills artifacts مشتركة قبل أن تنمو الأدوات المحيطة بها بالسرعة نفسها، لذلك فإن استخدام الأدوات التي تثق بها بالفعل هو الخيار الأكثر أماناً.

تخطيط لفريق صغير على مستودع Git مستضاف ذاتياً

يحتوي مستودع واحد على المهارات. ولا توجد فيه أي ملفات أخرى، لذلك يعرض سجله تاريخاً للتغييرات على التعليمات.

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

الإصدارات هي وسوم. استخدم الوسوم المشروحة، لأنها تتضمن رسالة وتاريخاً. اكتب الرسالة باعتبارها السبب الذي يجعل المستهلك يرغب في الترقية:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

إذا كان remote لديك هو Gitea أو Forgejo أو GitLab أو مستودعاً عارياً عبر SSH على VPS تملكه، فلن يتغير أي مما يلي. كل ما في الأمر هو git ورابط رمزي.

التثبيت باستخدام وحدة git الفرعية

تسجّل الوحدة الفرعية commit واحداً محدداً من مستودع آخر داخل مستودعك. هذا السجل هو التثبيت. في كل مشروع مستهلك:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

الرابط الرمزي هو الجزء الذي يجعل ذلك ممكناً. قد يكون إدخال skill على مستوى المشروع رابطاً رمزياً إلى دليل آخر على القرص، ويتبعه Claude Code ويقرأ SKILL.md من الهدف. لذلك تُحمَّل skill كمهارة عادية للمشروع، بينما تكون الملفات موجودة في الوحدة الفرعية عند commit اخترته.

تحقق من التثبيت:

git submodule status

يبدأ السطر السليم بمسافة، ثم commit، ثم المسار، ثم أقرب وسم:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

تعني - في بداية السطر أن الوحدة الفرعية لم تتم تهيئتها مطلقاً، ولذلك يشير .claude/skills/api-review إلى لا شيء ولا تُحمَّل skill بصمت. أصلح ذلك باستخدام git submodule update --init. وتعني + في بداية السطر أن commit الذي تم سحبه يختلف عن commit المسجّل، ولذلك يشغّل ذلك المطوّر تعليمات لا يملكها أي شخص آخر. تحتاج النسخ المستنسخة حديثاً إلى git clone --recurse-submodules، ويجب أن يذكر README هذا الأمر، لأن الاستنساخ العادي يترك vendor/agent-skills فارغاً ولا يطبع أي خطأ.

الترقية عملية مقصودة، وهذا هو الهدف منها:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

يمثل السطر diff مسار المراجعة. فهو يعرض التغيير نفسه الذي سيراه كل مستودع مستهلك آخر، ويناسب وضعه في pull request.

التثبيت بالإصدار المحدد باستخدام سوق الإضافات بدلاً من ذلك

إذا كنت تفضّل ألا تطلب من كل مطوّر تعلّم الوحدات الفرعية، فإن نظام إضافات Claude Code يتولى التوزيع نيابةً عنك، ويعمل مع مستودع remote مستضاف ذاتياً. ضع كتالوجاً في .claude-plugin/marketplace.json ضمن مستودع المهارات:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

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

بعد ذلك، يعلن كل مستودع مستهلك عن marketplace في ملف .claude/settings.json المضمّن فيه:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

يُطلب من زميل يثق بمجلد المشروع تثبيت marketplace، وتُفعّل الإضافة لديه دون الحاجة إلى صفحة wiki تطلب منه تنفيذ ذلك. بعد ذلك تُستدعى المهارات باستخدام /team-skills:api-review، لأن مهارات الإضافات تستخدم مساحة أسماء مشتقة من اسم الإضافة ولا يمكن أن تتعارض مع مهارة مشروع تحمل الاسم نفسه. بعد دفع وسم جديد، يحدّث المستهلكون المحتوى باستخدام /plugin marketplace update acme-agents، ثم يشغّلون /reload-plugins إذا طلب ملخص التثبيت ذلك.

كتابة اختبار دخاني لمهارة واحدة

الاختبار الدخاني هو تشغيل وكيل مبرمج مقابل fixture يحتوي على عطل معروف، مع assertion واحدة. يعمل Claude Code دون تفاعل باستخدام -p، وتعمل المهارة التي يستدعيها المستخدم في هذه الحالة: ضع /skill-name في سلسلة المطالبة، وسيُوسَّع قبل بدء التشغيل.

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md هو ملف قصير يحتوي على عطل متعمد واحد. تتمثل assertion في أن تسمّيه المهارة. يخرج jq -e بحالة غير صفرية عندما ينتج عامل التصفية الخاص به null، ولذلك يفشل البرنامج النصي إذا توقفت المهارة عن اكتشاف العطل المُضمَّن. ويخرج claude بحالة غير صفرية عندما يفشل التشغيل، بينما يحوّل set -euo pipefail أيّاً من الفشلين إلى اختبار فاشل.

يعيد النموذج صياغة إجاباته بين عمليات التشغيل، لذلك لا تُجرِ assertion على جملة كاملة. أجرِ assertion على معرّف يفترض أن تُصدره المهارة، أو على حقل في schema طلبته، واجعل fixture صغيراً حتى يبقى التشغيل منخفض التكلفة.

في CI، أضف --bare. من دونه، يحمّل claude -p السياق نفسه الذي ستحمّله جلسة تفاعلية، بما في ذلك hooks وplugins وCLAUDE.md من الجهاز الذي يعمل عليه. لذلك قد يغيّر إعداد أحد أعضاء الفريق الشخصي النتيجة. يتجاوز الوضع العاري كل الاكتشاف التلقائي، ما يعني أنه يتجاوز المهارة التي تختبرها أيضاً، لذا حمّل تلك المهارة صراحةً. لا يقرأ الوضع العاري بيانات تسجيل الدخول إلى الاشتراك، لذلك عيّن ANTHROPIC_API_KEY في البيئة أولاً:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

باستخدام --output-format stream-json، يوضّح الحدث الأول في التشغيل أي plugins تم تحميلها، ويتضمن مصفوفة plugin_errors للـplugins التي لم يتم تحميلها. اجعل مهمة CI تفشل عندما تكون plugin_errors غير فارغة. يكتشف ذلك وجود pin يشير إلى revision لم يعد موجوداً، وهي حالة تظهر خلاف ذلك على شكل تجاهل الوكيل بهدوء لقواعدك المعتمدة.

التعليمة المشتركة القابلة للتنفيذ هي مهارة

تجعل ميزتان هذه العبارة حرفية، وكلتاهما مهمتان عندما يأتي الملف من فريق آخر.

أولاً، يمكن لـ SKILL.md تشغيل أوامر shell قبل أن يقرأ النموذج أي شيء. سطر مثل هذا في النص الأساسي هو معالجة مسبقة:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

يُنفَّذ الأمر على الجهاز الذي يحمّل المهارة، ويحل ناتجه محل العنصر النائب في النص الذي يتلقاه النموذج. كما تُنفَّذ عدة أوامر بالطريقة نفسها عند فتح كتلة محاطة بثلاث علامات backticks متبوعة بـ !. لا يوافق أحد على أي من ذلك أثناء وقت التشغيل. تعني قراءة مهارة مشتركة قراءة استبدالات الأوامر التي تتضمنها.

ثانياً، يمكن لـ frontmatter منح الأدوات موافقة مسبقة. يمنح allowed-tools الأدوات المدرجة دون طلب إذن في الدورة التي استدعت المهارة. وبالنسبة إلى مهارة مشروع، يسري هذا المنح بعد قبول شخص ما لمربع حوار الثقة بمساحة العمل الخاصة بالمجلد. توضّح وثائق Claude Code النتيجة صراحةً: راجع مهارات المشاريع قبل الوثوق بمستودع، لأن المهارة يمكنها منح نفسها وصولاً واسعاً إلى الأدوات.

لذلك تعامل مع تحديث المهارة بالطريقة نفسها التي تتعامل بها مع تحديث dependency. ثبّت الإصدار باستخدام commit محدد تماماً حيثما تسمح الآلية بذلك، لأن tag يمكن نقله، بينما يتحرك branch بحكم تعريفه. في جهاز مقيّد، يستبدل "disableSkillShellExecution": true في الإعدادات كل استبدال للأوامر بالنص الحرفي [shell command execution disabled by policy] بدلاً من تنفيذه، وعند تطبيقه عبر الإعدادات المُدارة لا يستطيع المستخدم تجاوز هذا السلوك. تُستثنى المهارات المضمّنة والمُدارة من هذا الإعداد.

ينطبق الحذر نفسه على ما تقرؤه المهارة. فالـskill التي تشغّل env أو تفتح ملف إعدادات تسحب كل ما تجده إلى سياق النموذج، وهو الإخفاق المشمول في إبقاء الأسرار خارج الوكلاء الذين تشغّلهم. والـskill التي تجلب صفحة أو تنفّذ استعلاماً توجه هذا التعرض نفسه إلى الخارج، لأن النص المسترد يصل إلى السياق ويبدو تماماً مثل التعليمات التي كتبتها، وهي حدود يجدر بك قراءتها قبل أن توجّه وكيلاً إلى مثيل SearXNG الخاص بك للبحث على الويب.

ما الذي يجب قراءته عند ترقية الإصدار

• الفرق بين محتوى كل SKILL.md، لأن هذا النص هو التعليمات التي سيتبعها وكيلك.
• كل استبدال للأوامر، لأن هذه الأوامر تُنفَّذ على جهازك عند تحميل المهارة.
• أي تغيير في allowed-tools، لأن هذا السطر يمنح الأدوات من دون مطالبة.
• تشغيل الاختبارات المرتبط بالوسم. إذا كان المستودع المشترك يشغّل اختبارات smoke الخاصة به في CI، فيجب أن يكون للوسم الذي تثبّته تشغيل ناجح مرفق به.

إذا لم يتمكن المراجع من قراءة الفرق الكامل خلال عشر دقائق، فهذا يعني أن المهارة أصبحت كبيرة جداً. قسّمها. وينطبق الأمر نفسه على مستندات المستودع التي يقرأها وكلاؤك: احتفظ بالقواعد الدائمة في الملفات الموضحة في تقسيم AGENTS.md وHUMAN.md، وبالتعليل المعماري في ملف DESIGN.md مكتوب للوكلاء، واجعل المهارات إجراءات محددة النطاق.

عندما يؤدي تغيير النموذج أو الأداة إلى تعطيل مهارة

تتغير عدة أمور خلف مهارة ما دون أن يحررها أحد. قد يغيّر تحديث النموذج مدى موثوقية اتباع تعليمات طويلة، ولذلك قد تتوقف مهارة كانت تعتمد على وصول النموذج إلى الخطوة التاسعة قبل بلوغها. وقد تعيد أداة سطر الأوامر تسمية خيار، فيستخدم الوكيل الخيار القديم، ويقرأ رسالة الخطأ، ثم يرتجل حلاً. وقد يبدأ عنوان URL مشار إليه في إرجاع الخطأ 404. وقد يغيّر إطار تشغيل الوكيل طريقة اختياره للمهارات، ولذلك قد لا يعود description الذي كان يطابق الطلب أولاً هو الفائز بالمطابقة. عندما تبدأ إجراءات ما في الانتهاء مبكراً بهذه الطريقة، لا يعالج تغيير الإصدار المشكلة. تحتاج التعليمات نفسها إلى بنية تفرض تنفيذ الخطوات الأخيرة، وهذا هو النهج الذي تقوم عليه مهارة unlazy وطريقة Depth Tree الخاصة بها.

لهذا السبب، يحمل اختبار الدخان الأهمية الأكبر في هذا الترتيب. شغّل اختبار كل مهارة وفق جدول زمني، وكذلك عند تنفيذ push. تشغّل Google وظائف التقييم أسبوعياً على المكتبة بأكملها لهذا السبب، وتكفي مهمة cron أسبوعية على VPS صغير لفريق لديه عشر مهارات. هذه هي الطريقة الوحيدة لمعرفة التعطّل قبل أن يكتشفه أحد المطورين.

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

FAQ

كيف أشارك مهارة وكيل واحدة بين عدة مستودعات؟

ضع المهارة في مستودع git مخصص، وأنشئ علامات للإصدارات فيه، واجعل كل مشروع مستهلك يشير إلى علامة بدلاً من نسخ الملف. توجد آليتان مناسبتان. يسجل git submodule تعهداً محدداً، ويجعل symlink من .claude/skills/<name> إلى الوحدة الفرعية المهارة تُحمَّل كمهارة عادية للمشروع. ويؤدي سوق الإضافات الوظيفة نفسها عبر /plugin، مع تعريف التثبيت في .claude/settings.json بالمستودع المستهلك. تسجل الآليتان الإصدار في سجل git، ولذلك يمكنك تحديد التعليمات التي أنتجت عملية تشغيل وكيل معينة.

هل يمكنني تثبيت مهارة وكيل على إصدار محدد؟

ليس من داخل SKILL.md، لأن هذه frontmatter لا تحتوي على المفتاح version. يجب أن يأتي التثبيت من الطبقة المحيطة بالملف. يثبت git submodule تعهداً محدداً بحكم تصميمه. في سوق إضافات Claude Code، يقبل مصدر الإضافة ref لفرع أو علامة، وsha لتعهّد محدد، وتكون الأولوية لـsha عند وجودهما معاً. ولا يقبل مصدر السوق نفسه إلا ref. فضّل التثبيت بالتعهّد، لأن العلامة قد تُنقل بعد مراجعتك لها.

ماذا يجب أن يختبره اختبار smoke للمهارة؟

اختبر قيمة مستقرة. شغّل المهارة دون تفاعل على fixture يحتوي على خلل معروف، ثم تحقق من ظهور معرّف محدد في الناتج، مثل معرّف قاعدة يفترض أن تبلغ عنه المهارة. يجعل طلب ناتج منظم باستخدام --output-format json و--json-schema الفحص دقيقاً، ويجعل jq -e البرنامج النصي يفشل عند غياب القيمة. لا تختبر جملة كاملة، لأن النموذج يعيد صياغة إجاباته بين عمليات التشغيل.

هل تثبيت مهارة مشتركة من مستودع فريق آخر آمن؟

تعامل معها باعتبارها تبعية برمجية، لأنها تعليمات قابلة للتنفيذ. يمكن لـSKILL.md تشغيل أوامر shell عند التحميل باستخدام صيغة استبدال الأوامر !، كما يمكن لحقل allowed-tools في frontmatter الموافقة مسبقاً على الأدوات دون عرض مطالبة. اقرأ diff عند كل ترقية، وثبّت المهارة على تعهّد محدد بدلاً من فرع، وفضّل مصدراً يتحكم فيه فريقك. في الأجهزة المُدارة، يمنع "disableSkillShellExecution": true في الإعدادات تشغيل استبدالات الأوامر بالكامل.

هل تعمل المهارة المشتركة مع وكلاء غير Claude Code؟

يعتمد ذلك على مفاتيح frontmatter التي تستخدمها. تحدد مواصفة Agent Skills ستة مفاتيح: name وdescription وlicense وcompatibility وmetadata وallowed-tools. تُحمَّل المهارة المقتصرة على هذه المفاتيح عبر الأدوات التي تطبق المواصفة، كما تُحمَّل في Claude Code دون تغييرات. تُتجاهل المفاتيح وميزات النص الخاصة بالبيئة، التي تتجاوز المواصفة، أو تُرفض في الأدوات الأخرى. لذلك أبقِ هذه العناصر خارج أي مهارة تنوي مشاركتها على نطاق واسع.