كتابة أول skill لك

تعرف متى تستخدم skill. بناء واحد يكاد يكون مخيّبًا للحماس — إلى أن تصل إلى الجزء الوحيد المهم فعلًا.

الـ skill مجرد مجلد بداخله ملف SKILL.md. ما يصنع النجاح أو الفشل سطرٌ واحد: الـ description.

يفتتح ملف SKILL.md بترويسة صغيرة — name وdescription — ثم تعليمات بنص عادي تحته:

---
name: pr-description
description: Use when writing a pull request description. Summarizes the
  change from the commits and fills in the team's PR template.
---

When asked to write a PR description:
1. Look at the commits on the branch.
2. Group them into a short summary and a "what changed" list.
3. Fill in the template in .github/pull_request_template.md.

التعليمات هي الجزء السهل — فهي مجرد الطريقة التي تشرح بها الوظيفة لشخص.

الـ description هو الـ matcher، لا ملصق

هنا الجزء الذي يربك الناس. يغريك أن تكتب الـ description كعنوان: «مساعد وصف الـ PR». هذا عديم الفائدة — ليس لدى Claude ما يطابقه.

الـ description هو الشيء الوحيد الذي يقرأه Claude حين يقرر إن كان سيلجأ إلى الـ skill. عليه أن يجيب عن سؤال واحد: متى ينبغي أن ينطلق هذا؟

فتكتب المواقف داخله: «استخدم حين تكتب pull request description…». الآن، لحظة أن تقول «اكتب هذا الـ PR»، يطابقها.

الـ description ليس توثيقًا لإنسان يتصفّح قائمة skills. إنه الـ trigger. اكتبه لأجل متى، لا لأجل ماذا.

إذا لم ينطلق الـ skill الخاص بك أبدًا

تقريبًا كل مشكلة «الـ skill الخاص بي لا يعمل» هي المشكلة نفسها: الـ description لا يصف الموقف. لم يطابقه Claude قط، فلم يفتحه أبدًا.

الحل دائمًا هو نفسه — أعد كتابة الـ description ليسمّي اللحظات التي ينبغي أن يبدأ فيها، بالكلمات التي قد تستخدمها فعلًا حين تطرأ تلك المهمة.

(لست مضطرًا حتى إلى كتابة skills يدويًا — هناك skill لصنع الـ skills. لكن فهم ما يجعل الـ skill ينطلق هو الجزء الجدير بإبقائه في رأسك.)

ما التالي

هذا هو نصف «تغليف المعرفة» من هذا المستوى. أما الباقي فيدور حول الوقت — القيام بالعمل المستقل دفعةً واحدة بدلًا من قطعة تلو الأخرى. ابدأ صغيرًا: parallel tool calls.