Blog

كيفية إنشاء مهارات Claude Code تلقائيًا باستخدام Skill Creator

Ashley Innocent

Ashley Innocent

23 مارس 2026

كيفية إنشاء مهارات Claude Code تلقائيًا باستخدام Skill Creator

Apidog للمؤسسات

النشر على الخوادم المحلية

SSO و RBAC

متوافق مع SOC 2

استكشف Apidog للمؤسسات

TL;DR

مهارات Claude Code هي قدرات مخصصة توسع وظائف Claude لسير عمل معين. نظام Skill Creator (منشئ المهارات) يقوم بأتمتة إنشاء المهارات من خلال عملية منظمة: حدد الغرض من مهارتك، قم بصياغة ملف SKILL.md، أنشئ حالات اختبار، قم بتشغيل التقييمات بمعايير كمية، وحسّن تكرارًا بناءً على الملاحظات.

مقدمة

أنت تستخدم Claude Code يوميًا. تلاحظ أنك تكرر نفس التسلسلات: إعداد هياكل المشروع، تشغيل أوامر اختبار محددة، تنسيق المخرجات بطريقة معينة. في كل مرة، تشرح سير العمل من الصفر. ماذا لو تذكر Claude؟ ماذا لو كان بإمكانك التقاط سير العمل هذا مرة واحدة، وجعله متاحًا إلى الأبد؟ هذا ما تفعله مهارات Claude Code. إنها قدرات مخصصة تنشئها لتوسيع وظائف Claude لسير عملك المحدد. ومع Skill Creator، تكون العملية مؤتمتة ومنهجية.

يشرح لك هذا الدليل العملية بأكملها. ستتعلم تشريح المهارة، وسير عمل الإنشاء، ونظام التقييم، وكيفية التحسين من أجل تشغيل موثوق. سترى أمثلة عملية من مستودع مهارات Anthropic الرسمي.

💡
إذا كنت تقوم بإنشاء مهارات متعلقة بـ API، فإن Apidog يندمج بشكل طبيعي. اختبر نقاط نهاية API الخاصة بك، تحقق من صحة الاستجابات، وقم بإنشاء الوثائق كلها ضمن سير عمل مهارة واحدة.
button

ما هي مهارات Claude Code؟

مهارات Claude Code هي مجموعات تعليمات متخصصة توسع قدرات Claude لمجالات أو سير عمل محددة. فكر فيها كإضافات مخصصة تعيش في ملفات markdown.

هندسة نظام المهارة

تستخدم المهارات نظام تحميل من ثلاثة مستويات:

  1. البيانات الوصفية (Metadata) (~100 كلمة) - الاسم والوصف، دائمًا في السياق.
  2. جسم SKILL.md (<500 سطر) - التعليمات الأساسية، يتم تحميلها عند تشغيل المهارة.
  3. الموارد المجمعة (Bundled resources) (غير محدودة) - البرامج النصية، المراجع، الأصول التي يتم تحميلها عند الطلب.
skill-name/
├── SKILL.md (مطلوب)
│   ├── YAML frontmatter (الاسم، الوصف)
│   └── تعليمات Markdown
└── موارد مجمعة (اختياري)
    ├── scripts/    - تعليمات برمجية قابلة للتنفيذ للمهام المتكررة
    ├── references/ - وثائق يتم تحميلها حسب الحاجة
    └── assets/     - قوالب، أيقونات، خطوط

متى يتم تشغيل المهارات

تظهر المهارات في قائمة available_skills لدى Claude مع اسمها ووصفها. يقرر Claude ما إذا كان سيستشير مهارة بناءً على هذا الوصف.

هام: لا يتم تشغيل المهارات إلا للمهام التي لا يستطيع Claude التعامل معها مباشرة. الاستعلامات البسيطة مثل "اقرأ هذا الملف" لن تؤدي إلى تشغيل مهارة حتى مع وصف مطابق. سير العمل المعقد متعدد الخطوات يتم تشغيله بشكل موثوق عندما يتطابق الوصف.

