تعدين المهارات: من 3,500 مرشَّح إلى 466 قدرة

تعكس الأرقام في هذا المنشور حالة النظام وقت النشر (يناير 2026). راجع صفحة فريقنا للأرقام الحالية.

مشكلة الـ3,500 مهارة

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

إجابتنا: حلقة تعدين واستيعاب منهجية.

الأرقام اليوم

بعد نحو ثلاثة أشهر فقط من إطلاق Anthropic لـAgent Skills في 16 أكتوبر 2025، إليك أين كنا عندما نُشِر هذا المنشور في 27 يناير 2026:

المقياس	العدد
المرشَّحون المحدَّدون	أكثر من 3,500
المهارات المُعتمَدة	466
مهارات البائعين	373
المهارات الداخلية	93
البائعون النشِطون	أكثر من 25
متوسط الرموز لكل مهارة	2,834
الأدوات المُشار إليها	89
الوسوم الفريدة	635

راجعنا أكثر من 3,500 مرشَّح للمهارات. اعتمدنا 466 منها. ذلك معدل اعتماد 13% - وتلك الانتقائية مقصودة.

نظام طبقات المعرفة

لم تُخلَق كل المهارات متساوية. ننظِّمها في خمس طبقات معرفة (K0-K4)، تمثِّل كل واحدة نطاق تطبيق مختلفًا:

K0: الأساسيات (عالمية)

مهارات ينبغي أن يمتلكها كل وكيل. تمثِّل هذه قدرات “المفكِّر الجيد” التي تعمل في أي مكان.

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

مهارات K0 قابلة للنقل إلى أي مشروع، أي مجال، أي مكدس تقني. تُرمِّز أنماطًا معرفية عالمية.

K1: الهويات (الانضباط)

مهارات “المهندس الجيد” أو “الباحث الجيد” التي تُطبَّق عبر المشاريع ضمن تخصص واحد.

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: المجالات (خبرة الموضوع)

مهارات “خبير قواعد البيانات الجيد” أو “مهندس الأمان الجيد” القابلة للنقل ضمن مجال واحد.

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: المكدسات التقنية (Stacks)

مهارات “مستخدم Supabase الجيد” أو “مطوِّر Cloudflare الجيد” لمكدسات تقنية محدَّدة.

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: المشروع (المؤسسة)

مهارات خاصة بمؤسستنا وسير عملنا.

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

حلقة التعدين

المرحلة 1: الاكتشاف

تأتي المهارات من كل مكان:

مستودعات البائعين: تنشر AWS، وAnthropic، وCloudflare، وSupabase، ومساهمو المجتمع مجموعات مهارات. نتتبَّع أكثر من 25 جذر بائع.

مشاريع المجتمع: GitHub مليء بقوالب Claude Code، وأنماط الوكلاء، وتعريفات سير العمل.

الأنماط الداخلية: بينما يحل فريقنا المشكلات، تظهر أنماط. تُصاغ هذه رسميًا في مهارات.

تعدين التوثيق: غالبًا ما يحتوي التوثيق التقني على مهارات ضمنية - إجراءات، وقوائم مراجعة، وأشجار قرار.

الاكتشاف مستمر. نستخدم قائمة انتظار مهارات لتتبُّع المرشَّحين قبل التقييم الرسمي.

المرحلة 2: التقييم

يمر كل مرشَّح بالمعيار نفسه:

adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage

يجب أن تنجح جميع المعايير الخمسة للمنتج. لهذا يُرفَض 87% من المرشَّحين.

ثم يمر كل مرشَّح بمراجعة ثقة منفصلة. لا نعامل مستودع بائع رسمي، ومشرف مجتمع معروف جيدًا، ومستودع GitHub عشوائي كمصادر حقيقة متكافئة.

trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

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

تحليل الفجوات: قبل الاعتماد، نبحث في سجلنا:

uv run orkestra skills search "<capability>"

إذا كنا نمتلكها بالفعل، لا نحتاج إليها. إذا كان لدينا شيء قريب، قد ندمج بدلًا من أن نعتمد.

