מ־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        # checklist ארוך לסקירת קוד
├── examples/
│   └── good-diff.md    # דוגמה טובה
└── scripts/
    └── lint.sh         # script ש־SKILL.md יכול להריץ

בתוך SKILL.md מפנים בעזרת path יחסי:

סקור את ה־diff הנוכחי לפי הסטנדרטים ב־[checklist.md](checklist.md).
ראה [examples/good-diff.md](examples/good-diff.md) להבנת פורמט הפלט המצופה.

הקבצים התומכים האלה אינם נטענים אוטומטית ל־context—Claude קורא אותם לפי הצורך. ההמלצה הרשמית היא לשמור על SKILL.md מתחת ל־500 שורות, ואת השאר להעביר לקבצי הנלווים.

2. `disable-model-invocation`: אילו skills רק אתה יכול להפעיל ידנית

ברירת המחדל היא ש־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—אבל היית צריך לתאר בעצמך ב־prompt "פתח subagent מסוג Explore שיעשה...".

ב־SKILL מספיקה שורה אחת ב־frontmatter:

---
name: deep-research
description: מחקר מעמיק על סמל מסוים
context: fork
agent: Explore
---

חקור את כל השימושים של $ARGUMENTS:
- כל נקודות הקריאה
- ההקשרים העסקיים
- מימושים חלופיים

החזר תקציר של עד 300 מילים.

כשמפעילים /deep-research SomeClass: כל SKILL.md הופך ל־prompt של subagent עצמאי, רץ עם agent type בשם 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 1
└── risk-prompt.md         # הוראות ל־subagent 2

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 כדי להריץ שני subagents במקביל:
1. מחקר קוד: prompt נמצא ב־[research-prompt.md](research-prompt.md)
2. הערכת סיכונים: prompt נמצא ב־[risk-prompt.md](risk-prompt.md)

אחד את שתי התוצאות ופלט צעדי מימוש + רשימת סיכונים + המלצה על granularity של commit.

ה־prompts של שני ה־subagents יושבים בקבצים נפרדים; בעת תחזוקה משנים מקום אחד בלי לגעת ב־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 כמשימה ← מחזיר רק את התוכנית הסופית. השיחה הראשית לא מתלכלכת כלל.

מתי לא כדאי להעביר

לא כל command שווה שדרוג. מקרים שבהם עדיף להישאר ב־.claude/commands/:

מספיק Markdown יחיד: אין checklist, examples או scripts שצריך להוציא
אין צורך ב־fork: המשימה כרוכה עמוקות בשיחה הראשית ודורשת לראות את כל ההיסטוריה
אין צורך בהפעלה אוטומטית לפי path: המשתמש מפעיל ידנית בכל מקרה
אין צורך בבקרת גישה: אפשר בלב שקט לתת ל־Claude לקרוא לבד

/commit, /pr-desc וכאלה הם רק frontmatter עם כמה שורות של prompt—לשים אותם ב־.claude/commands/ הרבה יותר ישיר. הצוות הרשמי אמר במפורש ששתי הצורות יתקיימו במקביל, ואף אחת מהן לא תהיה deprecated.

המצב הנוכחי של דו־קיום

הארגון הכי נקי של .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/ חדה מאוד—זה לא שינוי מסוג "עבור עכשיו או תיעלם", אלא הרחבה מסוג "ניתנות לך יכולות חדשות בלי לכפות". תבין את ההבדלים, עבור לפי הצורך, ואל תרדוף אחרי סדר פורמלי בלבד.