عندما تعملون مع وكيل، تتكرر بعض التعليمات مرة بعد مرة. ربما لديكم طريقة لمناقشة ميزة، أو لمراجعة الكود، أو للتحضير لإطلاق جديد. الـ skill يُبقي هذا الإجراء متاحًا عندما تحتاجون إليه. سنكتب واحدًا، ونرى كيف يُحمَّل، ونرى كيف يساعدنا استخدامه على تحسين التعليمات. السؤال المهم هو: هل يجعل الـ skill العمل أفضل؟
لنفترض أنكم تريدون مناقشة ميزة قبل أن ينفّذها الوكيل. تريدون أن يقرأ الوكيل سياق المشروع ذا الصلة، ويطرح القرارات المعلّقة، ويدوّن ما تتفقون على بنائه. يمكنكم شرح هذا الإجراء في كل محادثة. وحين تجدون طريقة عمل تريدون تكرارها، فمن المفيد أن تحفظوا هذه التعليمات في ملف.
الـ skill يجمع تعليمات نعيد استخدامها، يحمّلها الوكيل عند الحاجة. يمكنكم استدعاؤه باسمه، ويمكن للوكيل أيضًا أن يختاره حين يناسب وصفُه المهمة. تحميل الملف يضيف تعليمات إلى سياق النموذج. ولا يغيّر أوزان النموذج التي اكتسبها في التدريب. سنعود إلى تحسين الإجراء بعد أن نستخدمه.
في Claude Code، ضعوا الـ skill الخاص بالمشروع في مجلد داخل .claude/skills. اسم مجلدنا spec-discussion، وفيه الملف SKILL.md. سجّلوا هذه الملفات في commit لتشاركوا الإجراء مع من يعملون على المستودع. أما الـ skill الشخصي المتاح في كل مشاريعكم المحلية، فضعوه في مجلد skills داخل .claude في مجلدكم الرئيسي. والإضافات (plugins) قد تضمّ skills أيضًا.
يبدأ الملف بقسم front matter بصيغة YAML، بين سطرين في كل منهما ثلاث شرطات. ضعوا الشرطات الافتتاحية في السطر الأول. سمّوا الـ skill باسم مجلده، واكتبوا وصفًا يذكر غرضه ومتى يُستخدم. المتن نص Markdown عادي يحتوي على الإجراء. بنية المجلد والملف هذه تتبع معيار Agent Skills، لكن مسارات التثبيت والإعدادات الإضافية تختلف من أداة إلى أخرى.
الوصف يساعد الوكيل على أن يقرر هل يحمّل التعليمات. اذكروا ما يفعله الـ skill، وحدّدوا الموقف الذي يفيد فيه. في هذا المثال، يفيد الـ skill حين تتضمن الميزة قرارات تصميم مهمة لم تُحسم بعد. ومجرد غياب المواصفات ليس سببًا لمقاطعة كل تغيير صغير بجولة أسئلة.
هذا الوصف يشمل طلبًا صريحًا لنقاش التصميم، وميزة لا يزال سلوكها أو نطاقها أو تكاملها بحاجة إلى تفكير. ويستثني التغييرات الروتينية ذات المتطلبات الواضحة. وحتى المواصفات الموجودة قد تحتاج إلى نقاش عندما تتغير الميزة. هذه الحدود تساعد الوكيل على اختيار الإجراء للعمل الذي يكون فيه مفيدًا.
بعد الـ front matter يأتي المتن، والمتن هو الإجراء نفسه. وهو نص Markdown عادي، مكتوب على شكل تعليمات للوكيل، بالترتيب الذي تريدون أن تُنفَّذ به. يبدأ هذا المثال بما يقرؤه الوكيل وما يسأل عنه، ثم ما يكتبه، ومتى يتوقف. كل خطوة تذكر ما يجب فعله، بجمل بسيطة، والقاعدة التي تهمكم تُكتب على أنها قاعدة، لأن الوكيل يتبع النص حرفيًا. الخطوات نفسها ليست إلا طريقة من طرق إدارة نقاش التصميم. ما يهم في كتابة الـ skill هو الشكل: ماذا يقرأ الوكيل، وماذا يسأل، وماذا يكتب، ومتى يتوقف.
استدعوا الـ skill بكتابة /spec-discussion ثم طلبكم. تحقّقوا من أن تعليماته تُحمَّل. إذا لم يجده Claude Code، فتحقّقوا من المجلد واسم الملف، ومن المكان الذي بدأتم منه الجلسة. هذا الاستدعاء المباشر يمنحكم طريقة بسيطة لتجربة الإجراء دون الاعتماد أولًا على الاختيار التلقائي.
يواصل الوكيل النقاش معكم، ويتناول القرارات واحدًا تلو الآخر، ويحدّث المسودة. وأثناء العمل، راجعوا الميزة المقترحة والإجراء نفسه معًا. هل الأسئلة مفيدة؟ هل يستخدم الوكيل إجابات قدّمتموها من قبل؟ هل النتيجة المكتوبة تطابق ما اتفقتم عليه؟ ستتعلمون عن الـ skill من هذا العمل أكثر مما تتعلمونه من ظهور اسمه في الواجهة.
ابدؤوا بنسخة أولى مفيدة، وجرّبوها على عمل حقيقي. راجعوا ما يفعله الوكيل، وحدّدوا ما ساعد وما أعاق العمل، ثم عدّلوا التعليمات. كتابة الـ skill عملية تكرارية. فوصفكم الأول للإجراء سيُغفل غالبًا قرارًا ما، أو يتضمن خطوة يتبيّن أنها غير ضرورية.
احكموا على الـ skill بما يضيفه. هل ينبّهكم إلى قرارات كانت ستفوتكم لولاه؟ هل يوفّر عليكم تكرار التصحيح نفسه؟ هل ينتج شيئًا أسهل في المراجعة؟ الـ skill الذي يضيف أسئلة وشكليات دون أن يحسّن العمل يجب تعديله أو حذفه. كثرة الـ skills ليست تقدّمًا في حد ذاتها.
قارنوا الطلب نفسه في جلستين جديدتين، مع الـ skill ومن دونه. من دونه، بدأ الوكيل بتهيئة المشروع، ووصل إلى طلب إذن. ومعه، حين استُدعي باسمه، قرأ الوكيل المشروع الفارغ أولًا، ولم يجد قرارات محسومة، وطرح سؤال تصميم عن التخزين قبل أي شيء آخر. هذا يُظهر تغييرًا ملموسًا في طريقة بدء العمل. ابحثوا عن القرارات المهمة التي يطرحها النقاش مبكرًا، قبل التنفيذ.
ثم يتواصل النقاش من هذه النقطة. وأثناء العمل، قارنوا مقدار ما تقدّمونه من شرح وتصحيح بما قدّمتموه في مهام مشابهة دون الـ skill. المحادثة الأطول تستحق العناء إذا حسمت أسئلة مفيدة. أما الأسئلة المكررة أو الخارجة عن الموضوع فهي سبب لتعديل الإجراء.
راجعوا المواصفات الناتجة أيضًا. تحقّقوا من أنها تصف السلوك المقصود، وتلائم المشروع القائم، وتحفظ أسباب القرارات المهمة. مقارنة بداية الجلستين تُظهر أن الـ skill غيّر أول ما فعله الوكيل. أما فائدة الإجراء كله، فتحكمون عليها من العمل ونتيجته.
ويستطيع الوكيل أيضًا اختيار الـ skill بناءً على وصفه. تحقّقوا سريعًا بطلب يُفترض أن يفيد فيه، وبطلب آخر يُفترض ألّا يتدخل فيه. استخدموا إعدادكم المعتاد، فالتعليمات الأخرى تؤثر في هذا الاختيار. إذا كان يُختار أكثر من اللازم، أو لا يُختار حين يكون مناسبًا، فعدّلوا الوصف.
يمكنكم دائمًا طلب الـ skill مباشرة متى أردتم الإجراء الذي فيه. الاختيار التلقائي مجرد تسهيل، والتحقق منه أمر منفصل عن الحكم على جودة العمل. وحين يُحمَّل الـ skill، عودوا إلى السؤال: هل اتباعه مفيد؟
في Claude Code، يتحكم بهذين المسارين إعدادان في الـ front matter. ضبط disable-model-invocation على true يمنع الاستدعاء التلقائي، فتبدأون الإجراء بأنفسكم. وضبط user-invocable على false يعطّل أمر slash للمستخدم، مع إبقاء الـ skill متاحًا للنموذج. إخفاء الأمر ليس حاجزًا أمنيًا يمنع الوصول.
وهذا أيضًا مثال عملي على إدارة السياق. أما الـ skills المتاحة للاختيار التلقائي، فيبدأ الوكيل بقائمة من أسمائها وأوصافها، بدلًا من النص الكامل لكل إجراء. هذا القدر القليل من المعلومات يساعده على اختيار ما يحمّله. تقديم الملخّص أولًا والتفاصيل عند الحاجة هو الكشف التدريجي (progressive disclosure).
عند استدعاء الـ skill، يدخل متنه إلى سياق المحادثة. أما متون الـ skills الأخرى فتبقى خارج نافذة السياق حتى الحاجة إليها. لذلك يمكنكم الاحتفاظ بمجموعة من الإجراءات المفصّلة متاحةً دون تحميلها كلها في كل جلسة. التعليمات المحمّلة تشغل مساحة من السياق، وقد تظل تؤثر في الرسائل اللاحقة.
ويمكن تحميل المواد الداعمة ديناميكيًا أيضًا. إذا أحال الـ skill إلى مرجع أطول، فإن الوكيل يقرأ ذلك الملف حين يتطلبه الإجراء. وهذا يترك للمهمة الحالية مساحة أكبر مما لو وضعتم كل إجراء وكل مرجع في ملف تعليمات يُحمَّل دائمًا. اجعلوا الأوصاف موجزة أيضًا، لأن القائمة نفسها تشغل مساحة.
ركّزوا المتن على الخطوات والقرارات والفحوصات الخاصة بهذا الإجراء. ضعوا الشروح الطويلة في ملفات داعمة، وأضيفوا روابط إليها، وحدّدوا متى تُقرأ. الإيجاز مفيد لأنه يسهّل العثور على التعليمات المهمة. لكن أبقوا ما يلزم الوكيل من تفاصيل لينجز العمل كما يجب.
ضعوا أي حساب قابل للتكرار أو فحص آلي في سكربت، وأخبروا الوكيل كيف يشغّله. الـ skill يشرح الإجراء، أما الأدوات فتنفّذ العمليات، ومنها تشغيل هذا السكربت. لا حاجة إلى أن يركّب النموذج من جديد سلسلة ثابتة من الأوامر في كل مرة.
ضعوا قواعد المشروع الدائمة في ملف التعليمات الخاص به، مثل CLAUDE.md، والإجراءات الخاصة بمهام معيّنة في الـ skills. هذه الآليات تعمل معًا. ملف التعليمات يوفّر قواعد تنطبق على العمل كله، والـ skill يوفّر الإجراء المناسب، والأدوات تنفّذ عملياته.
مثال: الـ skill build-decks في مساقنا. فهو يصف للوكيل كيف يعمل على الشرائح والتعليق الصوتي لفيديوهات المساق. ويحيل إلى مراجع مفصّلة، ويشرح كيف نبني النتيجة ونتحقّق منها. الإجراء الرئيسي والمواد الداعمة لكل منهما دور مختلف. ويمكنكم استخدام البنية نفسها لأيّ طريقة عمل في مشروعكم الخاص.
بدأنا بتعليمات كانت تتكرر مرة بعد مرة، وتُشرح من جديد في كل محادثة. أما الآن فهي في ملف واحد، والوكيل يحمّلها بالاسم، أو حين يناسب الوصفُ المهمة، وكل استخدام يُريكم ما يجب إصلاحه في التعليمات. اختاروا إجراءً واحدًا تكررونه، واكتبوه، وحسّنوه أثناء العمل. والسؤال الذي يجب أن تواصلوا طرحه: هل يجعل الـ skill العمل أفضل؟