أمثلة واقعية من مستودع Anthropic

المهارة الغرض الميزات الرئيسية
skill-creator إنشاء مهارات جديدة توليد حالات الاختبار، تقييم المعايير، تحسين الوصف
mcp-builder إنشاء خوادم MCP قوالب Python/Node، إطار عمل التقييم، أفضل الممارسات
docx توليد مستندات Word برامج python-docx النصية، نظام القوالب، دليل التنسيق
pdf استخراج ومعالجة ملفات PDF معالجة النماذج، استخراج النص، وثائق مرجعية
frontend-design بناء واجهات الويب مكتبة المكونات، أنماط Tailwind، فحوصات إمكانية الوصول

سير عمل إنشاء المهارة

تتبع عملية إنشاء المهارة حلقة منهجية:

  1. التقاط النية - ماذا يجب أن تفعل المهارة؟
  2. كتابة مسودة - إنشاء ملف SKILL.md
  3. إنشاء حالات اختبار - تحديد مطالبات واقعية
  4. تشغيل التقييمات - التنفيذ مع وبدون المهارة
  5. مراجعة النتائج - ملاحظات نوعية + مقاييس كمية
  6. التكرار - التحسين بناءً على النتائج
  7. تحسين الوصف - زيادة دقة التشغيل
  8. التعبئة - التوزيع كملف .skill

دعنا ننتقل إلى كل خطوة.

الخطوة 1: التقاط النية

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

اطرح هذه الأسئلة الأربعة:

  1. ما الذي يجب أن تمكّن هذه المهارة Claude من فعله؟ كن محددًا بشأن النتيجة.
  2. متى يجب أن يتم تشغيل هذه المهارة؟ ما هي العبارات أو السياقات التي يستخدمها المستخدم؟
  3. ما هو تنسيق الإخراج المتوقع؟ ملفات، رمز، تقارير؟
  4. هل يجب علينا إعداد حالات اختبار؟ المهارات ذات المخرجات القابلة للتحقق (توليد التعليمات البرمجية، استخراج البيانات، تحويلات الملفات) تستفيد من حالات الاختبار. المهارات ذات المخرجات الذاتية (أسلوب الكتابة، جودة التصميم) غالبًا لا تحتاج إليها.

مثال: مهارة اختبار API

النية: مساعدة المطورين على اختبار واجهات برمجة التطبيقات REST بشكل منهجي
الزناد: عندما يذكر المستخدم اختبار API، أو نقاط النهاية، أو REST، أو GraphQL، أو يريد التحقق من صحة الاستجابات
الإخراج: تقارير اختبار مع حالة النجاح/الفشل، أوامر curl، مقارنات الاستجابة
حالات الاختبار: نعم - المخرجات قابلة للتحقق بشكل موضوعي

الخطوة 2: كتابة ملف SKILL.md

تبدأ كل مهارة بملف SKILL.md يحتوي على YAML frontmatter وتعليمات markdown.

تشريح المهارة

---
name: api-tester
description: كيفية اختبار واجهات برمجة التطبيقات REST بشكل منهجي. استخدمها عندما يذكر المستخدمون اختبار API، أو نقاط النهاية، أو REST، أو GraphQL، أو يريدون التحقق من صحة استجابات API. تأكد من اقتراح هذه المهارة كلما كان هناك اختبار.
compatibility: تتطلب curl أو أدوات عميل HTTP
---

# مهارة اختبار API

## سير العمل الأساسي

عند اختبار API، اتبع الخطوات التالية:

1. **فهم نقطة النهاية** - اقرأ المواصفات أو اطلب المخطط
2. **تصميم حالات الاختبار** - المسار السعيد، الحالات الهامشية، ظروف الخطأ
3. **تنفيذ الاختبارات** - استخدم curl أو Apidog للطلبات
4. **التحقق من صحة الاستجابات** - تحقق من رموز الحالة، الرؤوس، بنية الجسم
5. **الإبلاغ عن النتائج** - تلخيص النجاح/الفشل مع الأدلة

