Slash Command: بناء نظام أوامر قابل لإعادة الاستخدام في Claude Code

يأتي Claude Code مع عدد من slash commands المدمجة — /help، /clear، /compact. لكن الأوامر التي تُسرّع سير العمل فعلاً هي تلك التي تكتبها بنفسك.

تتناول هذه المقالة كيفية تصميم نظام slash commands قابل لإعادة الاستخدام، حتى يتشارك الفريق بأكمله مكتبة prompts واحدة، بدلاً من إعادة كتابة وصف المهام من الصفر في كل مرة.

ما هو Slash Command المخصص

في Claude Code، الـ slash command المخصص هو ببساطة ملف Markdown. ضعه في الدليل الصحيح، يكتشفه Claude Code عند التشغيل، وكتابة /اسم-الملف يُفعّله.

محتوى الملف هو الـ prompt الذي يُرسَل إلى Claude. هذا كل شيء.

لا توجد صياغة خاصة، ولا تنسيق إعدادات — ملف .md واحد يساوي أمراً واحداً.

أين توضع الملفات

موقعان، غرضان مختلفان:

الموقع	المسار	النطاق
المشروع	.claude/commands/	المشروع الحالي فقط، يمكن إضافته إلى git
المستخدم	~/.claude/commands/	جميع المشاريع، شخصي

مستوى المشروع هو جوهر المشاركة في الفريق. أضف .claude/commands/ إلى git، وسيحصل كل من يستنسخ المستودع تلقائياً على مجموعة الأوامر الكاملة.

مستوى المستخدم مناسب للعادات الشخصية — عمليات التحقق من أسلوب الكود التي تفضلها، أو تكاملات الأدوات التي تستخدمها وحدك.

إنشاء أول Command

من جذر المشروع:

mkdir -p .claude/commands

أنشئ .claude/commands/review.md:

راجع جودة الكود في التغييرات الحالية. ركّز على:

1. الأخطاء المنطقية وحالات الحافة
2. وضوح التسمية
3. الكود المكرر الذي يستحق الاستخراج
4. مشاكل الأمان (حقن SQL، XSS، الأسرار المكشوفة)

قدّم اقتراحات محددة وقابلة للتنفيذ — لا نصائح عامة.

أعد تشغيل Claude Code واكتب /review لتفعيله.

استخدام $ARGUMENTS لاستقبال المدخلات

الأوامر ذات المحتوى الثابت محدودة الاستخدام. $ARGUMENTS يجعلها مرنة — ما يكتبه المستخدم بعد /الأمر يُدرج في الـ prompt.

مثال .claude/commands/test.md:

اكتب اختبارات للتالي: $ARGUMENTS

المتطلبات:
- غطّ المسار الطبيعي وحالات الحافة
- أسماء الاختبارات يجب أن تكون واضحة بذاتها
- استخدم بيانات حقيقية بدلاً من mocks حيثما أمكن

الاستخدام:

/test دالة login في الكلاس UserAuthentication

يستقبل Claude:

اكتب اختبارات للتالي: دالة login في الكلاس UserAuthentication

المتطلبات:
...

يمكن لـ $ARGUMENTS أن يظهر في أي مكان بالـ prompt ويستخدم أكثر من مرة.

مبادئ التصميم

أمر واحد، مسؤولية واحدة

لا تكتب أمراً "للكل" يضم كل المهام. /review للمراجعة فقط، /test لكتابة الاختبارات فقط، /pr لأوصاف PR فقط. الأوامر المحددة أسهل في التذكر وإعادة الاستخدام.

اكتب prompts محددة، لا مجردة

سيء:

ساعدني في تحسين هذا الكود


جيد:
```
حسّن هذا الكود من ناحية الأداء. أولوياتك:
1. تقليل استعلامات قاعدة البيانات غير الضرورية (مشاكل N+1)
2. تجنب الحسابات المتكررة داخل الحلقات
3. استبدال البحث الخطي بهياكل بيانات أكثر كفاءة

أبقِ الواجهة دون تغيير — غيّر التنفيذ الداخلي فقط.
```

القيود المحددة تؤدي إلى نتائج دقيقة.

أضف frontmatter إلى أوامرك

