Slash Command מתקדם: סוכני משנה ותזמור כלים

שני המאמרים הראשונים סיפרו מהו slash command (קובץ Markdown) וכיצד להשתמש בקידומת ! כדי להזריק פלט shell להקשר. המאמר הזה הולך רחוק יותר: איך לגרום לפקודה אחת לתזמר את היכולות החזקות ביותר של Claude Code — הפניות לקבצים, סוכני משנה, כלי MCP — תוך שמירה על ההרשאות בשליטה.

כשמגיעים לשכבה הזאת, ה־command כבר אינו "קיצור ל־prompt" בלבד, אלא workflow קטן הניתן לשימוש חוזר.

---

הפניית @file: הזרקה סטטית מתאימה יותר מ־!cat

!cat file.md אמנם יכול לדחוף את תוכן הקובץ להקשר, אבל הוא עובר דרך ה־shell ויש לו כמה חסרונות: כל הפעלה דורשת הרצת תת־תהליך; אם נתיב הקובץ מכיל רווחים או תווים מיוחדים צריך escape נוסף; ו־Claude Code לא יזהה אותו כ"קובץ" אלא רק כקטע טקסט.

הפניית @ היא native:

---
description: סקירת שינויים לפי תקני הפרויקט
---

עיין בתקנים הבאים:

@.claude/context/coding-standards.md
@.claude/context/security-checklist.md

עכשיו סקור את השינויים ב־git diff וציין כל מקום שבו מופרים התקנים.

!`git diff HEAD`

@path אומר ל־Claude Code "צרף את הקובץ הזה לשיחה כאילו היה קובץ מצורף". ההבדלים:

תרחיש	!cat	@
הנתיב מגיע מארגומנט ($ARGUMENTS)	✅ רק !cat אפשרי	❌ @ לא תומך בהרחבת משתנים
תקני פרויקט ותבניות קבועים	⚠️ אפשרי אבל כבד	✅ native, חוסך קריאת shell
תוכן דינמי (diff, log, תוצאות test)	✅ חובה !	❌ לא אפשרי

כלל: קבצים סטטיים עם @, פלט דינמי עם !, נתיבים פרמטריים עם !cat $ARGUMENTS.

---

allowed-tools: הגבלת הרשאות לפקודה

כברירת מחדל, כשפקודה רצה, המודל יכול להשתמש בכל הכלים שבסשן. לפעמים זה לא מה שרצית — למשל /review היא משימת סקירה בקריאה בלבד, ואתה לא רוצה שהיא "בדרך אגב" תשנה אפילו שורת קוד אחת.

הוסף allowed-tools ב־frontmatter, וכל עוד הפקודה פעילה יורשו רק הכלים המפורטים:

---
description: סקירת קוד לקריאה בלבד
allowed-tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)
---

סקור את ההבדל בין הענף הנוכחי ל־master, קריאה בלבד ללא שינויים.

!`git diff master...HEAD`

כמה נקודות חשובות:

• Bash(git diff:*) הוא אישור מפורט — מרשה רק קריאות bash שמתחילות ב־git diff, ו־git push ייחסם
• Read / Grep / Glob נותן במפורש רק כלים לקריאה בלבד
• Edit / Write לא מופיעים, כך שגם אם המודל ירצה לתקן קוד הוא פשוט לא יוכל

באופן דומה, לפקודה עם הרשאות גבוהות כמו /deploy אפשר לתת הרשאה בכיוון הפוך:

---
description: פריסת הענף הנוכחי
allowed-tools: Bash(kamal deploy:*), Bash(git push:*), Read
---

לקבע מראש "מה הפקודה הזאת יכולה לעשות" אמין הרבה יותר מלהסתמך על אישור ידני של כל בקשת bash בכל הרצה.

---

הפעלת סוכני משנה: לבודד עבודות שטורפות הקשר

יש משימות שמפוצצות את ההקשר של השיחה הראשית — לעבור על עשרות קבצים כדי למצוא את כל מקומות הקריאה לפונקציה, להריץ סטטיסטיקות על ה־codebase, למשוך פיסת log גדולה לניתוח. אם עושים זאת ישירות בשיחה הראשית, אלפי שורות פלט נשארות בהקשר, ושיחות ההמשך הופכות איטיות וטיפשות יותר.