## قالب حالة الاختبار

لكل نقطة نهاية، اختبر:

- مصادقة صحيحة مع حمولة صحيحة
- مصادقة صحيحة مع حقول مطلوبة مفقودة
- مصادقة غير صالحة (متوقع 401)
- سلوك تحديد المعدل
- وقت الاستجابة تحت الحمل

## تنسيق الإخراج

قم دائمًا بتنسيق التقارير هكذا:

# تقرير اختبار API

## ملخص
- الاختبارات التي تم تشغيلها: X
- ناجح: Y
- فاشل: Z

## الاختبارات الفاشلة

### اسم الاختبار
**المتوقع:** 200 OK
**الفعلي:** 400 Bad Request
**الاستجابة:** {...}

## التوصيات
...

أفضل ممارسات الكتابة

استخدم الكشف التدريجي: حافظ على ملف SKILL.md أقل من 500 سطر. انقل المراجع التفصيلية إلى ملفات منفصلة.

api-tester/
├── SKILL.md (نظرة عامة على سير العمل)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

اشرح السبب: لا تكتفِ بسرد القواعد. اشرح سبب أهميتها.

## لماذا نختبر حالات الخطأ أولاً

اختبار حالات الخطأ قبل المسارات السعيدة يكتشف 80% من المشاكل بشكل أسرع.
عندما تفشل المصادقة بصمت، تصبح اختبارات المسار السعيد بلا معنى.
ابدأ بفحص 401.

استخدم صيغة الأمر: "تحقق دائمًا من رمز الحالة أولاً" وليس "يجب عليك التحقق..."

تضمين أمثلة: اعرض الإدخال والإخراج المتوقع.

## تنسيق رسالة الالتزام

**مثال:**
الإدخال: تمت إضافة مصادقة المستخدم باستخدام رموز JWT
الإخراج: feat(auth): implement JWT-based authentication

الخطوة 3: إنشاء حالات الاختبار

بعد صياغة المهارة، أنشئ من 2 إلى 3 مطالبات اختبار واقعية. هذه هي أنواع الطلبات التي سيقدمها مستخدم حقيقي بالفعل.

تنسيق حالة الاختبار

احفظ حالات الاختبار في evals/evals.json:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "اختبر نقطة النهاية /users على api.example.com - تتطلب رمز Bearer وتعيد قائمة بالمستخدمين مع حقول id و name و email",
      "expected_output": "تقرير اختبار يتضمن ما لا يقل عن 5 حالات اختبار بما في ذلك فشل المصادقة، والنجاح، واختبارات الترحيل",
      "files": []
    },
    {
      "id": 2,
      "prompt": "أحتاج إلى التحقق من أن نقطة النهاية الجديدة POST /orders تتعامل مع الكميات غير الصالحة بشكل صحيح",
      "expected_output": "حالات اختبار ترسل كميات سالبة، صفر، وغير رقمية مع استجابات خطأ مناسبة",
      "files": ["openapi.yaml"]
    }
  ]
}

ما الذي يجعل مطالبة الاختبار جيدة

سيء: "اختبر هذا الـ API"

جيد: "حسنًا، لقد قام فريقي للتو بنشر نقطة النهاية الجديدة للدفعات على https://api.stripe.com/v1/charges وأحتاج إلى التحقق من أنها تتعامل مع الحالات الهامشية - وبالتحديد ماذا يحدث عندما ترسل مبلغًا سالبًا أو رمز عملة غير موجود. تقول الوثائق أنه يجب أن يعيد 400 ولكنني أريد رؤية رسائل الخطأ الفعلية"

تتضمن مطالبة الاختبار الجيدة ما يلي:

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

الخطوة 4: تشغيل التقييمات

