من Slash Commands إلى Skills: متى تهاجر وكيف

تناولت المقالات الثلاث السابقة استخدام slash command بالكامل: من ملف Markdown، إلى حقن !command، ثم تنسيق subagent و MCP. كل هذا لم يَعفُ عليه الزمن—لكن في الكواليس أجرى الفريق الرسمي عملية دمج: صارت custom commands جزءًا من Skills.

ملفك .claude/commands/review.md لا يزال يعمل، و/review لا يزال متاحًا، ولا يلزمك تغيير أي شيء. لكن إن أردت أن ينمو هذا الـ command بقدرات أكبر (عدة ملفات، تنفيذ عبر fork، تفعيل تلقائي حسب path)، فالمسار الجديد هو .claude/skills/review/SKILL.md. هذه المقالة توضح أمرين: كيف تهاجر، وهل يستحق الأمر الهجرة.

الحد الأدنى من الهجرة: غيِّر path واحدًا واترك الباقي

وعد التوافق الرسمي واضح: كلٌّ من .claude/commands/deploy.md و .claude/skills/deploy/SKILL.md يُسجَّل باسم /deploy، وبنفس الوظيفة تمامًا. وعند تعارض الأسماء، تُقدَّم الـ skills.

خطوات الهجرة الدنيا:

cd .claude/commands
mkdir -p ../skills/review
mv review.md ../skills/review/SKILL.md

لا يحتاج محتوى الملف لتعديل سطر واحد. YAML frontmatter و !`command` و @file و $ARGUMENTS—كلها متوافقة.

لكن إن اكتفيت بهذا، سيسأل القارئ: فلماذا الهجرة أصلًا؟ الجواب أن مجلد الـ skill يستوعب عدة ملفات، بينما الـ command ملف واحد فقط.

لماذا تهاجر: أربعة أشياء إضافية في SKILL.md

1. الملفات المساعِدة: افصل المستندات الطويلة

SKILL.md هو نقطة الدخول، والمجلد نفسه يسع أي ملفات ملحقة. تخيل بنية كهذه:

.claude/skills/review/
├── SKILL.md            # نقطة الدخول، تعليمات موجزة + مراجع
├── checklist.md        # قائمة مراجعة كود طويلة
├── examples/
│   └── good-diff.md    # مثال جيد
└── scripts/
    └── lint.sh         # script يمكن لـ SKILL.md استدعاؤه

داخل SKILL.md تُشير إلى الملفات بمسار نسبي:

راجع الـ diff الحالي وفق المعايير في [checklist.md](checklist.md).
انظر [examples/good-diff.md](examples/good-diff.md) لفهم صيغة المخرجات المتوقعة.

هذه الملفات المساعِدة لا تدخل في context تلقائيًا—إنما يقرؤها Claude عند الحاجة. التوصية الرسمية أن يبقى SKILL.md دون 500 سطر، ويُنقل ما زاد إلى الملفات المساعِدة.

2. `disable-model-invocation`: أي skill لا يُفعَّل إلا يدويًا منك

افتراضيًا يستدعي Claude أي skill من تلقاء نفسه حين يرى المناسبة. هذا خطر على الـ commands ذات الآثار الجانبية مثل /deploy و /commit و /send-email—فأنت لا تريده أن "يستحسن الكود فيذهب للـ deploy".

---
name: deploy
description: النشر إلى production
disable-model-invocation: true
allowed-tools: Bash(kamal deploy:*), Bash(git push:*)
---

بعد إضافة هذا السطر، لا يُفعَّل /deploy إلا إذا كتبته أنت بنفسك، ولن يستدعيه Claude من تلقاء نفسه في أثناء المحادثة.

على النقيض، user-invocable: false يعني "لا يستدعيه إلا Claude، ولا يظهر في قائمة /"—ويناسب skills ذات طابع المعرفة الخلفية (مثل legacy-system-context: يحمّله Claude تلقائيًا في السياقات المعنيّة، ولا معنى لأن تستدعيه أنت يدويًا).

3. `context: fork`: اجعل الـ skill يعمل داخل subagent

هذه الترقية الأكبر. ذكرت المقالة السابقة أن الـ command يستطيع استخدام allowed-tools: Task ليطلب من النموذج تشغيل subagent—لكنك كنت مضطرًا لوصف "شغّل subagent من نوع Explore ليقوم بـ..." يدويًا في الـ prompt.

SKILL يحل ذلك بسطر واحد في الـ frontmatter:

---
name: deep-research
description: بحث معمّق في رمز معيّن
context: fork
agent: Explore
---

ابحث في جميع استخدامات $ARGUMENTS:
- كل نقاط الاستدعاء
- السياقات التجارية
- التطبيقات البديلة

أعِد ملخصًا ≤300 كلمة.

عند تفعيل /deep-research SomeClass: يتحول محتوى SKILL.md كاملًا إلى prompt لـ subagent مستقل، يُشغَّل بنوع agent هو Explore، وعند الانتهاء يُعيد الخلاصة فقط. يبقى context المحادثة الرئيسية نظيفًا تمامًا.

أي أن مسألة "تشغيل subagent" انتقلت من وصف نصي داخل الـ prompt إلى خاصية تصريحية في الـ skill.

4. `paths`: تفعيل تلقائي حسب نوع الملف

---
name: rails-conventions
description: أعراف الكتابة في مشاريع Rails
paths: ["app/**/*.rb", "config/**/*.rb"]
---

التزم بأعراف Rails في هذا المشروع:
- استخدم service object بدل fat controller
- يجب تسمية ActiveRecord scope
...

