استخدم البادئة ! لتنفيذ أوامر shell داخل slash commands مع حقن diff ومحتوى الملفات ونتائج الاختبارات تلقائياً
أوامر slash لدى معظم الناس تبدو هكذا:
راجع جودة التغييرات الحالية في الكود وقدّم اقتراحات محددة.
هذا ينجح، لكن له قيد جوهري: على Claude أن يستنتج بنفسه "ما هي التغييرات الحالية". أما إذا تمكّن أمرك من حقن السياق مباشرة بنفسه، فستختلف النتيجة اختلافاً جذرياً.
يتناول هذا المقال كيف تحوّل الأمر إلى أمر "له عينان" — عند تشغيله يقرأ تلقائياً محتوى الملفات وحالة git ومعلومات المشروع، ثم يحشر كل ذلك داخل البرومبت كي لا يضطر Claude إلى التخمين.
!`أمر` لحقن مخرجات الـ shellتدعم أوامر slash المخصصة تضمين أوامر shell داخل البرومبت. الصياغة هي تغليف الأمر بعلامتي backtick مع وضع علامة تعجب أمامه: !`أمر`. عند التشغيل يُنفَّذ الأمر أولاً، وتحلّ مخرجاته محل العنصر النائب، فيتلقّى Claude برومبتاً مكتمل التركيب.
هذا هو git diff الحالي:
!`git diff HEAD`
راجع هذه التغييرات وركّز على الأخطاء المنطقية والمشكلات الأمنية.
للأوامر متعددة الأسطر، استخدم fenced code block يبدأ بـ
```!:```! node --version git status --short ```
عند تشغيل /review، يكون المحتوى الذي يتلقّاه Claude فعلياً كالتالي:
هذا هو git diff الحالي:
diff --git a/app/models/user.rb b/app/models/user.rb
index 3a2f1c8..9b4e2d1 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -12,6 +12,9 @@ class User < ApplicationRecord
...
راجع هذه التغييرات وركّز على الأخطاء المنطقية والمشكلات الأمنية.
لا حاجة إلى نسخ ولصق يدوي. لحظة تشغيل الأمر يكون الـ diff قد دخل إلى الداخل بالفعل.
---
allowed-tools: Bash(cat:*)
---
هذا هو المحتوى الكامل للملف الحالي:
!`cat $ARGUMENTS`
ابحث عن جميع مشاكل الأداء المحتملة في هذا الملف، مع تحديد أرقام الأسطر وطرق الإصلاح بشكل ملموس.
طريقة الاستخدام: /perf app/models/order.rb
يستقبل $ARGUMENTS مسار الملف، ويقرأ cat المحتوى ويحقنه. يحصل Claude على الكود الفعلي، وليس على وصف مبهم من نوع "انظر إلى الملف الحالي".
يمنح
allowed-toolsفي الـ frontmatter صلاحية مسبقة لأمرcat، فلا تظهر نافذة طلب الإذن عند التشغيل. بدون هذا السطر سيكون عليك الضغط على "السماح" يدوياً في كل تشغيل. جميع الأمثلة أدناه تحتاج إلى الإعلان نفسه.
الفرع الحالي وحالة التغييرات:
!`git status --short`
!`git log --oneline -10`
بناءً على المعلومات أعلاه، ولّد وصفاً مختصراً لـ PR يتضمن محتوى التغييرات ودوافعها.
أمر /pr هذا لا يطلب منك أن تشرح "ماذا غيّرت" — هو يقرأ ذلك بنفسه.
المكدّس التقني للمشروع:
!`cat .claude/context/stack.md`
البنية الحالية لقاعدة البيانات (الجداول الأساسية):
!`head -100 db/schema.rb`
اعتماداً على السياق أعلاه، اكتب سكربت ترحيل (migration) للـ $ARGUMENTS متوافقاً مع معايير المشروع.
اكتب معلومات خلفية المشروع مسبقاً داخل دليل .claude/context/، ودَع الأمر يقرأها عند الحاجة، بدلاً من إعادة وصف المشروع في كل مرة.
نتيجة آخر تشغيل للاختبارات:
!`bundle exec rspec --format progress 2>&1 | tail -30`
ما سبق هو الاختبارات التي فشلت. حلّل السبب الجذري وقدّم خطة إصلاح، دون تعديل الاختبارات نفسها.
عند تشغيل /fix-tests تُنفَّذ الاختبارات على الفور وتُجلب نتائجها. ما يراه Claude هو رسائل خطأ حقيقية.
عند جمع كل ما سبق، يستطيع /review أن يكون دقيقاً تماماً:
---
description: راجع التغييرات الحالية، وأحقن الـ diff والسياق ذا الصلة تلقائياً
allowed-tools: Bash(git diff:*), Bash(cat:*)
---
## التغييرات هذه المرة
!`git diff HEAD`
## قائمة الملفات المتأثرة
!`git diff HEAD --name-only`
## ملخّص معايير كتابة الكود في المشروع
!`cat .claude/context/coding-standards.md 2>/dev/null || echo "(لا يوجد ملف معايير)"`
---
راجع التغييرات أعلاه:
1. صحة المنطق: حالات حدّية لم تُعالَج، أخطاء منطقية
2. مشاكل أمنية: SQL injection، تحقّق من الصلاحيات، تسرّب معلومات حساسة
3. مدى التوافق مع المعايير: هل يتوافق مع معايير الكود في المشروع
4. القابلية للقراءة: التسمية، التعليقات، البنية
لكل مشكلة اذكر اسم الملف، ورقم السطر، واقتراحاً ملموساً. إن لم توجد مشاكل فقل ذلك صراحةً، ولا تختلق مشاكل لتعبئة الفراغ.
هذا الأمر لا يطلب منك أي تحضير — بمجرد تشغيله، يُحقَن الـ diff وقائمة الملفات والمعايير كلها تلقائياً.
قد تفشل أوامر الـ shell (الملف غير موجود، الأمر ليس في PATH، إلخ). استخدم || لتقديم قيمة افتراضية كي لا يتوقف الأمر بسبب ذلك:
!`git diff HEAD 2>/dev/null || echo "(لا توجد تغييرات في git أو لسنا داخل مستودع git)"`
!`cat .env.example 2>/dev/null || echo "(لا يوجد ملف .env.example)"`
!`which rspec > /dev/null 2>&1 && bundle exec rspec --dry-run 2>&1 | head -20 || echo "(لم يُكتشف RSpec)"`
عند فشل الأمر يتلقّى Claude نصاً توضيحياً بدلاً من فراغ، فيستطيع تعديل استراتيجيته في الإجابة بناءً على ذلك.
كل مخرجات أوامر ! تدخل إلى نافذة السياق (context window). من الفخاخ الشائعة:
لا تستخدم cat على ملف كبير بأكمله
# خطر: قد يحقن عشرات الآلاف من الأسطر
!`cat db/schema.rb`
# الأفضل: خذ فقط الجزء المطلوب
!`grep -A 5 "create_table \"orders\"" db/schema.rb`
ضع حداً لعدد الأسطر في ملفات الـ log
!`tail -50 log/development.log`
اقتطع مخرجات الاختبارات
!`bundle exec rspec 2>&1 | tail -40`
كلما كان السياق أدق كانت إجابة Claude أفضل. حشر قاعدة الكود بأكملها لن يجعله أذكى، بل سيُضيعه وسط الضجيج.
سؤال شائع: هل ينبغي وضع معلومات خلفية المشروع في CLAUDE.md أم حقنها ديناميكياً عبر !؟
معيار التمييز:
| نوع المعلومات | أين توضع |
|---|---|
| خلفية مشروع مطلوبة في كل مرة (المكدّس التقني، بنية الأدلة، المعايير) | CLAUDE.md |
| حالة تتغيّر مع الوقت (الـ diff الحالي، نتائج الاختبارات، محتوى الملفات) | حقن ديناميكي عبر ! |
| خلفية تحتاجها مهمة محددة فقط (وثائق تصميم وحدة معينة) | قراءة عند الطلب بـ !cat |
CLAUDE.md معرفة خلفية دائمة، أما ! فلقطة لحظية وقت تنفيذ المهمة. الاثنان يتكاملان، فلا تكرّر بينهما.
.claude/commands/ كامل.claude/
├── commands/
│ ├── review.md # المراجعة: حقن diff + معايير
│ ├── test.md # كتابة اختبارات: حقن الملف المستهدف
│ ├── fix-tests.md # إصلاح الاختبارات: حقن النتائج الفاشلة
│ ├── pr.md # وصف PR: حقن git log + status
│ ├── explain.md # شرح الكود: حقن محتوى الملف
│ └── migrate.md # كتابة migration: حقن مقتطف من schema
├── context/
│ ├── stack.md # شرح المكدّس التقني
│ └── coding-standards.md # معايير كتابة الكود
└── settings.json
يُخزَّن في دليل context/ ملفات الخلفية الثابتة لتقرأها مختلف الأوامر عند الحاجة. هذه البنية يمكن إيداعها مباشرة في git ومشاركتها مع الفريق.
أمر ثابت:
راجع تغييرات الكود الحالية.
سيحتاج Claude إلى أن يسأل أولاً "أين توجد التغييرات"، أو يبحث بنفسه، فتكون النتائج غير مستقرة.
أمر واعٍ بالسياق:
هذا هو الـ diff (مع المحتوى الفعلي)، وهذه هي المعايير ذات الصلة (مع المحتوى الفعلي)، فضلاً راجع.
يبدأ Claude التحليل مباشرةً — إجابات دقيقة، بلا حشو، ودون حاجة إلى تبادل تأكيدات.
الفرق ليس في قدرات Claude، بل في كمّ المعلومات الحقيقية التي قدّمتها له.