هنا تبرز قوة Skill Creator. ستشغل كل حالة اختبار مرتين: مرة مع المهارة، ومرة بدونها (أو مع الإصدار القديم إذا كنت تقوم بتحسين مهارة موجودة).

هيكل مساحة العمل

توضع النتائج في <skill-name>-workspace/ كمجلد شقيق لمجلد المهارة:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

إطلاق تشغيلات متوازية

لكل حالة اختبار، قم بإنشاء وكيلين فرعيين في نفس الدور:

التشغيل مع المهارة:

نفّذ هذه المهمة:
- مسار المهارة: /path/to/api-tester
- المهمة: اختبر نقطة النهاية /users على api.example.com
- ملفات الإدخال: لا يوجد
- حفظ المخرجات إلى: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

التشغيل الأساسي:

نفّذ هذه المهمة:
- مسار المهارة: (لا يوجد)
- المهمة: اختبر نقطة النهاية /users على api.example.com
- ملفات الإدخال: لا يوجد
- حفظ المخرجات إلى: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

التقاط بيانات التوقيت

عندما يكتمل كل وكيل فرعي، تتلقى total_tokens و duration_ms. احفظها فورًا في timing.json:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

تأتي هذه البيانات فقط عبر إشعار المهمة. عالج كل منها فور وصولها.

الخطوة 5: صياغة التأكيدات بينما تكتمل عمليات التشغيل

لا تنتظر فقط حتى تنتهي عمليات التشغيل. استخدم هذا الوقت بشكل منتج من خلال صياغة تأكيدات كمية.

ما الذي يجعل التأكيد جيداً

التأكيدات الجيدة هي:

أمثلة على التأكيدات لمهارة اختبار API:

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "يتضمن تقرير الاختبار على الأقل حالة اختبار واحدة لفشل المصادقة",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "يتضمن تقرير الاختبار على الأقل حالة اختبار طلب ناجحة واحدة",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "تتضمن كل حالة اختبار أوامر curl قابلة للتنفيذ",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "التقرير يتحقق من صحة بنية الاستجابة مقابل المخطط",
      "type": "contains",
      "value": "schema"
    }
  ]
}

قم بتحديث eval_metadata.json و evals/evals.json بالتأكيدات بمجرد صياغتها.

الخطوة 6: التقييم والتجميع

بمجرد اكتمال جميع عمليات التشغيل:

تقييم كل تشغيل

قم بتشغيل وكيل فرعي للمُقيّم (grader subagent) يقرأ agents/grader.md ويقيّم كل تأكيد مقابل المخرجات. احفظ النتائج في grading.json في كل دليل تشغيل:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "تم العثور على رمز حالة 401 في حالة الاختبار 3"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "تم العثور على 'curl -X POST' في حالة الاختبار 1"
    }
  ]
}

هام: يجب أن تستخدم مصفوفة التوقعات في grading.json أسماء الحقول text و passed و evidence. تعتمد العارضة على هذه الأسماء بالضبط.

التجميع في معيار

قم بتشغيل النص البرمجي للتجميع من دليل skill-creator:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

ينتج هذا benchmark.json و benchmark.md مع معدل النجاح (pass_rate) والوقت (time) والرموز (tokens) لكل تهيئة، بما في ذلك المتوسط ± الانحراف المعياري (stddev) والفرق (delta).

القيام بمرور المحلل

اقرأ بيانات المعيار واكتشف الأنماط:

راجع agents/analyzer.md للحصول على إرشادات مفصلة.

الخطوة 7: إطلاق عارضة التقييم

تعرض عارضة التقييم المخرجات النوعية والمقاييس الكمية في واجهة المتصفح.

توليد العارضة

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

للتكرار 2+، قم أيضًا بتمرير --previous-workspace:

--previous-workspace api-tester-workspace/iteration-1

ما يراه المستخدم

تعرض علامة التبويب المخرجات (Outputs) حالة اختبار واحدة في كل مرة:

تعرض علامة التبويب المعيار (Benchmark):

