٥ قواعد لكتابة body في SKILL.md مخفية في وثائق Anthropic

يحتاج الـ Skill إلى سطرين فقط من YAML frontmatter ليعمل. لكن طريقة كتابة الـ body هي التي تحدد جودة المخرجات بالكامل.

بعد مقارنة الوثائق الرسمية لـ Anthropic مع مدونتهم الهندسية، استخلصت آليات العمل ومبادئ كتابة الـ body في خمس قواعد. بدأت هذه الرحلة لأن الـ Skills التي كتبتها بنفسي كانت تفشل في التحميل أحياناً، فاستغللت عطلة نهاية الأسبوع للتحقق من كل شيء من الصفر.

إذا لم تفهم ترتيب تنفيذ الـ Skills، سيفشل تصميم الـ body

الـ Skills لا تُحقن في المحادثة مثل الـ prompt. عند البدء، يُحمّل فقط الـ name والـ description في prompt النظام.

عندما يتطابق طلب المستخدم مع الـ description، يستخدم Claude أداة Bash لقراءة SKILL.md بالكامل. بعدها فقط يحمّل ملفات المراجع والسكربتات حسب الحاجة. مدونة Anthropic الهندسية تسمي هذه البنية “الكشف التدريجي (progressive disclosure)”.

• المرحلة الأولى: البيانات الوصفية فقط (name + description) محمّلة دائماً. حوالي ١٠٠ token لكل Skill.
• المرحلة الثانية: body الـ SKILL.md يدخل نافذة السياق فقط عند التطابق.
• المرحلة الثالثة: ملفات مجلدات scripts و references تُحمّل في لحظة الاستخدام الفعلي.
• عند تنفيذ السكربتات، الكود نفسه لا يدخل السياق, فقط المخرجات تُستهلك.

بدون فهم هذه البنية، ستملأ الـ body بمعلومات غير ضرورية وتفوّت ما يهم فعلاً.

كتابة “متى تستخدم” في الـ body تهدر الـ tokens

كثير من الناس يضيفون قسم “When to Use This Skill” في الـ body. بعد إنشاء Skills خاصة بي، اكتشفت أن هذا عديم الفائدة تماماً. الـ body يُقرأ فقط بعد تفعيل الـ Skill.

“متى تستخدم” يجب أن تكون حصرياً في الـ description. مستودع skill-creator الرسمي من Anthropic يوضح هذه النقطة صراحةً.

• الـ description هو آلية التفعيل الوحيدة (Claude لا يرجع لمحتوى “متى تستخدم” في الـ body)
• الـ description محدود بـ ١٬٠٢٤ حرفاً. الكتابة بصيغة الغائب تحسّن دقة الاكتشاف.
• الـ body يجب أن يحتوي على قواعد المهمة والإجراءات وأشكال المخرجات المتوقعة.
• احذف جمل مثل “استخدم هذا الـ Skill عندما…” من الـ body.

اجعل الـ body أقل من ٥٠٠ سطر وافصل الباقي

السطر الأول في دليل Anthropic يقول إن نافذة السياق مورد مشترك. بمجرد تحميل Skill، يتشارك الـ tokens مع سجل المحادثة و prompt النظام.

التوصية الرسمية هي إبقاء الـ body أقل من ٥٠٠ سطر واستخراج المحتوى التفصيلي إلى ملفات منفصلة. SKILL.md يعمل كجدول محتويات، وملفات المراجع تعمل كفصول مستقلة.

• الـ body أقل من ٥٠٠ سطر (مذكور في best practices الخاصة بـ Anthropic)
• ملفات المراجع تُربط بعمق طبقة واحدة فقط من SKILL.md
• مع طبقتين أو أكثر من المراجع المتداخلة، قد يقرأ Claude فقط أول ١٠٠ سطر عبر head -100
• أضف جدول محتويات في بداية أي ملف مرجعي يتجاوز ١٠٠ سطر

اكتب على أساس أن Claude ذكي بالفعل

شرح ما هو PDF في الـ body يهدر الـ tokens. هناك مبدأ يؤكد عليه دليل Anthropic مراراً:

“لا تكتب ما يعرفه Claude مسبقاً.”

مثال كود مختصر من ٥٠ token يتفوق على شرح مفاهيمي من ١٥٠ token. في اختباراتي على نفس مهمة استخراج PDF، الـ body المختصر أنتج دقة أعلى بشكل ملحوظ من الـ body المطوّل.

• اسأل نفسك عن كل جملة: “هل هذا الشرح يستحق الـ tokens المنفقة؟”
• استبدل الشروحات المفاهيمية بأمثلة كود + أشكال مخرجات متوقعة
• صنّف حرية المهمة إلى ثلاث مستويات (عالية/متوسطة/منخفضة) لمعايرة شدة التعليمات
• اضبط حرية منخفضة لمهام مثل ترحيل قواعد البيانات. عالية لمراجعات الكود.

ادمج حلقات التحقق في الـ body لتحسين الجودة

تنفيذ → تحقق → إصلاح → إعادة تحقق. هذا أكثر نمط body عملي توصي به Anthropic. دمج قوائم التحقق في الـ body يقلل بشكل ملحوظ احتمالية تخطي Claude للخطوات.

الدليل الرسمي يشير أيضاً إلى أن اللغة القوية مثل “MUST filter” تحقق نسبة امتثال أعلى من “always filter”.

• فصّل الخطوات بصيغة قائمة تحقق للمهام المعقدة
• ضمّن حلقات تحقق من السكربت → إصلاح الخطأ → إعادة التحقق في الـ body
• استخدم “MUST” بدل “always”, نسبة امتثال Claude تتحسن
• اكتب رسائل خطأ محددة حتى يتمكن Claude من التصحيح التلقائي

الخلاصة

الـ description يقرر متى يُفعّل الـ Skill. الـ body يقرر كيف يُنفّذ. في اللحظة التي تخلط فيها هذين الدورين، الـ Skill لن يُفعّل بشكل صحيح ولن ينتج مخرجات بجودة عالية.

الـ Skill الجيد مثل وثيقة onboarding جيدة. أقوى الوثائق هي التي تبدأ من افتراض أن القارئ ذكي بالفعل.