يظهر حقل description في قائمة أوامر Claude Code، ليفهم أعضاء الفريق بسرعة الغرض من كل أمر:

---
description: يراجع التغييرات الحالية ويقدم ملاحظات حول جودة الكود
---

راجع جودة الكود في التغييرات الحالية...

مجموعة عملية من Commands على مستوى المشروع

لمشروع Rails، تغطي هذه الأوامر مهام التطوير اليومية الأكثر شيوعاً:

.claude/commands/review.md — مراجعة الكود

```markdown

description: يراجع التغييرات الحالية للمنطق والأمان وسهولة القراءة

راجع التغييرات في git diff. تحقق من:
- الأخطاء المنطقية ومعالجة حالات الحافة
- مشاكل الأمان: حقن SQL، فحوصات التفويض
- وضوح التسمية
- المنطق المكرر الذي يستحق الاستخراج

لكل مشكلة، حدد الموقع الدقيق واقتراحاً محدداً.
```

.claude/commands/test.md — توليد الاختبارات

```markdown

description: يولّد حالات اختبار للكود المحدد

اكتب اختبارات لهذا الكود: $ARGUMENTS

استخدم RSpec. الغطاء: المسار الطبيعي، قيم الحافة، شروط الأخطاء.
تنسيق التسمية: describe ... context ... it ...
استخدم الكائنات الحقيقية افتراضياً؛ اعمل mock للتبعيات الخارجية عند الضرورة فقط.
```

.claude/commands/pr.md — وصف PR

```markdown

description: يولّد عنوان ووصف PR من التغييرات الحالية

بناءً على git diff وسجل الـ commits، أنشئ وصفاً لـ PR.

الشكل:

ما الذي تغيّر

(2-3 جمل تلخّص ما تم)

لماذا

(الخلفية والدافع)

كيفية الاختبار

(كيفية التحقق من هذا التغيير)

كن موجزاً، مكتوباً لمراجع الكود.
```

.claude/commands/explain.md — شرح الكود

```markdown

description: يشرح وظيفة الملف أو الدالة المحددة

اشرح ما يفعله $ARGUMENTS:
- ما هي مسؤوليته الإجمالية؟
- كيف تعمل المنطق الأساسي؟
- ما حالات الحافة التي تستحق الملاحظة؟

اكتب لمطور جديد على هذا الجزء من الكود. ركّز على لماذا، لا على ماذا فقط.
```

Commands على مستوى المستخدم: سير العمل الشخصي

بعض العادات شخصية ولا يجب فرضها على الفريق بأكمله. ضعها في ~/.claude/commands/:

~/.claude/commands/standup.md — تحضير الاجتماع اليومي
```markdown
بناءً على git log اليوم والـ TODOs المفتوحة، أعدّ ملخصاً للاجتماع اليومي:
- ما أنجزته أمس
- ما أخطط للقيام به اليوم
- هل يوجد عوائق

بحد أقصى 5 جمل.
```

~/.claude/commands/refactor.md — اقتراحات إعادة الهيكلة
```markdown
حلّل $ARGUMENTS واقترح تحسينات لإعادة الهيكلة.

اطرح فقط التغييرات ذات القيمة الحقيقية — لا تُعيد الهيكلة من أجل إعادة الهيكلة.
لكل اقتراح، وضّح: أي مشكلة يحل، وكم الجهد المطلوب، وما المخاطر.
```

مفتاح اعتماد الفريق: الإضافة إلى git

القيمة الحقيقية للأوامر المخصصة ليست الإنتاجية الشخصية — بل منح الفريق لغة مشتركة.

أضف .claude/commands/ إلى المستودع ووثّق الأوامر المتاحة في README أو CLAUDE.md. يحصل الأعضاء الجدد على مكتبة prompts التي جمعها الفريق لحظة استنساخهم للمستودع، دون الحاجة للاكتشاف بأنفسهم.

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

هيكل الدليل المرجعي

.claude/
├── commands/
│   ├── review.md      # مراجعة الكود
│   ├── test.md        # توليد الاختبارات
│   ├── pr.md          # وصف PR
│   └── explain.md     # شرح الكود
└── settings.json