تقييم العمق والمعايير: نُقيِّم أيضًا مدى استخدام المرشَّح الكامل لنموذج مهارة الوكيل. لا يزال SKILL.md منفردًا مفيدًا، لكن المهارات الأعمق أكثر قيمة عندما تفصل التعليمات عن المراجع، والنصوص البرمجية، والأصول بالطريقة التي يشجِّعها agentskills.io.

skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost

يمكن أن ترفع نجوم GitHub درجة المصداقية قليلًا، لكنها لا تُنقِذ أبدًا مهارة سطحية أو غير آمنة. مستودع بنجوم كثيرة مع SKILL.md غامض واحد ونصوص برمجية معتمة يحصل على درجة أقل من مستودع أصغر بوصف دقيق، وreferences/ مُنسَّق، ومساعدات ذرية تستفيد فعليًا من كامل قدرة المهارة.

التحليل البنيوي: نفحص جودة المهارة:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

إذا تضمَّن المرشَّح نصوصًا برمجية، تصبح تلك المراجعة أكثر صرامة. المهارة الجيدة ليست مفيدة فقط؛ يجب أن تكون واضحة، ومحدودة، وآمنة لتُسلَّم إلى وكيل. مرشِّح السلامة هذا وحده يستبعد شريحة ذات معنى من مرشَّحين مثيرين للاهتمام لولا ذلك.

المرحلة 3: الاستيعاب

عندما تجتاز مهارة التقييم، تدخل السجل. لكن المهارات لا تُعتمَد أبدًا دون تغيير. تُعدَّل لتناسب نظامنا.

التعديلات عند الاعتماد:

1. تطبيع البيانات الوصفية: تحصل كل مهارة على مخطط frontmatter الخاص بنا
2. تعيين طبقة K: تُوضَع المهارات في طبقة المعرفة المناسبة
3. إثراء الوسوم: تُضاف وسوم للاكتشاف
4. تصريح الأدوات: تُصرَّح الأدوات المسموح بها صراحةً
5. مواءمة الأقسام: تُعاد هيكلة المحتوى ليطابق قالبنا

مهارة YAML نموذجية بعد الاستيعاب:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

المرحلة 4: تعيين النطاق

تُعيَّن المهارات إلى نطاقات - فئات تُحدِّد أي الوكلاء يُحمِّل أي المهارات:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

تُصرِّح الوكلاء عن نطاقاتها، وتُعيَّن المهارات تلقائيًا:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

المرحلة 5: التجسيد

لا تعيش المهارات كـYAML في الإنتاج. تُصيَّر إلى ملفات SKILL.md التي يستطيع Claude Code تحميلها:

uv run orkestra sync

يقوم هذا الأمر بما يلي:

1. يقرأ كل تعريفات YAML للمهارات
2. يُصيِّرها عبر قوالب Jinja
3. يكتب ملفات SKILL.md إلى .claude/skills/
4. ينظِّم حسب طبقة K (foundations/، identities/، domains/، stacks/، project/)

بنية المخرَج النهائية:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

نمط النطاق الكامن (Dormant)

أحد أقوى أنماطنا هو مهارات “مُعتمَدة لكن غير محمَّلة”. نسمّي هذه النطاقات الكامنة.

تأمَّل مهارات الحوسبة العلمية من مستودع k-dense-scientific. اعتمدنا أكثر من 120 مهارة تغطي المعلوماتية الحيوية، والكيمياء، والحوسبة الكمومية، والمعلوماتية السريرية. لكن معظم وكلائنا لا يحتاجون إلى الالتحام الجزيئي أو تحليل التعبير الجيني.

بدلًا من تحميل كل الـ120 مهارة في كل وكيل (مما يُضخِّم نوافذ السياق)، نحن:

1. نعتمد المهارات بنطاق محدَّد (مثل bioinformatics)
2. نُبقيها كامنة - مُسجَّلة لكن غير محمَّلة
3. نُفعِّلها فقط عندما يُصرِّح وكيل عن ذلك النطاق

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills

يتيح لنا هذا النمط امتلاك 466 مهارة في السجل بينما تُحمِّل الوكلاء النموذجية 40-60 مهارة ذات صلة فقط.