أخبر المستخدم: "لقد فتحت النتائج في متصفحك. توجد علامتا تبويب - 'المخرجات' تتيح لك النقر عبر كل حالة اختبار وترك الملاحظات، و 'المعيار' يعرض المقارنة الكمية. عندما تنتهي، عد إلى هنا وأخبرني."

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

إذا لم يكن webbrowser.open() متاحًا، استخدم --static لكتابة ملف HTML مستقل:

--static /path/to/output/review.html

يتم تنزيل الملاحظات كـ feedback.json عندما ينقر المستخدم على "Submit All Reviews".

الخطوة 8: قراءة الملاحظات والتكرار

عندما ينتهي المستخدم، اقرأ feedback.json:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "الرسم البياني يفتقد تسميات المحاور",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "مثالي، أحب هذا",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

الملاحظات الفارغة تعني أن المستخدم اعتقد أنها جيدة. ركز التحسينات على حالات الاختبار التي تتلقى شكاوى محددة.

كيف تفكر في التحسينات

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

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

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

ابحث عن العمل المتكرر: هل كتبت جميع حالات الاختبار بشكل مستقل برامج مساعدة مماثلة؟ هذه إشارة إلى أن المهارة يجب أن تجمع هذا النص البرمجي. اكتبه مرة واحدة، ضعه في scripts/، واطلب من المهارة استخدامه.

حلقة التكرار

  1. طبق التحسينات على المهارة
  2. أعد تشغيل جميع حالات الاختبار في iteration-<N+1>/ مع تشغيلات الأساس
  3. شغّل العارضة مع توجيه --previous-workspace إلى التكرار السابق
  4. انتظر مراجعة المستخدم
  5. اقرأ الملاحظات الجديدة، وحسّن مرة أخرى، وكرر

استمر حتى:

أغلق العارضة عند الانتهاء:

kill $VIEWER_PID 2>/dev/null

الخطوة 9: تحسين وصف المهارة

حقل الوصف في مقدمة ملف SKILL.md هو الآلية الرئيسية للتشغيل. بعد إنشاء أو تحسين مهارة، قم بتحسين وصفها لتحقيق دقة أفضل في التشغيل.

توليد استعلامات تقييم المشغل

أنشئ 20 استعلام تقييم - مزيجًا من ما يجب أن يتم تشغيله وما لا يجب أن يتم تشغيله:

[
  {
    "query": "حسنًا، لقد أرسلت لي مديري هذا الملف xlsx (إنه في تنزيلاتي، يسمى شيئًا مثل 'Q4 sales final FINAL v2.xlsx') وتريد مني إضافة عمود يوضح هامش الربح كنسبة مئوية. الإيرادات في العمود C والتكاليف في العمود D على ما أعتقد",
    "should_trigger": true
  },
  {
    "query": "أحتاج إلى إنشاء جدول محوري من هذا CSV وإرساله بالبريد الإلكتروني إلى الفريق",
    "should_trigger": false
  }
]

للاستعلامات التي يجب أن تؤدي إلى التشغيل (8-10):

للاستعلامات التي لا يجب أن تؤدي إلى التشغيل (8-10):

اختبارات سلبية سيئة: "اكتب دالة فيبوناتشي" كاختبار سلبي لمهارة PDF أمر سهل للغاية. يجب أن تكون الحالات السلبية صعبة حقًا.

المراجعة مع المستخدم

قدم مجموعة التقييم باستخدام قالب HTML:

  1. اقرأ assets/eval_review.html
  2. استبدل العناصر النائبة ببيانات التقييم واسم المهارة ووصفها
  3. اكتب في ملف مؤقت وافتحه: open /tmp/eval_review_api-tester.html
  4. يمكن للمستخدم تحرير الاستعلامات، وتبديل "يجب أن يؤدي إلى التشغيل"، وإضافة/إزالة الإدخالات
  5. ينقر المستخدم على "تصدير مجموعة التقييم"
  6. يتم تنزيل الملف إلى ~/Downloads/eval_set.json