הדרך הנכונה היא להעביר משימות כאלה ל־subagent: הסוכן המשני רץ בהקשר עצמאי, וכשהוא מסיים הוא מחזיר לשיחה הראשית רק את המסקנות. ב־command מספיק להנחות במפורש:

---
description: חקירה מעמיקה של כל השימושים בסמל
allowed-tools: Task
---

השתמש ב־subagent מסוג Explore לחקור לעומק את כל השימושים בסמל הבא: $ARGUMENTS

דרוש מה־subagent לכסות:
- את כל מקומות הקריאה (כולל קבצי test)
- את תרחישי המשתמש המוגעים
- האם יש מימוש חלופי שווה ערך

לאחר חזרת ה־subagent, תן לי רק סיכום של עד 300 מילים, אל תדביק קטעי קוד גולמיים.

הפעלה של /trace SomeClass#some_method תגרום ל־Claude Code להרים subagent מסוג Explore שיסרוק את ה־codebase במקביל, בעוד השיחה הראשית מקבלת רק את המסקנה המזוקקת. אין פלט grep, אין קטעי קבצים, ההקשר נשאר נקי.

צעד נוסף:

---
description: חקירה מקבילה של שלוש חלופות
allowed-tools: Task
---

הרם במקביל 3 subagents, כל אחד יחקור אחת משלוש דרכי המימוש הבאות:

1. שימוש ב־ActiveJob + Sidekiq הקיימים
2. שימוש ב־Solid Queue
3. בניית queue קל משלנו

כל סוכן יענה על: היקף העבודה, הסיכונים, ומידת החדירה לקוד הקיים. כששלוש המסקנות יגיעו חזרה, אני אערוך את ההשוואה בעצמי.

שלושה subagents רצים במקביל, השיחה הראשית ממתינה לסבב תוצאות אחד. זהו אחד המנופים הגדולים ביותר שה־command מעניק — הפיכת משימות מחקר ש"דורשות הרבה טוקנים כדי להגיע למסקנה" ל־workflow של לחיצה אחת.

---

קריאה לכלי MCP: לאפשר לפקודה להגיע למערכות חיצוניות