حين تحرّر app/models/user.rb، يُضاف هذا الـ skill إلى context تلقائيًا؛ وعند تحرير package.json لا يُضاف. وهو أدقّ من CLAUDE.md العام—فكِّر فيه على أنه "CLAUDE.md مقسَّم إلى طبقات حسب path".

تطبيق: ترقية `/plan` إلى skill

كان مثال /plan في نهاية المقال السابق مجرد command من ملف واحد:

.claude/commands/plan.md

ترقيتها إلى skill:

.claude/skills/plan/
├── SKILL.md
├── research-prompt.md     # تعليمات الـ subagent الأول
└── risk-prompt.md         # تعليمات الـ subagent الثاني

SKILL.md:

---
name: plan
description: إنتاج خطة تنفيذ من Linear ticket
disable-model-invocation: true
allowed-tools: mcp__linear__*, Task, Read, Grep, Bash(git log:*)
---

## Context

@.claude/context/architecture.md

## الحالة

!`git log --oneline -10`

## المهمة

اسحب وصف وتعليقات Linear ticket $ARGUMENTS.

استخدم Task لتشغيل subagentين بالتوازي:
1. بحث الكود: الـ prompt في [research-prompt.md](research-prompt.md)
2. تقييم المخاطر: الـ prompt في [risk-prompt.md](risk-prompt.md)

ادمج النتيجتين ثم أخرج خطوات التنفيذ + قائمة المخاطر + توصية بدقة الـ commit.

prompt الـ subagentين موضوع في ملفات منفصلة؛ حين تحتاج إلى تعديل، تغيّر مكانًا واحدًا دون المساس بـ SKILL.md. يبقى الـ skill ذاته نظيفًا في أقل من 30 سطرًا، فيما يمكن للملفات المساعِدة أن تكون مئات الأسطر من التفاصيل.

وإن لم تشأ أن تُنسِّق الـ subagents بنفسك، فثمة خيار أكثر جذرية—ارمِ الـ skill كله داخل fork، ودع Explore agent ينفذه دفعة واحدة:

---
name: plan
context: fork
agent: Explore
allowed-tools: mcp__linear__*
---

تفعيل /plan ENG-4213 ← يتسلّم Explore agent في context مستقل محتوى SKILL.md كله كمهمة ← ويُعيد الخطة النهائية فقط. تبقى المحادثة الرئيسية نظيفة تمامًا.

متى لا تحتاج إلى الهجرة

ليست كل الـ commands تستحق الترقية. الحالات التي يبقى معها الملف في .claude/commands/ أنسب:

ملف Markdown واحد يكفي: لا توجد checklist أو examples أو scripts بحاجة إلى فصل
لا حاجة لتنفيذ عبر fork: المهمة ملتصقة بالمحادثة الرئيسية وتحتاج إلى رؤية التاريخ الكامل
لا حاجة للتفعيل التلقائي حسب path: يستدعيها المستخدم يدويًا
لا حاجة لضبط الوصول: لا ضير في أن يستدعيها Claude من تلقاء نفسه

/commit و/pr-desc البسيطة هي مجرد frontmatter مع بضعة أسطر من الـ prompt—ووضعها في .claude/commands/ أكثر مباشرة. صرّح الفريق الرسمي بوضوح أن الصيغتين متعايشتان، ولن يُلغى أيٌّ منهما.

حال التعايش الراهن

أنظف ترتيب لـ .claude/ الآن:

.claude/
├── commands/           # خفيف: ملف واحد + prompt بسيط
│   ├── commit.md
│   └── pr-desc.md
├── skills/             # ثقيل: عدة ملفات / fork / ضبط صلاحيات
│   ├── plan/
│   │   ├── SKILL.md
│   │   ├── research-prompt.md
│   │   └── risk-prompt.md
│   ├── deploy/
│   │   └── SKILL.md    # disable-model-invocation
│   └── rails-conventions/
│       └── SKILL.md    # تفعيل تلقائي عبر paths glob
└── context/
    └── coding-standards.md

لا تهاجر كل شيء دفعة واحدة. شرط الهجرة هو "أن هذا الـ command بدأ يتضخّم"—تجاوز محتواه 200 سطر، أو احتاج إلى فصل مستندات، أو أردت تنفيذه في subagent. عندها تغيّر الـ path، وهي دقائق معدودة.

الخلاصة

القدرة المطلوبة	`commands/`	`skills/`
اختصار prompt من ملف واحد	✅	✅
!`command` / `@file` / `$ARGUMENTS`	✅	✅
ضبط الصلاحيات عبر `allowed-tools`	✅	✅
الملفات المساعِدة (reference، scripts)	❌	✅
`disable-model-invocation` لمنع الاستدعاء الخاطئ	❌	✅
`context: fork` + `agent:` لتنفيذ معزول	❌	✅
تفعيل تلقائي عبر `paths:` glob	❌	✅

البنود الثلاثة الأولى متكافئة تمامًا بين commands و skills؛ البنود الأربعة الأخرى حكرٌ على skills. استخدم ما تحتاج إليه، ودع ما لا تحتاج إليه.

يميل المسار الرسمي باتجاه skills، لكن وعد التوافق مع commands/ واضح جدًّا—ليس هذا تغييرًا من نوع "هاجر فورًا وإلا سقطت"، بل هو توسيعٌ يمنحك قدرات جديدة دون أن يُجبرك. افهم الفوارق، هاجر حسب الحاجة، ولا تسعَ إلى الترتيب الشكلي فقط.