هذه الخطوة مهمة. استعلامات التقييم السيئة تؤدي إلى أوصاف سيئة.

تشغيل حلقة التحسين

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

استخدم معرف النموذج الذي يشغل جلستك الحالية بحيث تتطابق اختبارات التشغيل مع ما يختبره المستخدمون.

النص البرمجي:

  1. يقسم مجموعة التقييم إلى 60% تدريب، 40% اختبار محجوز
  2. يقيم الوصف الحالي (3 تشغيلات لكل منها للموثوقية)
  3. يطلب من Claude اقتراح تحسينات بناءً على الإخفاقات
  4. يعيد التقييم على مجموعة التدريب والاختبار
  5. يكرر ما يصل إلى 5 مرات
  6. يعيد best_description المختار حسب درجة الاختبار (وليس درجة التدريب لتجنب التخصيص الزائد)

تطبيق النتيجة

خذ best_description من مخرج JSON وحدث مقدمة ملف SKILL.md الخاص بالمهارة. اعرض على المستخدم قبل/بعد مع الدرجات.

قبل:

description: كيفية اختبار واجهات برمجة التطبيقات REST بشكل منهجي

بعد:

description: كيفية اختبار واجهات برمجة التطبيقات REST بشكل منهجي. استخدمها عندما يذكر المستخدمون اختبار API، أو نقاط النهاية، أو REST، أو GraphQL، أو يريدون التحقق من صحة استجابات API. تأكد من اقتراح هذه المهارة كلما كان هناك اختبار، حتى لو لم يذكروا صراحةً 'الاختبار'.

الخطوة 10: التعبئة والتوزيع

بمجرد اكتمال المهارة، قم بتعبئتها للتوزيع:

python -m scripts.package_skill /path/to/api-tester

ينشئ هذا ملف .skill يمكن للمستخدمين تثبيته. وجه المستخدمين إلى مسار الملف الناتج.

التثبيت

يقوم المستخدمون بتثبيت المهارات عن طريق وضع ملف .skill في دليل مهاراتهم أو باستخدام أمر تثبيت مهارات Claude Code.

أخطاء شائعة في إنشاء المهارات

الخطأ 1: وصف غامض

سيء:

description: مهارة للعمل مع واجهات برمجة التطبيقات

جيد:

description: كيفية اختبار واجهات برمجة التطبيقات REST بشكل منهجي. استخدمها عندما يذكر المستخدمون اختبار API، أو نقاط النهاية، أو REST، أو GraphQL، أو يريدون التحقق من صحة استجابات API. تأكد من اقتراح هذه المهارة كلما كان هناك اختبار، حتى لو لم يذكروا صراحةً 'الاختبار'.

الخطأ 2: تعليمات مقيدة بشكل مفرط

سيء:

استخدم دائمًا هذا التنسيق بالضبط. لا تنحرف أبدًا. يجب أن تتضمن هذه الأقسام.

جيد:

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

الخطأ 3: تخطي حالات الاختبار

تكتشف حالات الاختبار المشكلات قبل أن يواجهها المستخدمون. حتى بالنسبة للمهارات الذاتية، قم بتشغيل 2-3 أمثلة للتحقق من جودة الإخراج.

الخطأ 4: تجاهل بيانات التوقيت

المهارات التي تستغرق وقتًا أطول بـ 10 أضعاف ليست مستدامة. التقط بيانات التوقيت وحسّن الكفاءة جنبًا إلى جنب مع الجودة.

الخطأ 5: عدم تجميع البرامج النصية المتكررة

إذا كانت كل عملية تشغيل اختبار تكتب بشكل مستقل ملف generate_report.py، فقم بتجميعها في المهارة. يوفر الوقت ويضمن الاتساق.

أمثلة لمهارات واقعية

مهارة بناء MCP

أنشأتها Anthropic لبناء خوادم MCP (بروتوكول سياق النموذج).

الميزات الرئيسية:

الهيكل:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