אם לסשן מחוברים שרתי MCP (Linear, GitHub, Sentry, database proxy שבנית וכו'), הפקודה יכולה להנחות את המודל ישירות להפעיל כלים אלה:

---
description: יצירת todo מימוש מ־Linear issue
allowed-tools: mcp__linear__*, Read, Grep
---

קרא את התיאור המלא והתגובות של Linear issue $ARGUMENTS.

בשילוב עם מצב ה־codebase הנוכחי (חפש בעצמך קבצים רלוונטיים עם Grep/Read), ערוך רשימת todo למימוש:
- אילו קבצים צריך לשנות
- האם כל שלב מוגש כ־commit נפרד או יחד
- האם יש עמימויות שצריך לחדד מול ה־PM קודם

אל תתחיל לכתוב קוד, הצג רק את התוכנית.

mcp__linear__* נותן הרשאה לכל כלי Linear MCP, והמודל יכול למשוך את פרטי ה־issue, התגובות והסטטוס. כל ה־command הופך לנקודת ההתחלה של workflow "מטיקט לתוכנית מימוש".

נקודה מרכזית: כשכותבים שם של כלי MCP ב־allowed-tools חובה להשתמש בקידומת המלאה שלו (mcp__<server>__<tool>), אחרת ההרשאה לא תיכנס לתוקף.

---

המלכודת בהרכבת פקודות: slash אינו מתרחב רקורסיבית

טעות נפוצה מאוד: לכתוב /test בתוך הקובץ של /review בהנחה שזה יפעיל את פקודת ה־test. זה לא יקרה. slash command מתרחב רק פעם אחת ברמת הקלט העליונה של המשתמש; /xxx בתוך command הוא טקסט רגיל בלבד — המודל קורא אותו, אבל Claude Code לא ילך להריץ אותו.

כדי להרכיב מספר פקודות, יש כמה דרכים נכונות:

דרך א: לחלץ את הלוגיקה המשותפת לקובץ context, וכל פקודה תפנה אליו עם @ או !cat

@.claude/context/review-checklist.md
@.claude/context/security-checklist.md

דרך ב: לכתוב בפקודה במפורש "פעל כמו /review" + לחזור על ההוראות הקריטיות

לא אלגנטי אבל עובד. כל עוד ה־prompt ברור מספיק, המודל ילך באותו המסלול.

דרך ג: פקודה אחת משתמשת בכלי Task כדי להרים subagent, וה־prompt של ה־subagent ממחזר את אותם קבצי context

כל תזמור אמיתי של workflow עובר בדרך הזו. פקודת האב אחראית על תזמון וסיכום, וה־subagent אחראי על ביצוע הצעדים הקונקרטיים.

אנטי־pattern שכדאי להימנע ממנו: לכתוב פקודה של מאות שורות שמנסה לעשות הכול בהוראה אחת. ברגע שהגרנולריות מתפוצצת, עלות התחזוקה מזנקת, ותקציב ה־token של ריצה בודדת יאכל לבדו את הפקודה הזאת.

---

מתי להשתמש בשלישייה

עד כאן, הפדיון הבסיסי של המנגנונים להזריק "יכולות חיצוניות" ל־command ב־Claude Code הושלם. איך לבחור:

הצורך	המנגנון המועדף
תקנים, תבניות ומסמכי context קבועים	הפניית @file
מצב בזמן אמת (diff, log, תוצאות test, שאילתת DB)	הזרקת !shell
תוכן קבצים פרמטרי	!cat $ARGUMENTS
מחקר שטורף context, חיפוש חוצה־קבצים	subagent דרך Task
מערכות חיצוניות (issue tracker, ניטור, נתוני production)	כלי MCP + allowed-tools
workflow רב־שלבי סדרתי/מקבילי	פקודת אב שמתזמנת subagents

גבולות ההרשאה מוצהרים במפורש דרך allowed-tools, במיוחד בפקודות המשותפות לצוות — לקבע מה היא יכולה לעשות אמין יותר מלהסתמך על אישור ידני בכל פעם.

---

דוגמה קרובה ל־production

ניקח הכול ונחבר לפקודת "חקר מסלול מימוש על סמך Linear ticket":

---
description: הפקת תוכנית מימוש על סמך Linear ticket
allowed-tools: mcp__linear__*, Task, Read, Grep, Glob, Bash(git log:*)
---

## הקשר

@.claude/context/architecture.md
@.claude/context/coding-standards.md

## מצב ה־codebase הנוכחי

!`git log --oneline -10`

## המשימה

משוך את התיאור, התגובות והטיקטים המקושרים של Linear ticket $ARGUMENTS.

אחר כך הרם שני subagents במקביל:
1. הראשון: למצוא ב־codebase את כל המימושים הקיימים הרלוונטיים ואת המודולים הניתנים לשימוש חוזר
2. השני: להעריך סיכונים — באילו נתיבי קוד בעלי תעבורה גבוהה השינוי ייגע, האם יש פערי כיסוי בבדיקות

אחרי ששני הסוכנים חוזרים, הוצא:
- שלבי מימוש (מסודרים לפי סדר התלויות)
- רשימת סיכונים
- גרנולריות commit מומלצת

אל תתחיל לכתוב קוד.

הפעלה של /plan ENG-4213 — הוראה אחת שרצה עד הסוף: משיכת הטיקט ← מחקר מקבילי ב־codebase ← הערכת סיכונים ← סיכום התוכנית. כל מה שנשאר למשתמש הוא לקרוא את המסקנות ולהחליט אם לצאת לדרך.

---

זהו הקשת המלאה של שלושת המאמרים הראשונים בסדרת slash command: הגדרת prompts לשימוש חוזר (intro) ← הזרקת context דינמית (context) ← תזמור כלים וסוכני משנה (המאמר הזה). בשכבה הזאת, .claude/commands/ כבר איננו אוסף קיצורים, אלא ספריית workflow קטנה של הצוות.