השתמש בקידומת ! להרצת פקודות shell בתוך slash commands עם הזרקה אוטומטית של diff, תוכן קבצים ותוצאות בדיקות
ה-slash command של רוב האנשים נראה בערך כך:
בדוק את איכות השינויים הנוכחיים בקוד ותן הצעות קונקרטיות.
זה עובד, אבל יש כאן מגבלה יסודית: Claude צריך לנחש בעצמו "מה השינויים הנוכחיים". אם הפקודה שלך יודעת להזריק את ההקשר ישירות פנימה, התוצאה משתנה לחלוטין.
המאמר הזה מסביר איך להפוך פקודה ל"פקודה עם עיניים" — כשמפעילים אותה היא קוראת אוטומטית את תוכן הקבצים, את מצב git ואת מידע הפרויקט, ודוחפת את הכל לתוך ה-prompt, כך ש-Claude לא צריך לנחש.
!`פקודה` מזריק את הפלט של ה-shellcustom slash command תומך בהטמעת פקודות shell בתוך ה-prompt. התחביר הוא לעטוף את הפקודה ב-backtick ולהוסיף סימן קריאה לפניה: !`פקודה`. כשהפקודה מופעלת, פקודת ה-shell רצה ראשונה, הפלט שלה מחליף את ה-placeholder, ו-Claude מקבל prompt מורכב במלואו.
זה ה-git diff הנוכחי:
!`git diff HEAD`
עשה review לשינויים האלה, עם דגש על באגים לוגיים ובעיות אבטחה.
לפקודות מרובות שורות השתמש ב-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
...
עשה review לשינויים האלה, עם דגש על באגים לוגיים ובעיות אבטחה.
לא צריך להעתיק ולהדביק ידנית — ברגע שהפקודה מופעלת, ה-diff כבר בפנים.
---
allowed-tools: Bash(cat:*)
---
זה התוכן המלא של הקובץ הנוכחי:
!`cat $ARGUMENTS`
מצא את כל בעיות הביצועים הפוטנציאליות בקובץ הזה, עם מספרי שורות והצעות תיקון קונקרטיות.
שימוש: /perf app/models/order.rb
$ARGUMENTS מקבל את נתיב הקובץ, cat קורא את התוכן ומזריק אותו פנימה. Claude מקבל את הקוד האמיתי, לא תיאור עמום מסוג "תסתכל על הקובץ הנוכחי".
allowed-toolsב-frontmatter נותן הרשאה מראש לפקודתcat, כך שלא תופיע בקשת אישור כשהפקודה רצה. בלי השורה הזו תצטרך ללחוץ "Allow" ידנית בכל הפעלה. כל הדוגמאות שלמטה דורשות הצהרה דומה.
ה-branch הנוכחי ומצב השינויים:
!`git status --short`
!`git log --oneline -10`
על בסיס המידע שלמעלה, צור תיאור PR תמציתי שכולל את תוכן השינויים ואת המוטיבציה מאחוריהם.
הפקודה /pr הזו לא דורשת ממך לתאר "מה שיניתי" — היא קוראת זאת בעצמה.
מחסנית הטכנולוגיות של הפרויקט:
!`cat .claude/context/stack.md`
מבנה הדאטהבייס הנוכחי (טבלאות מרכזיות):
!`head -100 db/schema.rb`
על בסיס ההקשר שלמעלה, כתוב migration script עבור $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 "(אין קובץ קונבנציות)"`
---
עשה review לשינויים שלמעלה:
1. נכונות לוגית: מקרי קצה שלא טופלו, באגים לוגיים
2. בעיות אבטחה: SQL injection, בדיקת הרשאות, חשיפת מידע רגיש
3. עמידה בקונבנציות: האם תואם את ה-coding standard של הפרויקט
4. קריאוּת: שמות, הערות, מבנה
לכל בעיה ציין שם קובץ, מספר שורה והצעה קונקרטית. אם אין בעיות, תגיד שאין — אל תמציא כדי למלא.
הפקודה הזו לא דורשת ממך שום הכנה — כשמפעילים אותה, ה-diff, רשימת הקבצים והקונבנציות מוזרקים אוטומטית.
פקודות shell עלולות להיכשל (קובץ לא קיים, פקודה לא ב-PATH וכו'). השתמש ב-|| כדי לספק ערך ברירת מחדל ולמנוע מהפקודה להיתקע באמצע:
!`git diff HEAD 2>/dev/null || echo "(אין שינויים ב-git או שזה לא git repo)"`
!`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 טובה יותר. דחיסה של כל ה-codebase פנימה לא תהפוך אותו לחכם יותר — היא רק תאבד אותו בתוך הרעש.
שאלה נפוצה: האם מידע רקע של הפרויקט צריך להיות ב-CLAUDE.md או להיות מוזרק דינמית עם !?
קריטריון להחלטה:
| סוג מידע | איפה לשים |
|---|---|
| רקע פרויקט שדרוש בכל פעם (מחסנית טכנולוגיות, מבנה תיקיות, קונבנציות) | CLAUDE.md |
| מצב שמשתנה עם הזמן (diff נוכחי, תוצאות בדיקות, תוכן קבצים) | הזרקה דינמית עם ! |
| רקע שדרוש רק למשימה ספציפית (מסמכי עיצוב של מודול מסוים) | קריאה לפי דרישה עם !cat |
CLAUDE.md הוא ידע רקע קבוע, ! הוא תמונת מצב בזמן ביצוע המשימה. השניים משלימים זה את זה — אל תכפיל ביניהם.
.claude/commands/ שלמה.claude/
├── commands/
│ ├── review.md # review: מזריק 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/ שומרת קבצי רקע סטטיים שהפקודות השונות יכולות לקרוא לפי הצורך. אפשר לעשות commit למבנה הזה ישירות ל-git כדי לשתף אותו בין חברי הצוות.
פקודה סטטית:
בדוק את השינויים הנוכחיים בקוד.
Claude יצטרך לשאול קודם "איפה השינויים", או לחפש בעצמו, והתוצאה לא יציבה.
פקודה מודעת להקשר:
זה ה-diff (עם התוכן האמיתי), אלה הקונבנציות הרלוונטיות (עם התוכן האמיתי), עשה review.
Claude מתחיל לנתח מיד — תשובה מדויקת, בלי מילים מיותרות, בלי הלוך-חזור לאישור.
ההבדל הוא לא ביכולת של Claude אלא בכמות המידע האמיתי שנתת לו.