مهارة Docx

توليد مستندات Word برمجياً.

الميزات الرئيسية:

سير العمل:

  1. فهم متطلبات المستند
  2. تحديد أو إنشاء قالب
  3. التوليد عبر نص python-docx البرمجي
  4. التحقق من بنية الإخراج

مهارة تصميم الواجهة الأمامية

بناء واجهات الويب بأنماط حديثة.

الميزات الرئيسية:

الكشف التدريجي: سير العمل الأساسي في SKILL.md، وثائق المكونات في references/.

اختبار مهارتك باستخدام Apidog

إذا كنت تقوم بإنشاء مهارات متعلقة بـ API، فإن Apidog يندمج بشكل طبيعي في سير العمل.

مثال: دمج مهارة اختبار API

## تشغيل اختبارات API

استخدم Apidog للاختبار المنهجي:

1. استورد مواصفات OpenAPI إلى Apidog
2. أنشئ حالات اختبار من المواصفات
3. شغّل الاختبارات وصدّر النتائج كـ JSON
4. تحقق من صحة الاستجابات مقابل المخططات المتوقعة

للتأكيدات المخصصة، استخدم ميزة البرمجة النصية في Apidog.

تجميع برامج Apidog النصية

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

هذا يوفر كل استدعاء مستقبلي من إعادة اختراع العجلة.

الخلاصة

توسع مهارات Claude Code قدرات Claude لسير عملك المحدد. يوفر نظام Skill Creator عملية منهجية:

  1. التقاط النية - تحديد ما يجب أن تفعله المهارة
  2. صياغة SKILL.md - كتابة تعليمات واضحة مع أمثلة
  3. إنشاء حالات اختبار - مطالبات واقعية سيقدمها المستخدمون بالفعل
  4. تشغيل التقييمات - تنفيذ متوازٍ مع وبدون المهارة
  5. مراجعة النتائج - ملاحظات نوعية + معايير كمية
  6. التكرار - التحسين بناءً على النتائج
  7. تحسين الوصف - زيادة دقة التشغيل
  8. التعبئة - التوزيع كملف .skill
button

الأسئلة الشائعة

كم من الوقت يستغرق إنشاء مهارة؟

تستغرق المهارات البسيطة من 15 إلى 30 دقيقة. يمكن أن تستغرق المهارات المعقدة ذات الملفات المرجعية المتعددة والبرامج النصية المجمعة من 2 إلى 3 ساعات بما في ذلك تكرارات التقييم.

هل أحتاج إلى كتابة حالات اختبار لكل مهارة؟

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

ماذا لو لم يتم تشغيل مهارتي بشكل موثوق؟

قم بتحسين حقل الوصف. قم بتضمين عبارات وسياقات تشغيل محددة. اجعلها "تفاعلية" قليلاً - اذكر بوضوح متى تستخدم المهارة. قم بتشغيل حلقة تحسين الوصف مع 20 استعلام تقييم.

كيف أشارك المهارات مع فريقي؟

قم بتعبئة المهارة باستخدام python -m scripts.package_skill <path>، ثم قم بتوزيع ملف .skill. يضع أعضاء الفريق هذا الملف في دليل مهاراتهم.

هل يمكن للمهارات استدعاء واجهات برمجة التطبيقات الخارجية؟

نعم. قم بتجميع البرامج النصية التي تجري مكالمات API. تخبر تعليمات المهارة Claude متى وكيف يستخدمها. قم بتخزين مفاتيح API في متغيرات البيئة، وليس في المهارة نفسها.

ما هو حد حجم الملف للمهارات؟

لا يوجد حد صارم، ولكن حافظ على SKILL.md أقل من 500 سطر. انقل المراجع التفصيلية إلى ملفات منفصلة. لا تحتسب البرامج النصية والأصول ضمن حد السطر لأنها تُحمّل عند الطلب.

كيف أقوم بتحديث مهارة موجودة؟

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

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات

التسجيل مجانًاتحميل