أنواع المهارات

تأتي المهارات في ثلاثة أنماط معرفية:

سير عمل (Workflow)

خطوات إجرائية مرتَّبة: “1. افعل X، 2. ثم Y، 3. أخيرًا Z”

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

انضباط (Discipline)

ضوابط سلوكية: “دائمًا X”، “أبدًا Y”، “فضِّل Z”

type: discipline
# Examples: test-first-discipline, evidence-based-completion

قائمة مراجعة (Checklist)

معايير تحقق: “أكِّد X”، “تحقَّق من Y”، “افحص Z”

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

بوابات الجودة

يجب أن تجتاز كل مهارة التحقق قبل شحنها:

validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry

يجب أن تكون الأوصاف بين 50-400 حرف مع عبارات تفعيل (“استخدم عندما…”، “عندما تحتاج إلى…”) كي يعرف Claude Code متى يقترحها.

نتحقق باستمرار:

uv run orkestra validate --show-warnings

منظومة البائعين البيئية

تأتي الـ373 مهارة من بائعين لدينا من:

المزوِّد	المهارات	المجال
AWS Agent	19	خدمات سحابية
Anthropic	12	توليد المستندات
Cloudflare	8	الحوسبة الطرفية (edge)
Supabase	5	قواعد البيانات
k-dense	أكثر من 100	الحوسبة العلمية
silvainfm	4	علم البيانات
Java Developer Kit	أكثر من 45	Spring/Java
Vercel	1	أتمتة المتصفح

يُصرَّح كل جذر بائع في metadata.yaml:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

عندما يعمل orkestra sync، تُربَط مهارات البائعين برمزيًا إلى .claude/skills/vendor/ بمساحة اسم مزوِّدها.

ما تعلمناه

الانتقائية تُؤتي ثمارها. من المُغري اعتماد كل ما يبدو مفيدًا. لكن كل مهارة تكلِّف رموزًا. بمتوسط 2,834 رمزًا لكل مهارة، يضر التضخم بسرعة. معدل اعتمادنا البالغ 13% يُبقي الوكلاء رشيقين.

البنية تُمكِّن الاكتشاف. نظام طبقات K ليس مجرد تنظيم - إنه يتعلق بقابلية النقل. يمكن إعادة استخدام مهارات K0 في أي مكان. مهارات K4 خاصة بالمشروع عمدًا. هذا الوضوح يساعد كلًا من البشر والوكلاء على إيجاد ما يحتاجونه.

النطاقات الكامنة تتوسَّع. يمكنك اعتماد مئات المهارات دون تحميلها كلها. تتيح لك النطاقات بناء سجل شامل مع إبقاء نوافذ سياق الوكيل الفردية قابلة للإدارة.

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

التعدين مستمر. يستمر رقم الـ3,500 في النمو. تظهر مستودعات بائعين جديدة. تنبثق أنماط مجتمعية. تتصلَّب سير عمل داخلي. الحلقة لا تتوقف أبدًا.

ما التالي

نعمل على عدة تحسينات:

1. اكتشاف الفجوات آليًا: تنبيه عندما يمكن معالجة إخفاقات وكيل شائعة بمهارة غير مُعتمَدة
2. سير عمل تقادم المهارات: عملية رسمية لسحب المهارات التي حلَّت محلها أخرى أو لم تعد تُستخدَم
3. تبعيات عبر المهارات: تصريح صريح لمتطلبات المهارة المسبقة
4. تحليلات الاستخدام: تتبُّع أي المهارات يستدعيها الوكلاء فعليًا مقابل مجرد تحميلها

حلقة تعدين المهارات بنية تحتية. إنها ليست برّاقة. لكنها ما يجعل 41 وكيلًا يعمل بتماسك مع 466 قدرة مع البقاء ضمن حدود السياق.

تلك هي قصة كيف يصبح 3,500 هو 466. ليس بتجاهل 3,000 - بل بتقييمها منهجيًا واعتماد ما ينجح فقط.

---

تريد رؤية نظام المهارات في العمل؟ راجع uv run orkestra skills list لاستكشاف سجلنا الحالي.