4 שלב 2 — הרחבת יכולות

Skills and Custom Commands — פקודות מותאמות אישית

איך להפוך תהליכים מורכבים לפקודת /slash אחת: כתיבת Skills מאפס, YAML Frontmatter, הפעלה אוטומטית, Forked Context, פקודות מובנות, ובניית ספריית פקודות מותאמות אישית שחוסכת שעות בכל שבוע.

מה יהיה לך בסוף הפרק הזה
יעדי למידה — מה תדע לעשות אחרי הפרק הזה
דרישות קדם
הפרויקט שלך

בפרק הקודם (פרק 3: MCP) למדת לחבר את Claude Code לשירותים חיצוניים — דפדפנים, מסדי נתונים, GitHub ועוד. עכשיו יש ל-Claude כלים חזקים אבל אתה עדיין צריך לכתוב הוראות מחדש בכל פעם. בפרק הזה תלמד לארוז תהליכים שלמים לתוך פקודה אחת — Skill שמפעילים עם /slash ומקבלים תוצאה עקבית בכל פעם. בפרק הבא (פרק 5: Plugins) תלמד לארוז Skills, Agents, Hooks ושרתי MCP ביחד כ-Plugin שאפשר לשתף עם אחרים או להתקין ממארקטפלייס.

מילון מונחים — פרק 4
מונח באנגלית הסבר בעברית
Skill קובץ Markdown עם הוראות שהופך לפקודת /slash — מתכון שאפשר להפעיל שוב ושוב
YAML Frontmatter בלוק מטא-דאטה בראש קובץ Markdown (בין שני ---) שמגדיר שם, תיאור, מודל ועוד
Slash Command פקודה שמתחילה ב-/ ומפעילה Skill — למשל /deploy או /write-blog
User-Invoked Skill שרץ רק כשאתה מקליד את הפקודה ידנית
Auto-Invoked Skill ש-Claude מפעיל אוטומטית כשהוא מזהה שזה רלוונטי למשימה
Forked Context הרצת Skill בהקשר מבודד (כמו Sub-Agent) — לא צורך מחלון השיחה הראשי
Hot Reload עדכון Skill "בלייב" — עורכים את הקובץ, מפעילים שוב, רואים את השינוי מיד
Bundled Skill Skill שמגיע מובנה עם Claude Code — כמו /simplify, /batch, /debug
Dynamic Data Injection הזרקת נתונים חיים לתוך ה-Skill באמצעות פקודות Shell שרצות לפני ש-Claude מעבד את ההוראות
מתחיל 10 דקות חינם מושג

מה זה Skills — אבן הבניין לזרימת עבודה חוזרת

חשוב על המשימות שאתה מבצע שוב ושוב ב-Claude Code. אולי אתה תמיד מבקש "בדוק את הקוד שלי, מצא בעיות אבטחה, ותן דוח מסודר." או "קח את השינויים האחרונים, כתוב Release Notes, ושלח Pull Request." בכל פעם אתה מקליד את אותה בקשה ארוכה, עם אותם פרטים, ומקווה שהפלט יהיה עקבי.

Skill (מיומנות/פקודה) פותר את הבעיה הזו. זהו קובץ Markdown — עם כותרת YAML שמגדירה מטא-דאטה וגוף טקסט שמכיל הוראות — שהופך לפקודת /slash שאפשר להפעיל בלחיצה אחת. במקום להסביר תהליך של 10 שלבים כל פעם מחדש, אתה כותב את ההוראות פעם אחת כ-Skill ומפעיל עם פקודה קצרה.

1 → 10

פקודת /slash אחת מחליפה 10 שלבים ידניים. Skill ממוצע חוסך 3-5 דקות בכל הפעלה — ואם אתה מפעיל אותו 5 פעמים ביום, זה 15-25 דקות חסכון יומי על משימה אחת בלבד.

מערכת ה-Skills הושקה בסוף 2025, וקיבלה שדרוג משמעותי בגרסה 2.1.0 (ינואר 2026) שהוסיף Forked Context (הקשר מבודד), Hot Reload (טעינה מחדש מיידית), ותמיכה ב-Custom Agents (סוכנים מותאמים). מאז, Skills הם אחד הכלים הכי חזקים ב-Claude Code — ומי שמשתמש בהם נכון חוסך שעות של עבודה חוזרת כל שבוע.

9,000+

Plugins (שמבוססים על Skills כאבן בניין בסיסית) זמינים במארקטפלייס של Claude Code נכון למרץ 2026. מערכת ה-Skills שתלמד בפרק הזה היא הבסיס לכל Plugin — בלי Skill טוב, אין Plugin טוב. ה-Skills המובנים (/simplify, /batch, /review) מושכים מיליוני הפעלות חודשיות.

חשוב להבחין: Skill הוא לא CLAUDE.md ולא Hook. CLAUDE.md מגדיר כללים קבועים שתמיד פעילים ("תמיד כתוב ב-TypeScript, לא JavaScript"). Hook רץ אוטומטית על אירוע ספציפי ("אחרי כל שמירת קובץ, הרץ Formatter"). Skill הוא תהליך שלם שמופעל לפי בקשה (או אוטומטית) — "בצע Code Review מקיף על הקבצים שהשתנו, תן דוח, ותקן מה שאפשר." שלושת הכלים משלימים אחד את השני, וביחד הם יוצרים מערכת אוטומציה מלאה.

הרעיון המרכזי פשוט:

Skill = Reusable Prompt + Context — Skill הוא פרומפט מוכן שחידדת לאורך זמן, ארוז בפורמט שמאפשר הפעלה מיידית ועקבית בכל פעם.

השדה name ב-YAML Frontmatter הופך לפקודת ה-/slash. אם name: deploy-staging, אז הפקודה /deploy-staging מפעילה את ה-Skill. פשוט ככה.

חשוב להבין: Skill הוא לא קוד. הוא לא סקריפט Python או Shell. הוא קובץ Markdown רגיל — טקסט — שמכיל הוראות שClaude עוקב אחריהן. אם אתה יודע לכתוב הוראות ברורות בשפה טבעית, אתה יודע לכתוב Skill. לא צריך ידע בתכנות, לא צריך ללמוד שפה חדשה. מספיק לדעת מה אתה רוצה ולכתוב את זה בצורה מדויקת ומסודרת.

דוגמה מהחיים: נגיד שאתה Lead Developer בסטארטאפ ישראלי שמשתמש ב-Claude Code. כל פעם שמישהו בצוות פותח PR, אתה רוצה שClaude יבצע Code Review לפי הסטנדרטים של החברה. בלי Skill, צריך להסביר כל פעם מחדש: "בדוק את הקוד לפי הכללים שלנו — כל פונקציה צריכה JSDoc, אסור Hardcoded Secrets, Imports ממוינים אלפביתית..." עם Skill, כותבים את הכללים פעם אחת ומפעילים עם /our-review בכל PR.

Skill לעומת Prompt רגיל — מה ההבדל?

מאפיין Prompt רגיל Skill
שימוש חוזר מקלידים כל פעם מחדש כותבים פעם אחת, מפעילים תמיד
עקביות כל פעם ניסוח קצת שונה = תוצאה שונה הוראות זהות = תוצאה עקבית
שיתוף עם צוות צריך לשלוח ב-Slack "הנה הפרומפט שלי" קובץ ב-Git — כל הצוות משתמש באותו Skill
בקרת עלויות אין שליטה על מודל או Effort מגדירים מודל ו-Effort Level לכל Skill
הקשר מבודד צורך מחלון השיחה הראשי אפשר להריץ ב-Fork — לא פוגע בהקשר
נתונים דינמיים צריך להדביק ידנית Shell Commands מזריקים נתונים אוטומטית

דוגמאות מייצגות — Skills בפעולה

כדי להבין את העוצמה של Skills, הנה כמה תרחישים מהחיים:

תרחיש 1: צוות פיתוח בתל אביב

צוות של 4 מפתחים בסטארטאפ SaaS. כל אחד מהם פותח 2-3 Pull Requests ביום. לפני כל PR, צריך: לבדוק שאין Secrets בקוד, לוודא שיש Tests, לכתוב תיאור PR מפורט, ולבדוק שה-Types תקינים. בלי Skills — כל מפתח מבזבז 15 דקות על הבדיקות האלה לפני כל PR. עם Skill בשם /pre-pr שעושה את כל הבדיקות — זה יורד ל-2 דקות (הפעלת הפקודה + קריאת הפלט). עם 4 מפתחים ו-10 PRs ביום: חיסכון של 130 דקות ביום — יותר משעתיים של עבודת מפתחים.

תרחיש 2: משווקת דיגיטלית פרילנסרית

מנהלת 5 לקוחות. כל שבוע צריכה לכתוב 5 פוסטים לבלוגים (אחד לכל לקוח). עם Skill בשם /write-blog-he — מספקת נושא, מקבלת טיוטה ראשונה איכותית בעברית, עורכת ומפרסמת. במקום 3 שעות לפוסט — שעה אחת. חיסכון של 10 שעות שבועיות על כתיבה בלבד.

תרחיש 3: DevOps Engineer

אחראי על Deploy לסביבות שונות. Skill בשם /deploy-staging שמריץ בדיקות, בונה Docker Image, דוחף ל-Registry, ומעדכן את ה-Kubernetes Deployment. במקום 10 פקודות ידניות שקל לטעות בהן — פקודה אחת שעושה הכל נכון בכל פעם.

⚡ עשה עכשיו 2 דקות

חשוב על 3 משימות שאתה מבצע שוב ושוב ב-Claude Code. רשום אותן על דף או בקובץ. למשל: "ביקורת קוד לפני PR", "כתיבת תיעוד לפונקציה חדשה", "ניתוח לוגים מהיום". אלה המועמדים הראשונים שלך להפיכה ל-Skills. שמור את הרשימה — נשתמש בה בהמשך הפרק.

מתחיל 15 דקות חינם הקמה

אנטומיית Skill — YAML Frontmatter לעומק

בינוני 15 דקות חינם מעשי

כל קובץ Skill מורכב משני חלקים: YAML Frontmatter (מטא-דאטה) ו-Markdown Body (הוראות). ה-Frontmatter מוגדר בין שני סימני --- בראש הקובץ, וכל מה שמתחתיו הוא גוף ההוראות.

הנה המבנה הבסיסי:

📚 מבנה קובץ Skill

---
name: my-skill
description: What this skill does
model: sonnet
effort: medium
fork: true
invoke: user
---

# Instructions for Claude

1. First, do this...
2. Then, check that...
3. Finally, report...

בוא נעבור על כל שדה:

בוא נעבור על כל שדה לעומק, עם דוגמאות ומקרי שימוש:

name (חובה) — שם הפקודה

השדה name קובע את שם פקודת ה-/slash. הכלל: קצר, תיאורי, באנגלית, עם מקפים (lowercase with hyphens). השם צריך לספר מה ה-Skill עושה בלי שיצטרכו לקרוא את התיאור.

שם טוב שם רע למה
deploy-staging d ברור מה עושה לעומת ראשי תיבות
write-blog wb קריא ומובן לכל חבר צוות
security-check do-everything ממוקד במשימה אחת ברורה
audit-imports myTool_v2 lowercase-with-hyphens הוא הסטנדרט

description (חובה) — תיאור

השדה description מסביר מה ה-Skill עושה. זה לא רק תיעוד — Claude משתמש בתיאור כדי להחליט אם להפעיל את ה-Skill אוטומטית (במצב Auto-Invoke). התיאור גם מופיע בפלט של /help, כך שחשוב שיהיה ברור ותמציתי.

דוגמאות לתיאורים טובים:

תיאור גרוע: "Does stuff" או "My tool" — Claude לא יבין מתי להפעיל אוטומטית, והצוות לא יבין למה הפקודה קיימת.

agent (אופציונלי) — סוכן מותאם

השדה agent מפנה לקובץ הגדרות סוכן בתיקיית .claude/agents/. כשה-Skill רץ, הוא משתמש בסוכן הספציפי הזה במקום בסוכן הרגיל. זה שימושי כשאתה רוצה ש-Skill מסוים יפעל עם מגבלות כלים ספציפיות, רמת Effort מסוימת, או maxTurns מוגבל.

למשל, יש לך סוכן בשם security-auditor ב-.claude/agents/security-auditor.md שמוגדר עם disallowedTools: ["Write", "Edit"] (לא יכול לשנות קבצים — רק לקרוא ולדווח). Skill שמשתמש בסוכן הזה יכול לבצע ביקורת אבטחה בלי סיכון שישנה קבצים בטעות:

📚 Skill עם Custom Agent

---
name: security-audit
description: Read-only security review of recent changes
agent: security-auditor
fork: true
---

מה אפשר להגדיר בקובץ Agent? שלושה שדות קריטיים שמופיעים ב-YAML של קובץ ה-Agent עצמו (לא ב-Skill, אלא בקובץ .claude/agents/security-auditor.md):

שדה ב-Agent מה עושה דוגמה
maxTurns מגביל כמה צעדים הסוכן יכול לבצע. מונע "ריצה אינסופית" של סוכנים שנתקעים בלולאה maxTurns: 20 — מספיק לרוב המשימות, לא יבזבז תקציב
disallowedTools רשימת כלים שהסוכן לא יכול להשתמש בהם. מייצר "סוכן Read-Only" או "סוכן בלי Shell" disallowedTools: ["Write", "Edit", "Bash"] — קורא בלבד, לא יכול לשנות שום דבר
effort רמת חשיבה ברירת מחדל לסוכן הזה (עוקפת את ההגדרה בסשן) effort: high — לניתוח אבטחה מעמיק, למשל
📚 דוגמה — קובץ Agent מלא (.claude/agents/security-auditor.md)

---
name: security-auditor
description: Read-only agent for security analysis
model: opus
effort: high
maxTurns: 25
disallowedTools:
  - Write
  - Edit
  - Bash
---

You are a security auditor. Analyze code for vulnerabilities.
NEVER attempt to modify files. Report findings only.

maxTurns: 20

הערך המומלץ ל-maxTurns ברוב ה-Skills. מספיק לסוכן לקרוא 10-15 קבצים, להריץ 3-5 פקודות, ולייצר דוח. ערך גבוה מדי (100+) מסכן בזבוז תקציב; ערך נמוך מדי (5) עלול לחתוך את הסוכן באמצע העבודה.

model (אופציונלי) — בחירת מודל

כאן אתה שולט בעלויות — וזה קריטי. Skill פשוט שבודק פורמט קוד? השתמש ב-model: haiku — מהיר וזול. Skill מורכב שמנתח ארכיטקטורה? השתמש ב-model: opus — איטי יותר אבל חכם יותר. ברירת המחדל היא המודל הפעיל של הסשן הנוכחי.

הנה מדריך מהיר לבחירת מודל:

סוג משימה מודל מומלץ עלות יחסית
פורמט קוד, Lint Fix, סיכום קצר haiku הכי זולה
כתיבת בלוג, Code Review, תיעוד sonnet מאוזנת
ניתוח ארכיטקטורה, אבטחה, רפקטורינג מורכב opus הכי יקרה
💡 חסכון חכם עם Model Override

Skill ש-80% מהזמן עושה משימה פשוטה (פורמט, בדיקת Lint, סיכום קצר) — הגדר אותו עם model: sonnet או model: haiku. תחסוך 60-90% מעלות הפעלה לעומת Opus, בלי הבדל משמעותי בתוצאה למשימות פשוטות.

effort (אופציונלי) — רמת חשיבה

השדה effort שולט בעומק החשיבה של Claude. שלוש רמות: "low" (מהיר, שטחי), "medium" (ברירת מחדל, מאוזן), "high" (מעמיק, יסודי). משימות מהירות כמו פורמט קוד — low. ניתוח אבטחה מעמיק — high.

invoke (אופציונלי) — מי מפעיל

השדה invoke קובע מי שולט על ההפעלה. ברירת המחדל היא "user" — ה-Skill רץ רק כשאתה מקליד את פקודת ה-/. האפשרות השנייה היא "auto" — Claude יכול להפעיל את ה-Skill מעצמו כשהוא שופט שזה רלוונטי. נרחיב על זה בסעיף 4.4.

fork (אופציונלי) — הקשר מבודד

השדה fork קובע אם ה-Skill רץ בהקשר מבודד (true) או בתוך השיחה הנוכחית (false). ברירת המחדל: false ל-User-Invoked, true ל-Auto-Invoked. נרחיב בסעיף 4.5.

hooks (אופציונלי) — Hooks ספציפיים ל-Skill

אפשר להגדיר Hooks (כמו אלה שלמדת בפרק 1) שמופעלים רק כשה-Skill הספציפי הזה רץ. למשל, Hook שרץ אחרי ש-Skill של Deploy מסיים — שולח התראה ל-Slack. או Hook שלפני הפעלת /deploy-production מוודא שאתה ב-Branch הנכון. זה מאפשר "שכבות הגנה" ספציפיות לכל Skill.

📚 Skill עם Hook מובנה

---
name: deploy-production
description: Deploy current branch to production after safety checks
hooks:
  PreToolUse:
    - command: "bash -c 'branch=$(git branch --show-current); if [ \"$branch\" != \"main\" ]; then echo \"ERROR: Must be on main branch\"; exit 1; fi'"
---

ה-Hook הזה בודק שאתה ב-Branch main לפני שמתחיל. אם לא — ה-Skill לא ירוץ.

סיכום: Reference Card של כל שדות ה-YAML

שדה חובה? ברירת מחדל ערכים אפשריים
name כן — lowercase-with-hyphens
description כן — טקסט חופשי
model לא מודל הסשן haiku, sonnet, opus
effort לא medium low, medium, high
invoke לא user user, auto
fork לא false (user) / true (auto) true, false
agent לא — שם קובץ ב-.claude/agents/
hooks לא — מבנה hooks כמו ב-settings.json
tools לא כל הכלים רשימת כלים שה-Skill יכול להשתמש בהם (Read, Write, Bash, וכו')

שדה tools חשוב במיוחד כשאתה רוצה להגביל Skill ספציפי — למשל, Skill שרק קורא קבצים ולא משנה אותם. במקום ליצור Agent נפרד, אפשר פשוט לרשום בשדה tools רק את הכלים המותרים:

📚 Skill מוגבל עם tools

---
name: analyze-deps
description: Analyze project dependencies (read-only)
tools:
  - Read
  - Glob
  - Grep
---

ה-Skill הזה יכול רק לקרוא קבצים ולחפש — לא לערוך, לא להריץ פקודות Shell. מושלם לסריקות אנליטיות שלא צריכות לשנות שום דבר.

⚡ עשה עכשיו 3 דקות

צור קובץ חדש: .claude/commands/hello.md. הכנס בו:

---
name: hello
description: Greet the user with a fun fact about their project
---

Analyze the current project directory. Find one interesting or surprising fact about the codebase (e.g., total lines of code, most edited file, oldest file, unusual dependency). Greet the user in a friendly way and share this fun fact.

שמור, חזור ל-Claude Code, והקלד /hello. זהו ה-Skill הראשון שלך.

בינוני 12 דקות חינם תרגול

כתיבת הוראות — גוף ה-Markdown

בינוני 12 דקות חינם מעשי

אחרי ה-YAML Frontmatter (בין שני ---), מגיע גוף ההוראות — Markdown רגיל שאומר ל-Claude בדיוק מה לעשות. זהו הלב של ה-Skill. הוראות טובות = תוצאות עקביות. הוראות מעורפלות = תוצאות שמשתנות בכל הפעלה.

הכלל הזהב: Claude עוקב אחרי ההוראות כמו שהן כתובות. אם דילגת על שלב — גם הוא ידלג.

ההוראות מתחילות מיד אחרי ה---- השני. אתה יכול להשתמש בכל פורמט Markdown: כותרות (#, ##, ###), רשימות ממוספרות ולא ממוספרות, טקסט מודגש, בלוקי קוד, ואפילו טבלאות. Claude מבין Markdown במלואו ומשתמש בפורמט כדי להבין את המבנה והעדיפויות של ההוראות.

הנקודה החשובה: הוראות Skill שונות מפרומפט רגיל. בפרומפט רגיל, אתה מתכתב עם Claude ויכול לתקן תוך כדי. ב-Skill, אתה כותב "מתכון" שClaude עוקב אחריו בלי שתוכל להתערב באמצע (במיוחד ב-Fork). לכן, ההוראות צריכות להיות מושלמות — ברורות, מפורטות, ובלי הנחות.

עקרונות לכתיבת הוראות אפקטיביות

1. שלבים ממוספרים לתהליכים סדרתיים

כשה-Skill מבצע פעולות בסדר מסוים, השתמש ברשימה ממוספרת:

📚 דוגמה — שלבים סדרתיים

1. Read the config file at `.env.example`
2. Compare with `.env` to find missing variables
3. For each missing variable, suggest a default value
4. Report findings as a table: Variable | Status | Suggested Default

2. Bullet Points לבדיקות וקריטריונים

כשה-Skill צריך לבדוק מספר דברים (לא בהכרח בסדר), השתמש ב-Bullets:

📚 דוגמה — רשימת בדיקות

Verify the following for every file changed in the last commit:
- No hardcoded secrets or API keys
- All API calls have proper error handling
- Tests exist for all public functions
- No TODO comments without associated issue numbers

3. לוגיקה מותנית

Skill חכם מתאים את עצמו לסיטואציה:

📚 דוגמה — לוגיקה מותנית

If the project uses TypeScript, run `tsc --noEmit` to check types.
If the project uses JavaScript, run `eslint .` to check style.
If neither is found, report "No JS/TS project detected" and stop.

4. הגדרת פורמט פלט

ציין בדיוק איך אתה רוצה את התוצאה. בלי הגדרה ברורה, Claude יחליט בעצמו — ותקבל פורמט שונה בכל הפעלה:

📚 דוגמה — הגדרת פורמט

Report findings as a markdown table with these columns:
| File | Issue | Severity (high/medium/low) | Recommendation |

End with a summary: total issues found, breakdown by severity,
and estimated time to fix all issues.

5. טיפול בשגיאות

אמור ל-Claude מה לעשות כשמשהו נכשל. בלי זה, הוא עלול להמשיך הלאה ולגרום נזק:

📚 דוגמה — טיפול בשגיאות

If tests fail, STOP immediately and report the failures.
Do NOT proceed to deployment.
List each failing test with its error message.

6. הפניות לקבצים ונתיבים

הפנה ל-Claude לקבצים ספציפיים כשצריך:

📚 דוגמה — הפניה לקבצים

Read the project's CLAUDE.md for coding standards.
Read `.github/PULL_REQUEST_TEMPLATE.md` for PR format.
Apply both when generating the pull request description.

7. קבלת קלט מהמשתמש

כש-Skill צריך מידע מהמשתמש (נושא לבלוג, שם Branch, קובץ לבדיקה), אפשר לכתוב את ההוראות כך שClaude ישאל. אבל יותר יעיל: להניח שהמשתמש כותב את הקלט מיד אחרי פקודת ה-/slash:

📚 דוגמה — קלט מהמשתמש

The user will provide a topic after the /command. Example usage:
`/write-blog-he artificial intelligence for small businesses`

If no topic is provided, ask the user to specify one before proceeding.

כך המשתמש יכול להקליד /write-blog-he שיווק דיגיטלי לעסקים קטנים ו-Claude יתחיל לעבוד מיד עם הנושא הזה — בלי שאלות מיותרות.

טעות נפוצה: Skill שמשנה קבצים בלי שלב אישור

זו הטעות הנפוצה ביותר בכתיבת Skills: לתת ל-Claude לערוך קבצים ישר בלי לבקש אישור קודם. למה זה מפתה? כי "סומכים על Claude." למה זה מסוכן? כי Skill שעובד 95% מהזמן עדיין יכול למחוק קוד חשוב ב-5% הנותרים. מה לעשות במקום: תמיד הוסיף שלב אישור בין ניתוח לפעולה: "Step 1: Analyze. Step 2: Present plan and wait for approval. Step 3: Only after approval, execute changes."

פקודות Shell ב-Skills

אפשר לשלב פקודות Shell ישירות בהוראות. עוטפים אותן ב-Backticks ו-Claude יריץ אותן דרך כלי ה-Bash:

📚 דוגמה — פקודות Shell בהוראות

Run the following command to get the list of changed files:
`git diff --name-only HEAD~1`

Then review each changed file for code quality issues.

⚡ עשה עכשיו 5 דקות

קח את ה-Skill /hello שיצרת קודם ושדרג אותו. הוסף:

שמור ובדוק עם /hello — שים לב להבדל באיכות הפלט לעומת הגרסה הקודמת.

בינוני 10 דקות חינם מושג

User-Invoked vs Auto-Invoked — מי שולט על ההפעלה

בינוני 10 דקות חינם תיאוריה + מעשי

ברגע שיש לך Skills, צריך להחליט: מי מפעיל אותם — אתה או Claude?

User-Invoked (ברירת מחדל) — invoke: user

ה-Skill רץ רק כשאתה מקליד את פקודת ה-/. אתה שולט מתי הוא מופעל. זו ברירת המחדל, וזו הדרך הבטוחה להתחיל.

מתי להשתמש:

Auto-Invoked — invoke: auto

Claude מפעיל את ה-Skill אוטומטית כשהוא מזהה שזה רלוונטי לבקשה הנוכחית. אתה לא צריך לזכור להפעיל — Claude עושה את זה בשבילך.

מתי להשתמש:

📚 דוגמה — Skill עם Auto-Invoke

Skill בשם check-imports עם invoke: auto. בכל פעם ש-Claude עורך קובץ TypeScript, הוא אוטומטית מפעיל את ה-Skill כדי לוודא שכל ה-Import Statements תקינים. אתה אף פעם לא צריך לזכור לבדוק — זה קורה ברקע.

טעות נפוצה: להגדיר יותר מדי Skills כ-Auto-Invoke

זה מפתה — "שClaude יפעיל הכל לבד!" — אבל יותר מדי Skills עם invoke: auto מאטים כל אינטראקציה. Claude צריך להעריך עבור כל בקשה שלך אם כל Skill רלוונטי או לא. מה לעשות במקום: התחל בלי Auto-Invoke. רק אחרי שאתה סומך על Skill והוא הוכיח את עצמו ב-30+ הפעלות ידניות — שדרג אותו ל-invoke: auto. כלל אצבע: לא יותר מ-3-5 Skills עם Auto-Invoke בו-זמנית.

מסגרת החלטה: User-Invoked מול Auto-Invoked
שאלה User-Invoked Auto-Invoked
ה-Skill משנה קבצים? User — תמיד אישור ידני רק אם יש שלב אישור מובנה
ה-Skill הוכח ב-30+ הפעלות? עדיין בבדיקה Auto — מוכן לשדרוג
ה-Skill צורך הרבה tokens? User — הפעלה מודעת לעלות רק עם fork: true
ה-Skill בודק איכות/Standards? בהתחלה Auto — מושלם לבדיקות רקע

כלל אצבע: התחל תמיד כ-User-Invoked. שדרג ל-Auto-Invoked רק כשסומכים על ה-Skill ואחרי שהוכח ב-30+ הפעלות ידניות.

נקודה טכנית חשובה: Skills עם Auto-Invoke תמיד רצים ב-Forked Context (הקשר מבודד). זה מונע זיהום לא צפוי של ההקשר שלך.

דוגמה מעשית: המסע מ-User-Invoked ל-Auto-Invoked

נגיד שיש לך Skill שמוודא שכל קובץ TypeScript שנערך כולל Type Annotations תקינים. ככה נראה המסע:

  1. שבוע 1: יוצר את ה-Skill כ-invoke: user. מפעיל ידנית אחרי כל שינוי ב-TS: /check-types.
  2. שבוע 2: ה-Skill עובד מצוין, בודק כל פעם 5-10 קבצים ומוצא 2-3 בעיות. אתה מרוצה מהתוצאות.
  3. שבוע 3: שוכח להפעיל פעמיים. מגלה בעיות Types רק ב-PR Review. מחליט לשדרג.
  4. שבוע 4: משנה ל-invoke: auto. עכשיו כל פעם שClaude עורך קובץ TS — ה-Skill רץ אוטומטית ברקע. אתה לא צריך לזכור שום דבר.

זהו הדפוס הנכון: תמיד להתחיל כ-User-Invoked, ולשדרג רק אחרי שהוכחת שה-Skill אמין ושימושי.

⚡ עשה עכשיו 5 דקות

צור Skill בשם check-todos.md בתיקיית .claude/commands/:

---
name: check-todos
description: Scans recently changed files for TODO comments without issue numbers
invoke: user
effort: low
model: sonnet
---

1. Run `git diff --name-only HEAD~3` to find recently changed files
2. Scan each file for TODO, FIXME, HACK comments
3. Flag any TODO without an issue number (e.g., TODO(#123) is OK, bare TODO is not)
4. Report as a table: File | Line | Comment | Status (OK/Missing Issue)

הפעל עם /check-todos. אם זה עובד טוב — שקול לשנות ל-invoke: auto בהמשך.

בינוני 10 דקות חינם מושג

Forked Context — הפעלה בהקשר מבודד

בינוני 8 דקות חינם תיאוריה

כשאתה מפעיל Skill עם fork: true, הוא רץ בחלון הקשר נפרד — כמו Sub-Agent שמופעל על ידי מערכת ה-Skills. ה-Fork מתחיל נקי: יש לו את ההוראות של ה-Skill, גישה לקבצים, אבל לא את היסטוריית השיחה שלך.

כשה-Skill מסיים, רק התוצאה הסופית / הסיכום חוזרים לסשן הראשי. כל החקירה והביניים נשארים ב-Fork ולא צורכים מההקשר שלך.

למה זה חשוב?

בלי Forked Context, כל Skill שרץ צורך Tokens מחלון ההקשר הראשי שלך. Skill שקורא 20 קבצים, מריץ 5 פקודות Shell, ומייצר דוח ארוך — יכול לתפוס 30-40% מההקשר שלך. עם Fork, רק הדוח הסופי (אולי 5% מכל העבודה) חוזר אליך.

95%

מהעבודה של Skill ב-Fork נשארת "מאחורי הקלעים". אם Skill קורא 15 קבצים, מריץ 4 פקודות, ומייצר דוח של 500 מילים — כל הקריאות וההרצות צורכות ~19,000 טוקנים ב-Fork, אבל רק ~1,000 טוקנים (הדוח הסופי) חוזרים לשיחה הראשית. ב-Opus 4.6 עם חלון הקשר של 200K טוקנים (או מיליון למנויי Max), זו ההבדל בין לרוקן את ההקשר אחרי 3 Skills לבין להריץ 20+ Skills בסשן אחד.

מצב fork: false (ברירת מחדל) fork: true
צריכת הקשר כל שלב נכנס לשיחה הראשית רק התוצאה הסופית חוזרת
גישה להיסטוריית שיחה מלאה — רואה מה דיברתם אין — מתחיל נקי
השפעת כישלון שגיאות מזהמות את השיחה שגיאות נשארות ב-Fork
מתאים ל- Skills שצריכים הקשר מהשיחה Skills עם חקירה כבדה

מתי להשתמש ב-Fork ומתי לא

כן Fork:

לא Fork:

מסגרת החלטה: Fork או לא Fork?
מאפיין ה-Skill fork: false fork: true
קורא 5+ קבצים או מריץ 3+ פקודות ימלא את ההקשר Fork — רק סיכום חוזר
צריך לדעת מה דיברתם עד עכשיו No Fork — חייב הקשר ה-Fork לא יראה את השיחה
עלול להיכשל (ניסויי/חקירתי) שגיאות יזהמו את השיחה Fork — שגיאות נשארות מבודדות
מחזיר שורה אחת / תוצאה קצרה No Fork — מיותר תקורה מיותרת

כלל אצבע: אם ה-Skill מייצר יותר פלט ממה שאתה רוצה לראות — Fork. אם הוא צריך הקשר מהשיחה — No Fork.

איך Fork עובד מאחורי הקלעים

כשמפעילים Skill עם fork: true, Claude Code יוצר מעין "חלון שיחה וירטואלי" נפרד. ה-Fork מקבל:

מה ה-Fork לא מקבל:

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

💡 פיצול חכם: הקשר + חקירה

אם Skill צריך גם גישה להקשר מהשיחה וגם חקירה כבדה — פצל אותו. צור Skill לא-מפורק שמחלץ את ההקשר הנדרש, ואז מפעיל Forked Agent למשימה הכבדה. כך אתה מקבל את הטוב משני העולמות.

⚡ עשה עכשיו 3 דקות

חזור ל-Skill check-todos שיצרת, והוסף fork: true ל-YAML. הפעל שוב. שים לב להבדל: הפעם תקבל רק את הסיכום הסופי, בלי לראות את כל השלבים הביניים. ההקשר שלך נשאר נקי.

מתחיל 8 דקות חינם הקמה

תיקיית commands/ — פקודות Slash מותאמות אישית

מתחילים 8 דקות חינם מעשי

תיקיית .claude/commands/ היא הבית של פקודות ה-/slash המותאמות שלך. כל קובץ .md בתיקייה הופך אוטומטית לפקודה. שם הקובץ (בלי סיומת) = שם הפקודה:

קובץ פקודה
.claude/commands/deploy.md /deploy
.claude/commands/write-blog.md /write-blog
.claude/commands/audit.md /audit
.claude/commands/content/blog.md /content-blog

שימו לב לשורה האחרונה: תתי-תיקיות יוצרים פקודות עם Namespace. התיקייה content/ עם הקובץ blog.md הופכת לפקודה /content-blog. זה מעולה לארגון — אפשר ליצור תיקיות לפי תחום: deploy/, content/, quality/.

Project-Level vs Global Commands

יש שתי רמות:

💡 היחס בין commands/ לבין Skills

מאז גרסה 2.1.0, תיקיית commands/ ומערכת ה-Skills מאוחדות. קובץ Command הוא קובץ Skill. אתה יכול להשתמש ב-YAML Frontmatter מלא בקבצי Command — כולל model, fork, invoke ושאר השדות. אם אתה רואה "Skill" ו-"Custom Command" במקומות שונים — מדובר באותו דבר בדיוק.

כלל אצבע לחלוקה בין Project ל-Global:

שיתוף Skills עם הצוות

כי Skills הם קבצי Markdown רגילים בתיקיית .claude/commands/, הם חלק מה-Git Repository. כשאתה מוסיף Skill חדש ועושה Commit + Push — כל הצוות מקבל אותו. זה אחד היתרונות הגדולים של הארכיטקטורה: Skills הם Infrastructure as Code — כמו הגדרות CI/CD או Docker Compose, אבל עבור זרימת העבודה של ה-AI.

דוגמה מעשית: ב-Sprint Planning, הצוות מחליט על Coding Standards חדשים. ה-Tech Lead כותב Skill בשם /pr-check שבודק את הסטנדרטים האלה. עושה Commit. מהרגע הזה, כל חבר צוות שמושך את ה-Branch יכול להפעיל /pr-check לפני שפותח PR. כולם משתמשים בדיוק באותן בדיקות — עקביות מלאה.

ארגון תיקיית Commands מומלץ

📚 מבנה תיקיות מומלץ

.claude/commands/
  deploy/
    staging.md        # /deploy-staging
    production.md     # /deploy-production
  content/
    blog-he.md       # /content-blog-he
    release-notes.md  # /content-release-notes
  quality/
    security-check.md # /quality-security-check
    lint-fix.md      # /quality-lint-fix
  check-todos.md      # /check-todos
  hello.md            # /hello

⚡ עשה עכשיו 5 דקות

צור את מבנה התיקיות הבסיסי:

  1. mkdir -p .claude/commands/deploy
  2. mkdir -p .claude/commands/content
  3. mkdir -p .claude/commands/quality

העבר את hello.md ו-check-todos.md לשם אם הם לא שם כבר. הקלד /help ב-Claude Code וודא שכל הפקודות מופיעות.

מתחיל 5 דקות חינם תרגול

Hot Reload ואיטרציה מהירה

מתחילים 5 דקות חינם מעשי

אחד הדברים הכי נוחים ב-Skills: אתה לא צריך לאתחל את Claude Code כשמעדכנים Skill. ערוך את קובץ ה-.md, שמור, וההפעלה הבאה כבר תשתמש בגרסה המעודכנת. זה נקרא Hot Reload.

לולאת האיטרציה נראית ככה:

  1. הפעל /my-skill
  2. בדוק את הפלט — מה טוב? מה חסר?
  3. ערוך את .claude/commands/my-skill.md
  4. שמור
  5. הפעל /my-skill שוב
  6. חזור לשלב 2 עד שהתוצאה מושלמת

לא צריך לסגור את Claude Code. לא צריך להתחבר מחדש. לא צריך לחכות. פשוט עורכים ומפעילים.

💡 Setup מומלץ לפיתוח Skills

פתח שני חלונות זה לצד זה: בחלון אחד — עורך טקסט עם קובץ ה-Skill. בחלון שני — Claude Code. ערוך, שמור, הפעל, חזור על זה. תוך 10 דקות של איטרציות תקבל Skill מושלם.

ההשלכה המעשית: אל תנסה לכתוב את ה-Skill המושלם מההתחלה. כתוב גרסה ראשונה מינימלית, בדוק, שפר. כל Skill טוב עובר 3-5 סבבי שיפור לפני שהוא מגיע לגרסה הסופית.

3-5

סבבי איטרציה ממוצעים לפני ש-Skill מגיע לגרסה יציבה. סבב = עריכה + שמירה + הפעלה + בדיקת פלט. עם Hot Reload, כל סבב לוקח 2-3 דקות. סך הכל: 10-15 דקות לפיתוח Skill מלוטש — השקעה שמחזירה את עצמה תוך 3 הפעלות.

טיפ מתקדם: כשאתה מפתח Skill חדש, שמור "לוג פיתוח" — רשום מה שינית בכל סבב ולמה. זה עוזר כשחוזרים ל-Skill אחרי חודשיים ושוכחים למה הוראה מסוימת נוספה. אפשר להוסיף את הלוג כהערת HTML בתוך הקובץ:

📚 לוג פיתוח Skill

<!-- Changelog:
v1 - Basic review with 3 checks
v2 - Added TypeScript-specific checks after false positive on .js files
v3 - Added output format table (was inconsistent in v1-v2)
v4 - Added error handling for empty git diff
-->

⚡ עשה עכשיו 3 דקות

פתח את /hello Skill, שנה את ההוראה — במקום "fun fact" בקש "security observation" (תצפית אבטחה). שמור והפעל /hello שוב. וודא שהפלט השתנה בלי שהיית צריך לאתחל שום דבר.

מתחיל 12 דקות חינם כלי

Skills מובנים — מה מגיע עם Claude Code

בינוני 12 דקות מעשי תיאוריה

Claude Code מגיע עם מספר Skills מובנים שזמינים בכל סשן בלי שתצטרך להתקין שום דבר. חשוב להכיר אותם — הם חוסכים המצאה מחדש של הגלגל.

לפני שאתה ממציא את הגלגל ויוצר Skill חדש, בדוק אם כבר קיים Skill מובנה שעושה את מה שאתה צריך. ה-Skills המובנים עברו שיפור מתמשך לאורך חודשים ומשתמשים בהם אלפי מפתחים — הם מלוטשים ויעילים.

176

עדכונים שוחררו ל-Claude Code ב-2025 לבד. בין ינואר למרץ 2026 הגענו לגרסה 2.1.81 — עם יותר מ-80 גרסאות נוספות. Skills מובנים חדשים מתווספים בקביעות, ו-Skills קיימים משתפרים. כדאי לבדוק /help לפחות פעם בשבוע כדי לגלות מה חדש.

/simplify — ביקורת קוד עם 3 סוכנים מקבילים

הושק בפברואר 2026. כשאתה מפעיל /simplify, הוא בודק קבצים שהשתנו לאחרונה באמצעות 3 סוכנים מקבילים. כל סוכן בודק היבט אחר:

אחרי הניתוח, /simplify מתקן אוטומטית את הבעיות שזוהו. זה חזק אבל יקר — 3 סוכנים מקבילים פירושם 3x עלות.

/batch — המפלצת של Claude Code

הושק בפברואר 2026. זהו ה-Skill הכי חזק שמגיע עם Claude Code. /batch מנתח את ה-Codebase, מפרק עבודה ל-עד 30 יחידות עצמאיות, ומשגר סוכן אחד לכל יחידה — כל אחד ב-Git Worktree מבודד. כל סוכן מיישם את היחידה שלו, מריץ בדיקות, ופותח Pull Request.

מתי להשתמש: רפקטורינג גדול (למשל: "שנה את כל ה-API Endpoints מ-REST ל-GraphQL"), מיגרציות קוד (מ-JavaScript ל-TypeScript), שינויים בסיטונאות ("הוסף Error Handling לכל 50 ה-Controllers"). מתי לא: שינויים קטנים או ממוקדים — התקורה של 30 סוכנים לא מצדיקה שינוי של 3 קבצים.

טעות נפוצה: להשתמש ב-/batch למשימות קטנות

זה מפתה — /batch נשמע מרשים ואפשר לעשות הכל במכה אחת. אבל הפעלה אחת שמשגרת 15 סוכנים יכולה לעלות $5-15 בטוקנים. לשינוי של 3-5 קבצים? זה בזבוז. מה לעשות במקום: השתמש ב-/review או עבוד ידנית על משימות קטנות. שמור את /batch למשימות של 10+ קבצים עם שינויים חוזרים — שם ה-ROI מצדיק את העלות.

/debug — פותר בעיות סשן

/debug קורא את לוגי ה-Debug של Claude Code ומנתח התנהגות לא צפויה. כש-Claude "מתנהג מוזר" — זו הפקודה הראשונה להפעלה.

/loop — Cron קל בתוך הסשן

הושק במרץ 2026. /loop מריץ Prompt חוזר במרווחים קבועים. למשל: /loop 5m check the deploy status — כל 5 דקות, Claude בודק סטטוס Deploy. זה כמו Cron Job קליל שרץ בתוך הסשן.

דוגמאות שימוש:

שימו לב: /loop פעיל רק כל עוד הסשן פתוח. אם סוגרים את Claude Code, ה-Loop נעצר. לניטור שצריך לרוץ 24/7 — השתמשו ב-Cron Job אמיתי (או ב-Hooks).

/claude-api — עוזר לפיתוח עם Anthropic SDK

הושק במרץ 2026. אם אתה בונה אפליקציה שמשתמשת ב-Claude API, /claude-api נותן לך הקשר על מתודות SDK, Best Practices, ודוגמאות קוד עדכניות.

/review — ביקורת קוד ממוקדת

ביקורת קוד עם אפשרות להגדיר תחומי פוקוס. מפנה אותו לקובץ או תיקייה ומקבל Feedback מובנה.

/btw — הערת אגב מהירה

Skill קל שמאפשר להוסיף הערה בלי להפריע ל-Workflow הנוכחי.

Framework: ספקטרום העלויות של Skills מובנים

📚 Bundled Skill Cost Spectrum
Skill עלות סוכנים מתי להשתמש
/btw זול מאוד 0 (Single Call) הערות צד מהירות
/debug זול 0 (Single Call) דיבוג סשן לא תקין
/loop משתנה 0 (חוזר) ניטור מתמשך
/review בינוני ניתוח ממוקד Code Review לפני PR
/claude-api בינוני ניתוח ממוקד פיתוח עם Claude SDK
/simplify יקר 3 מקבילים שיפור איכות קוד לאחר שינויים
/batch יקר מאוד עד 30 מקבילים רפקטורינג גדול / מיגרציות
⚡ עשה עכשיו 5 דקות

נסה את /review על קובץ בפרויקט שלך. הקלד: /review src/main.ts (או קובץ אחר שקיים אצלך). בדוק את הפידבק שמתקבל. אחר כך נסה /debug — גם אם אין בעיה, תראה מה הוא מספר על מצב הסשן שלך.

בינוני 25 דקות חינם תרגול

בניית Skill שלם: מחולל בלוגים בעברית

מתקדם 15 דקות מעשי

הגיע הזמן לבנות Skill אמיתי ומלא — מתחילתו ועד סופו. נבנה מחולל פוסטים לבלוג בעברית שמייצר תוכן עקבי ואיכותי בכל הפעלה.

שלב 1: הגדרת ה-YAML Frontmatter

📚 write-blog-he.md — YAML

---
name: write-blog-he
description: Generate a Hebrew blog post with English technical terms, SEO-optimized
model: sonnet
effort: medium
fork: true
---

למה הבחירות האלה?

שלב 2: כתיבת ההוראות

📚 write-blog-he.md — הוראות מלאות

# Hebrew Blog Post Generator

You are writing a professional Hebrew blog post. The user will provide a topic.

## Process

1. **Research**: Use WebSearch to find 3-5 relevant sources on the topic.
Extract key data points, statistics, and current trends.

2. **Outline**: Create an outline with:
   - Title (H1) -- catchy, includes the primary keyword
   - 4-6 subheadings (H2) that cover the topic comprehensively
   - Key points under each H2

3. **Write the post** following these rules:
   - Language: Hebrew. Technical terms in English on first mention,
     then Hebrew explanation in parentheses
   - Minimum 1,500 words
   - Short paragraphs (2-4 sentences)
   - Include at least 2 practical examples using Israeli businesses
   - Prices/costs in ILS
   - Conversational tone -- like a mentor, not a textbook
   - End each section with an actionable takeaway

4. **SEO Meta**: Generate a meta description (150-155 chars, Hebrew)

5. **Internal Linking**: Suggest 3-5 related topics for internal links

6. **CTA**: End with a clear call-to-action in Hebrew

## Output Format

Deliver the final post as clean HTML (no full page, just the article body).
Use semantic HTML: h1, h2, h3, p, ul, ol, strong, em.
Add a comment at the top: <!-- SEO: meta description here -->
Add a comment at the end: <!-- Internal links: topic1, topic2, topic3 -->

## Quality Gate

Before delivering, verify:
- [ ] Minimum 1,500 words
- [ ] All H2 sections have at least 2 paragraphs
- [ ] At least 2 Israeli business examples
- [ ] Meta description is 150-155 characters
- [ ] CTA is present and clear
If any check fails, fix it before delivering.

שלב 3: שמירה ובדיקה

  1. שמור את הקובץ ב-.claude/commands/write-blog-he.md (או ב-~/.claude/commands/ אם אתה רוצה אותו גלובלי)
  2. ב-Claude Code הקלד: /write-blog-he
  3. כשנשאל, כתוב נושא: "שיווק דיגיטלי לעסקים קטנים ב-2026"
  4. בדוק את הפלט — האם עומד בכל הקריטריונים?

שלב 4: איטרציה — הלב של פיתוח Skills

סביר שהגרסה הראשונה לא תהיה מושלמת. אולי הפוסט קצר מדי, או שאין מספיק דוגמאות ישראליות, או שה-CTA חלש. הנה רשימת בעיות נפוצות ואיך לתקן אותן בהוראות:

בעיה בפלט מה לתקן בהוראות
פוסט קצר מדי (פחות מ-1,500 מילים) הוסף "Each H2 section MUST have at least 300 words. Expand with examples and data."
אין דוגמאות ישראליות הוסף "REQUIRED: At least 2 examples using Israeli businesses. Use ILS for all prices."
CTA חלש או חסר הוסף "The CTA must include a specific next step, not just 'contact us'. Example: 'Schedule a free 15-minute consultation.'"
יותר מדי אנגלית, מעט עברית הוסף "Write 90%+ in Hebrew. English terms ONLY for technical concepts, always with Hebrew explanation."
פורמט HTML לא נקי הדגש "NO inline styles. NO class attributes. Only semantic HTML tags."

כל בעיה שמוצאים בפלט = שורה נוספת בהוראות. אחרי 3-5 סבבים של עריכה → שמירה → הפעלה → בדיקה — יש לך Skill שמייצר פוסטים באיכות גבוהה באופן עקבי.

שלב 5: הוספת הערת עלות

הוסף בסוף הקובץ:

📚 הערת עלות

<!-- Cost: ~$0.15-0.40 per blog post (Sonnet with WebSearch) -->

ה-Skill הזה, עם model: sonnet ו-Fork, עולה בערך $0.15-0.40 לפוסט. עם model: opus זה יעלה $0.80-1.50 — שלוש פעמים יותר, עם שיפור קטן באיכות לרוב הנושאים. מתי שווה Opus? כשהנושא טכני מאוד או דורש ניתוח מעמיק.

⚡ עשה עכשיו 10 דקות

צור את הקובץ .claude/commands/write-blog-he.md עם הקוד שלמעלה. הפעל אותו עם נושא שרלוונטי לפרויקט שלך. בדוק את התוצאה מול רשימת הבדיקות (Quality Gate). תקן את ההוראות לפחות פעם אחת ובדוק שוב.

דוגמאות מייצגות: מ-Skill פשוט ל-Skill מלוטש

בואו נראה איך Skill מתפתח ממשהו בסיסי למשהו מקצועי. ניקח Skill שבודק איכות תיעוד (Documentation Quality):

גרסה 1 — הניסוי הראשון:

📚 v1 — בסיסי

---
name: check-docs
description: Check documentation quality
---

Check if the documentation is good.

בעיה: ההוראה "check if the documentation is good" מעורפלת מדי. Claude לא יודע מה "good" אומר — ויבדוק משהו אחר בכל הפעלה.

גרסה 2 — אחרי הפעלה ראשונה:

📚 v2 — ספציפי יותר

---
name: check-docs
description: Audit JSDoc coverage and README completeness
model: sonnet
fork: true
---

1. Find all exported functions in `src/`
2. Check each function for JSDoc comments
3. Verify README.md has: installation, usage, API reference sections
4. Report: Function | Has JSDoc | JSDoc Quality (good/partial/missing)

שיפור: עכשיו Claude יודע בדיוק מה לבדוק ואיך לדווח. הוספנו מודל (sonnet) ו-Fork (true) כי הבדיקה קוראת הרבה קבצים.

גרסה 3 — אחרי שבוע של שימוש:

📚 v3 — מלוטשת

---
name: check-docs
description: Audit JSDoc coverage, README completeness, and CHANGELOG freshness
model: sonnet
effort: medium
fork: true
---

# Documentation Quality Audit

## Step 1: JSDoc Coverage
Find all exported functions/classes in `src/`. For each:
- Has JSDoc? (yes/no)
- If yes: has @param, @returns, @example? (partial/complete)
- If no: flag as "MISSING"

## Step 2: README Check
Verify README.md contains these required sections:
- [ ] Installation instructions
- [ ] Quick start / usage example
- [ ] API reference or link to docs
- [ ] Contributing guidelines
- [ ] License

## Step 3: CHANGELOG Freshness
Check if CHANGELOG.md was updated in the last 5 commits.
If not, flag as "STALE".

## Output Format
Report as three tables:
1. JSDoc Coverage: Function | Status | Details
2. README Sections: Section | Present? | Notes
3. Summary: Total coverage %, critical gaps, action items

## Error Handling
- If no `src/` directory exists, check `lib/` and `app/` instead.
- If no README.md exists, report "CRITICAL: No README found" as first item.
- If the project has 0 exported functions, skip JSDoc check and note it.

הגרסה השלישית היא Skill מקצועי: מכסה מקרי קצה, מגדיר פורמט פלט ברור, ומחולק לשלבים לוגיים. נדרשו 3 סבבי איטרציה — פחות מ-15 דקות סה"כ — כדי להגיע לכאן.

🎯 תרגיל 1: Skill ל-Release Notes אוטומטיים
  1. צור Skill בשם release-notes
  2. ה-Skill צריך לקרוא את ה-commits האחרונים (git log --oneline -20)
  3. לקטלג כל commit לקטגוריה: Feature, Fix, Refactor, Docs, Other
  4. לייצר Release Notes בפורמט: כותרת עם מספר גרסה, רשימה ממוינת לפי קטגוריה, סיכום של השינויים החשובים בהתחלה
  5. הגדר model: sonnet, effort: low, fork: true
  6. בדוק שהפלט קריא ומדויק
מתקדם 15 דקות חינם תרגול

Shell Commands ב-Skills — הזרקת נתונים דינמיים

מתקדם 10 דקות חינם מעשי

Skills יכולים לכלול פקודות Shell שרצות לפני ש-Claude מעבד את ההוראות. הפלט של הפקודה מחליף את הפקודה בטקסט, כך ש-Claude רואה את התוצאה כאילו מישהו כתב אותה ידנית בהוראות.

זה הופך Skills מסטטיים לדינמיים: במקום הוראות קבועות, ה-Skill מתאים את עצמו למצב הנוכחי של הפרויקט.

דוגמה בסיסית: הזרקת Git Status

📚 Skill עם Dynamic Data

בגוף ההוראות כתוב:

Review the following changed files:
`git diff --name-only HEAD~1`

For each file, check for:
- Security vulnerabilities
- Missing error handling
- Unused imports

כש-Claude מעבד את ה-Skill, הפקודה git diff --name-only HEAD~1 רצה קודם, והפלט (רשימת קבצים שהשתנו) מוחלף לתוך ההוראות. Claude רואה את רשימת הקבצים ממש כאילו הקלדת אותה.

שימושים מתקדמים

הזרקת נתונים דינמיים פותחת אפשרויות עצומות:

שימוש פקודת Shell מה Claude מקבל
תאריך נוכחי `date +%Y-%m-%d` 2026-03-23
משתני סביבה `echo $NODE_ENV` production / development
מצב דיסק `df -h / | tail -1` שורת מידע על שטח פנוי
שירותים פעילים `docker ps --format "table {{.Names}}\t{{.Status}}"` טבלת קונטיינרים ומצבם
סטטוס API `curl -s https://api.example.com/health | jq .status` "healthy" או "degraded"
Branch נוכחי `git branch --show-current` שם ה-Branch
טעות נפוצה: להזריק API Keys דרך Shell Commands לתוך Skills

זה מפתה — "הSkill צריך את ה-API Key כדי לעבוד." אבל כל נתון שמוזרק דרך Shell Command נכנס לתוך ההקשר של Claude ונשלח ל-API של Anthropic. זה אומר שהסיסמה שלך עוברת דרך שרתים חיצוניים. מה לעשות במקום: הזרק רק מידע לא רגיש — `echo $NODE_ENV` (מותר), `echo $API_KEY` (אסור). כלל אצבע: אם אתה לא מוכן לפרסם את הפלט של הפקודה — אל תזריק אותו.

שילוב הוראות סטטיות ודינמיות

הכוח האמיתי הוא בשילוב: הוראות קבועות (סטטיות) + נתונים חיים (דינמיים) = Skill שמתאים את עצמו למצב. חשוב על זה כתבנית עם חורים שמתמלאים בנתונים אמיתיים בכל הפעלה:

📚 Skill לדוח מצב פרויקט

---
name: project-status
description: Generate a project status report with live data
fork: true
---

# Project Status Report

Generate a status report based on the following live data:

## Current Branch
`git branch --show-current`

## Recent Changes (last 7 days)
`git log --oneline --since="7 days ago"`

## Open Issues
`git log --oneline --all --grep="TODO\|FIXME" | head -10`

## Test Status
`npm test 2>&1 | tail -5`

Based on this data, write a concise project status report. Include:
1. Summary (2-3 sentences)
2. Key changes this week
3. Risks or concerns
4. Recommended next steps

מתי לא להשתמש ב-Shell Commands דינמיים

לא כל Skill צריך נתונים דינמיים. הנה המצבים שבהם הוראות סטטיות עדיפות:

הכלל: השתמש ב-Dynamic Data Injection כשצריך "לכוון" את ה-Skill לנתונים ספציפיים לפני שמתחיל. אם ה-Skill יכול למצוא את הנתונים בעצמו — תן לו.

⚡ עשה עכשיו 7 דקות

צור Skill בשם daily-review.md שמשלב נתונים דינמיים:

  1. מזריק `git log --oneline --since="1 day ago"` — השינויים של היום
  2. מזריק `git diff --stat HEAD~5` — סטטיסטיקת שינויים אחרונים
  3. מבקש מ-Claude לסכם: מה נעשה היום, מה נשאר לעשות, ומה דורש תשומת לב

הפעל את /daily-review ובדוק שהנתונים הדינמיים מוזרקים נכון.

בינוני 10 דקות חינם אסטרטגיה

Best Practices — כללי זהב ל-Skills

בינוני 10 דקות חינם תיאוריה + מעשי

אחרי שלמדת את הטכניקה, הנה הכללים שיהפכו Skills טובים ל-Skills מעולים.

1. Skill אחד, מטרה אחת

Skill צריך לעשות דבר אחד היטב. אל תיצור Mega-Skill שמבצע Deploy, בודק Tests, כותב Release Notes, ומעדכן Docs — בו-זמנית. פצל למספר Skills קטנים שכל אחד ממוקד.

Framework: "Single Responsibility Skill" — אם אתה צריך יותר ממשפט אחד כדי לתאר מה ה-Skill עושה, הוא כנראה עושה יותר מדי. פצל.

2. שמות ברורים

שם הפקודה צריך לספר לכל אחד בצוות בדיוק מה היא עושה. /deploy-staging טוב. /ds רע. /do-everything גרוע.

3. טיפול בשגיאות בהוראות

תמיד אמור ל-Claude מה לעשות כשמשהו נכשל. "If tests fail, STOP and report." בלי זה, Claude ימשיך הלאה — ואתה תגלה את הבעיה רק בסוף.

4. הגדרת פורמט פלט

ציין את הפורמט הרצוי בהוראות: "Report as a markdown table", "Output as JSON", "Write a bullet list with emojis." בלי זה, תקבל פורמט שונה בכל הפעלה.

5. גרסאות ב-Git — Skills כחלק מהקוד

שמור את ה-Skills ב-Git יחד עם הקוד. כשהפרויקט מתפתח, ה-Skills מתפתחים איתו. אם שינית את פרוטוקול ה-Deploy, עדכן גם את /deploy. פתח PR נפרד לשינויי Skills משמעותיים — זה נותן לצוות הזדמנות לעבור על השינויים ולתת פידבק.

גישה מומלצת: תייג כל Skill עם גרסה בהערת HTML. כשצריך לעשות Debug — אפשר לראות באיזו גרסה של ה-Skill הבעיה התחילה:

📚 תיוג גרסאות

<!-- Version: 2.1 | Last updated: 2026-03-20 | Author: Team Lead -->

6. בדיקה עם מקרי קצה

הרץ את ה-Skill על קלט לא שגרתי: פרויקט ריק, קובץ שבור, Branch ללא commits. ודא שההוראות מטפלות בכל מצב. הנה מקרי קצה שכדאי לבדוק:

לכל מקרה קצה, הוסף הוראה מתאימה: "If no commits found, report 'No changes since yesterday' and suggest reviewing backlog items instead."

7. הערות עלות

הוסף הערת HTML בקובץ ה-Skill עם הערכת עלות:

📚 דוגמה — הערת עלות

<!-- Cost: ~$0.10-0.30 per invocation -->

זה עוזר לך ולצוות להחליט אם להפעיל את ה-Skill או לעשות את המשימה ידנית.

8. Skill Naming Convention לצוותים

כשעובדים בצוות, הסכימו על Convention לשמות. הנה הצעה שעובדת היטב:

9. טעויות נפוצות שחשוב להימנע מהן

טעות תוצאה פתרון
הוראות מעורפלות: "בדוק את הקוד" Claude בודק משהו אחר כל פעם פרט בדיוק מה לבדוק, עם קריטריונים ופורמט פלט
אין שלב אישור לפני שינויים Claude עורך קבצים בלי לשאול הוסף "Show plan BEFORE making changes. Wait for approval."
יותר מדי Auto-Invoked Skills כל אינטראקציה נהיית איטית הגבל ל-2-3 Auto-Invoked. השאר User-Invoked
Fork ל-Skill שצריך הקשר ה-Skill לא רואה את מה שדיברתם השתמש ב-fork: false ל-Skills שצריכים היסטוריית שיחה
אין הערת עלות חבר צוות מפעיל Skill יקר 50 פעם ביום תמיד הוסף <!-- Cost: ... -->

10. Debugging — כש-Skill לא עובד כמצופה

לפעמים Skill לא מייצר את הפלט הצפוי. לפני שמתחילים לשנות הוראות באקראי, הנה תהליך Debug מסודר:

  1. בדוק YAML Syntax: שגיאת YAML (מרחב חסר, נקודתיים כפולות) גורמת לכל ה-Frontmatter להתעלם. ודא שיש --- בהתחלה ובסוף, שכל שדה כתוב נכון.
  2. הרץ בלי Fork: אם יש fork: true, שנה זמנית ל-false כדי לראות את כל שלבי הביניים. ככה תזהה איפה הבעיה.
  3. פשט את ההוראות: מחק את כל ההוראות חוץ מהשלב הראשון. אם שלב 1 עובד — הוסף שלב 2. כך תמצא את השלב הבעייתי.
  4. בדוק Shell Commands: אם יש פקודות Shell דינמיות, הרץ אותן ידנית בטרמינל וודא שהפלט תקין.
  5. השתמש ב-/debug: הפעל /debug אחרי ש-Skill נכשל — הוא יקרא את לוגי ה-Debug ויזהה בעיות.
💡 הבעיה הנפוצה מספר 1

הבעיה הכי נפוצה ב-Skills: ה-YAML Frontmatter לא מפורסר כי חסר --- בסוף, או שיש Tab במקום רווחים. YAML מאוד רגיש לפורמט. אם Skill לא עובד בכלל — התחל בלבדוק את ה-YAML.

טבלת Troubleshooting — "Skill לא עובד, מה עושים?"

סימפטום סיבה אפשרית פתרון
הפקודה /my-skill לא מוכרת שם הקובץ לא תואם, או שהקובץ לא ב-.claude/commands/ וודא: my-skill.md קיים בתיקייה הנכונה. בדוק שאין שגיאת YAML שמונעת פרסור של השדה name
Skill רץ אבל מתעלם מחלק מההוראות ההוראות ארוכות מדי או לא ברורות מספיק פשט: קצר ל-3-5 שלבים ברורים. השתמש בכותרות Markdown (#, ##) כדי לחלק. הוסף "IMPORTANT:" לפני הוראות קריטיות
Skill מחזיר תוצאה ריקה (Fork) ה-Fork נכשל או שלא מצא מה לעשות שנה ל-fork: false זמנית כדי לראות שגיאות. הוסף הוראת "If you cannot complete the task, explain why" בסוף
Shell Commands דינמיים מחזירים ריק הפקודה לא מוצאת נתונים (למשל git log בפרויקט בלי commits) הוסף fallback: `git log --oneline -10 2>/dev/null || echo "No commits found"`
Skill רץ עם המודל הלא-נכון שדה model לא מוגדר או שגוי ודא שכתבת model: sonnet (לא Model: Sonnet). YAML הוא Case-Sensitive. בדוק שאין רווח לפני הנקודתיים
Auto-Invoke לא מופעל ה-description לא ברור מספיק ל-Claude שכתב את ה-description כך שיהיה ספציפי: במקום "check code" כתוב "check TypeScript files for missing type annotations"
⚡ עשה עכשיו 3 דקות

עבור על כל ה-Skills שיצרת עד עכשיו בפרק הזה. לכל אחד, בדוק: (1) יש name ו-description ברורים? (2) יש הערת עלות? (3) הוראות כוללות טיפול בשגיאות? (4) פורמט פלט מוגדר? (5) YAML Syntax תקין (--- בהתחלה ובסוף)? תקן מה שחסר.

מסגרת החלטה: Skill מול Prompt מול Hook — מתי מה?
מצב כלי נכון למה
בדיקה אוטומטית על כל שינוי קובץ Hook Hook רץ אוטומטית על אירועים, בלי שצריך להפעיל
תהליך מורכב שמפעילים לפי בקשה Skill (User-Invoked) Skill מארז הוראות מורכבות לפקודה אחת
בדיקת איכות שתמיד צריכה לרוץ Skill (Auto-Invoked) Claude מפעיל בעצמו כשרלוונטי
שאלה חד-פעמית שלא תחזור Prompt רגיל לא שווה ליצור Skill למשהו שרץ פעם אחת
פורמט קבוע לכל פרויקט CLAUDE.md / Rules כללי עיצוב וסטנדרטים — לא צריכים הפעלה

עץ החלטה: Fork or Not Fork

📚 עץ החלטה: האם להשתמש ב-fork: true?

שאלה 1: האם ה-Skill צריך לראות מה דיברנו בשיחה?

  → כן: fork: false

  → לא: המשך לשאלה 2

שאלה 2: האם ה-Skill קורא הרבה קבצים או מריץ פקודות רבות?

  → כן: fork: true

  → לא: המשך לשאלה 3

שאלה 3: האם ה-Skill עלול להיכשל ואתה רוצה לנסות בלי לזהם את ההקשר?

  → כן: fork: true

  → לא: fork: false (ברירת המחדל)

🎯 תרגיל 2: בניית ספריית Skills — 3 פקודות מינימום
  1. קח את הרשימה של 3 משימות חוזרות שרשמת בתחילת הפרק
  2. כתוב Skill לכל אחת. לכל Skill הגדר: name, description, model, effort, fork
  3. בכל Skill כלול: שלבים ממוספרים, הגדרת פורמט פלט, טיפול בשגיאות
  4. בדוק כל Skill לפחות פעמיים — פעם עם קלט רגיל ופעם עם מקרה קצה
  5. הוסף הערת עלות (<!-- Cost: ... -->) לכל קובץ
  6. ארגן את ה-Skills בתיקיות לפי תחום
🎯 תרגיל 3: Skill עם Dynamic Data ו-Conditional Logic
  1. צור Skill בשם smart-review שמבצע ביקורת קוד דינמית
  2. ה-Skill צריך להזריק `git diff --cached --name-only` — קבצים ב-Staging
  3. אם הקבצים הם TypeScript — בדוק Types ו-Lint
  4. אם הקבצים הם Python — בדוק PEP8 ו-Type Hints
  5. אם הקבצים כוללים package.json — בדוק שאין Dependencies שלא בשימוש
  6. הגדר fork: true כי הביקורת קוראת הרבה קבצים
  7. הפלט: טבלת Markdown עם File, Issue, Severity, Fix Suggestion
🎯 תרגיל 4: שכפול Skill מובנה — בגרסה מותאמת
  1. צור Skill מותאם בשם my-review שמבוסס על /review אבל עם הכללים שלך
  2. הוסף להוראות את ה-Coding Standards הספציפיים של הפרויקט שלך (קרא אותם מ-CLAUDE.md)
  3. הגדר פורמט פלט שמתאים לתהליך ה-PR שלך
  4. הוסף בדיקות ספציפיות לפרויקט (למשל: "Check that all API endpoints return standard error format")
  5. בדוק: האם /my-review נותן תוצאה טובה יותר מ-/review הגנרי על הקוד שלך?
מתקדם 15 דקות חינם אסטרטגיה

Skill Composition — שרשור ושילוב Skills

מתקדם 12 דקות חינם מעשי

Skill בודד חזק. אבל שרשרת של Skills — זו מערכת אוטומציה שלמה. Composition (הרכבה) הוא הרעיון שSkill אחד יכול "לקרוא" ל-Skill אחר, או שתבנה Pipeline שמפעיל מספר Skills ברצף לפי תוצאות.

ב-Claude Code, אין תמיכה ישירה ב-"Skill calls Skill" (Skill לא יכול להפעיל /another-skill ישירות). אבל יש שלוש גישות פרקטיות לשרשור:

גישה 1: Orchestrator Skill — "מנצח" שמפעיל שלבים

Skill אחד שמכיל את כל השלבים ברצף. במקום 3 Skills נפרדים, Skill אחד גדול שמכסה את כל ה-Pipeline:

📚 Orchestrator Skill — Pipeline שלם

---
name: full-pr-pipeline
description: Complete PR preparation: lint, test, review, and PR creation
model: opus
effort: high
fork: true
---

# Full PR Pipeline

Execute these steps in order. Stop at any step that fails.

## Step 1: Lint & Format
Run linting and formatting on all changed files.
Fix any auto-fixable issues.

## Step 2: Run Tests
Execute the test suite. If any test fails, STOP and report the failure.
Do NOT proceed to Step 3.

## Step 3: Security Check
Scan changed files for hardcoded secrets, SQL injection patterns,
and missing input validation. Report any findings.

## Step 4: Generate PR Description
Based on git diff and commit messages, write a detailed PR description
following the template in .github/PULL_REQUEST_TEMPLATE.md.

## Step 5: Final Report
Summarize: tests passed, issues found, PR ready / not ready.

יתרון: פשוט, הכל במקום אחד, קל לתחזוקה. חיסרון: אם צריך רק Step 3 (Security Check), חייבים להריץ את כל ה-Pipeline.

גישה 2: Agent + Sub-Skills — סוכן שמפעיל Skills

צור Custom Agent שיודע על ה-Skills שלך ויכול להפעיל אותם לפי הצורך. בהוראות של ה-Agent, ציין את ה-Skills הקיימים ומתי להשתמש בכל אחד:

📚 Agent שמתזמר Skills

---
name: dev-assistant
description: Development assistant that orchestrates project workflows
model: opus
---

You are a development assistant. You have access to these workflows:

1. **Lint Check**: Run eslint on changed files and fix issues
2. **Security Scan**: Check for secrets and vulnerabilities
3. **PR Prep**: Generate PR description from git history

Based on the user's request, decide which workflows to run and in what order.
Always report results between steps so the user can intervene if needed.

גישה 3: Headless Chaining — שרשור ב-CLI

הגישה הכי גמישה: שרשור ב-Shell Script שמפעיל Claude Code ב-Headless Mode (-p flag) מספר פעמים ברצף. כל הפעלה מריצה Skill אחר:

📚 Shell Script — שרשור Skills

#!/bin/bash
# pipeline.sh — Chain multiple Skills

echo "Step 1: Lint..."
claude -p "/lint-fix" --bare

echo "Step 2: Security..."
result=$(claude -p "/security-audit" --bare)
if echo "$result" | grep -q "CRITICAL"; then
  echo "Security issues found! Aborting."
  exit 1
fi

echo "Step 3: PR..."
claude -p "/generate-pr" --bare

echo "Pipeline complete!"

שימו לב לדגל --bare — הוא מדלג על Hooks, LSP, ו-Plugin Sync, מה שמזרז את ההפעלה משמעותית. דגל זה הושק במרץ 2026 (גרסה 2.1.81) ומיועד בדיוק לתרחישים של CI/CD ואוטומציה.

3x

שלוש הגישות לשרשור Skills מתאימות לתרחישים שונים. Orchestrator Skill הוא הפשוט ביותר (קובץ אחד, אפס תלויות חיצוניות). Agent + Sub-Skills הוא הגמיש ביותר (Claude מחליט מה להפעיל). Headless Chaining הוא הכי מתאים ל-CI/CD (רץ בלי אינטראקציה, עם קודי יציאה לבקרת זרימה).

⚡ עשה עכשיו 5 דקות

חשוב על Pipeline בזרימת העבודה שלך שמורכב מ-2-3 שלבים. צור Orchestrator Skill שמבצע את כל השלבים ברצף עם נקודות עצירה (Stop Points) בין שלבים. הפעל ובדוק שהעצירה עובדת כשאחד השלבים נכשל.

מתחיל 15 דקות חינם תרגול

ספריית Templates — Skills מוכנים לשימוש

מעשי 10 דקות חינם

אחד הדברים שמעכבים אנשים מליצור Skills הוא השאלה "מאיפה מתחילים?" הנה 5 Templates מוכנים שאפשר להעתיק, להתאים, ולהשתמש מיד. כל Template כולל את ה-YAML המלא ואת ההוראות — פשוט תעתיק, תשנה את הפרטים הספציפיים, ותשמור.

Template 1: Code Review לפי סטנדרטים

📚 our-review.md

---
name: our-review
description: Code review using our team's specific standards
model: sonnet
effort: medium
fork: true
---

# Team Code Review

Review files changed in the current branch compared to main:
`git diff main --name-only`

## Checklist
For each changed file, verify:
- [ ] All functions have JSDoc with @param and @returns
- [ ] No hardcoded secrets or API keys
- [ ] Error handling exists for all async operations
- [ ] Imports are sorted alphabetically
- [ ] No console.log statements (use logger instead)
- [ ] Tests exist for new public functions

## Output
Report as: File | Issue | Line | Severity (critical/warning/info) | Fix
End with: Total issues, breakdown by severity, estimated fix time.

## Error Handling
If no files changed vs main, report "No changes to review" and stop.
If a file is binary (image, etc.), skip it and note "Skipped binary file."

Template 2: Changelog Generator

📚 changelog.md

---
name: changelog
description: Generate CHANGELOG entry from recent commits
model: sonnet
effort: low
fork: true
---

# Changelog Generator

Read recent commits:
`git log --oneline --since="last tag" 2>/dev/null || git log --oneline -20`

Categorize each commit: Added, Changed, Fixed, Removed, Security.

Output as Keep a Changelog format (https://keepachangelog.com):
## [Version] - `date +%Y-%m-%d`
### Added
### Changed
### Fixed

If a category has no entries, omit it.
Write the version as "[Unreleased]" unless user specifies a version number.

Template 3: Environment Health Check

📚 health-check.md

---
name: health-check
description: Check project health — dependencies, configs, and environment
model: haiku
effort: low
fork: true
---

# Project Health Check

## 1. Dependencies
If package.json exists: check for outdated packages (major versions behind).
If requirements.txt exists: verify all packages are pinned to specific versions.

## 2. Configuration
Compare .env.example with .env (if both exist). Flag missing variables.

## 3. Git Status
Report: current branch, uncommitted changes, unpushed commits.

## 4. Disk & Size
Report: node_modules size (if exists), .git size, total project size.

Output as a quick dashboard:
Dependencies: OK/WARN (N outdated)
Config: OK/WARN (N missing vars)
Git: Clean/Dirty (N uncommitted)
Size: X MB total

Template 4: Meeting Notes Generator

📚 meeting-notes.md

---
name: meeting-notes
description: Generate structured meeting notes from raw text or voice transcript
model: sonnet
effort: medium
fork: true
---

# Meeting Notes Generator

The user will paste raw meeting notes or voice transcript after the command.

Transform into structured format:

## [Meeting Title] - `date +%Y-%m-%d`
### Attendees
(Extract names mentioned)
### Key Decisions
(Bullet list of decisions made)
### Action Items
(Table: Task | Owner | Deadline)
### Discussion Summary
(3-5 paragraphs covering main topics)
### Open Questions
(Items that need follow-up)

Write in Hebrew. Names and technical terms in English.
If no text is provided, ask the user to paste the raw notes.

Template 5: Database Migration Generator

📚 gen-migration.md

---
name: gen-migration
description: Generate a database migration from schema changes
model: opus
effort: high
fork: true
---

# Migration Generator

1. Read the current schema file (look for schema.prisma, schema.sql, or models/)
2. Read recent git diff for schema changes
3. Generate an UP migration that applies the changes
4. Generate a DOWN migration that reverses them
5. Add data migration logic if columns are renamed or types changed

## Safety Rules
- NEVER generate DROP TABLE without explicit user confirmation
- Always wrap in transaction (BEGIN/COMMIT)
- Add IF EXISTS / IF NOT EXISTS guards
- Include a comment header: migration name, date, description

## Output
Write migration files to the appropriate directory:
- Prisma: generate prisma migration SQL
- Knex: generate knex migration JS
- Raw SQL: generate .sql file

Show plan BEFORE writing files. Wait for approval.

5 → 50

חמשת ה-Templates האלה הם נקודת ההתחלה. אחרי שתתאים כל אחד לצרכים שלך, כל Template יגדל: /our-review יקבל בדיקות ספציפיות לפרויקט, /changelog יקבל פורמט מותאם, /health-check יקבל בדיקות ספציפיות לסביבה שלך. תוך חודש תהיה לך ספרייה של 10-15 Skills מותאמים שחוסכים שעות.

⚡ עשה עכשיו 5 דקות

בחר Template אחד מהרשימה למעלה — את הרלוונטי ביותר לעבודה שלך. העתיק אותו לתוך .claude/commands/, התאם את הפרטים (Checklist, פורמט פלט, שם), ובדוק עם הפעלה אחת. אחר כך עשה לפחות סבב אחד של איטרציה (ערוך, שמור, הפעל).

בינוני 10 דקות חינם ניתוח

ROI Calculator — מדידת ההחזר על ההשקעה

מעשי 8 דקות תיאוריה + מעשי

Skills עולים כסף — כל הפעלה צורכת טוקנים. אבל Skills גם חוסכים כסף — זמן מפתח, עקביות, הפחתת טעויות. כדי להחליט אם Skill שווה את ההשקעה, צריך לחשב ROI (החזר על ההשקעה).

הנוסחה הבסיסית

ROI = (זמן שנחסך × שכר לשעה) - (עלות Skill × מספר הפעלות)

דוגמת חישוב: /our-review

פרמטר ערך
זמן Code Review ידני 15 דקות = 0.25 שעה
זמן עם Skill 3 דקות (הפעלה + קריאת דוח) = 0.05 שעה
חיסכון לכל הפעלה 12 דקות = 0.2 שעה
שכר מפתח ממוצע בישראל ~160 ₪ לשעה (עלות מעסיק)
ערך חיסכון לכל הפעלה 0.2 × 160 = 32 ₪
עלות Skill (Sonnet, Fork) ~$0.10-0.25 = ~0.40-1.00 ₪
הפעלות ביום (צוות של 4) ~10
ROI יומי (32 × 10) - (0.70 × 10) = 313 ₪ ליום
ROI חודשי (22 ימי עבודה) ~6,886 ₪ חיסכון נטו

כן, אתה קורא נכון. Skill אחד שחוסך 12 דקות לכל Code Review, עם צוות של 4 מפתחים שפותחים 2-3 PRs ביום כל אחד, מייצר חיסכון של כמעט 7,000 ₪ בחודש. העלות: פחות מ-200 ₪ בחודש בטוקנים. זה ROI של פי 35.

35x

ROI ממוצע של Skill שחוסך 12 דקות, 10 הפעלות ביום, עם צוות ישראלי. גם Skill שחוסך רק 5 דקות לכל הפעלה עדיין מניב ROI חיובי מההפעלה הראשונה — עלות הטוקנים זניחה לעומת עלות זמן מפתח.

מתי Skill לא שווה את ההשקעה?

Framework: "3-Use Rule" — אם תשתמש בתהליך 3 פעמים או יותר, צור לו Skill. פחות מ-3 פעמים — Prompt רגיל מספיק. זה הסף המינימלי שבו ההשקעה בכתיבת Skill מתחילה להחזיר את עצמה.
⚡ עשה עכשיו 3 דקות

קח Skill אחד שכבר יצרת. חשב: כמה זמן הוא חוסך בכל הפעלה? כמה פעמים ביום/שבוע תפעיל אותו? מה העלות לכל הפעלה (בדוק את הערת העלות)? חשב ROI חודשי. הוסף את התוצאה כהערה בקובץ ה-Skill.

מתחיל 5 דקות חינם תרגול

שגרת עבודה עם Skills

שגרת Skills — יומי / שבועי / חודשי

בנוסף לשגרת ה-Hooks מפרק 1 ולשגרת ה-Agents מפרק 2 ולשגרת תחזוקת ה-MCP מפרק 3, הנה השגרה הייעודית ל-Skills:

מתי מה לעשות זמן
יומי הפעל /daily-review בתחילת יום העבודה. השתמש ב-/check-todos לפני Commit. אם Skill לא עובד טוב — עדכן מיד עם Hot Reload 5 דקות
יומי הפעל /pre-pr לפני כל Pull Request — בדיקת איכות אחרונה 3 דקות
שבועי סקור את ספריית ה-Skills: האם יש משימה חוזרת שעדיין אין לה Skill? בדוק הערות עלות — אפשר להוריד מודל? 10 דקות
שבועי שתף Skills חדשים עם הצוות ב-PR. בדוק אם חברי צוות יצרו Skills שגם אתה יכול להשתמש בהם 5 דקות
חודשי רביזיה מלאה: מחק Skills שלא השתמשת בהם חודש. בדוק Bundled Skills חדשים. שקול Auto-Invoke על מוכחים (30+ הפעלות) 20 דקות
חודשי חשב ROI: כמה זמן חסכת? כמה עלה? האם המאזן חיובי? 10 דקות
85%

מהמפתחים שמשתמשים ב-Skills באופן קבוע מדווחים על שיפור בעקביות הפלטים מ-Claude Code, ועל חיסכון ממוצע של שעה ביום במשימות חוזרות. (דוגמאות מייצגות, בהתבסס על משוב משתמשים בקהילות מפתחים, 2026)

אם אתם עושים רק דבר אחד מהפרק הזה 5 דקות

צור Skill אחד היום. לא מחר, לא בסוף השבוע — היום. קח את המשימה שאתה עושה הכי הרבה ב-Claude Code, כתוב אותה כ-Skill עם הוראות ברורות, ושמור ב-.claude/commands/. לא צריך שיהיה מושלם — כתוב גרסה ראשונה ושפר עם Hot Reload. מהרגע שיש לך Skill אחד שעובד ושומר לך 5 דקות בכל שימוש, תרצה ליצור עוד. וספריית Skills מותאמת שגדלה = זרימת עבודה שמשתפרת כל שבוע. תוך חודש יהיו לך 10+ Skills שחוסכים שעה ביום.

בדוק את עצמך — 5 שאלות

ענה על 5 השאלות הבאות בלי לגלול למעלה. אם עונים נכון על 4 מתוך 5 — סיימת את הפרק בהצלחה.

  1. למה שדה ה-name ב-YAML Frontmatter כל כך חשוב ואיך הוא מתחבר לפקודות /slash? (רמז: ה-name הופך ישירות לפקודה — name: deploy = /deploy)
  2. מה הסכנה בלהגדיר יותר מדי Skills כ-Auto-Invoke ומה הפתרון? (רמז: Claude צריך להעריך כל Skill בכל בקשה. הפתרון: מקסימום 3-5, רק אחרי 30+ הפעלות ידניות)
  3. למה Forked Context חוסך ~95% מצריכת ה-tokens ומתי הוא דווקא לא מתאים? (רמז: רק הסיכום חוזר. לא מתאים כשצריכים הקשר מהשיחה)
  4. איך Shell Commands מזריקים נתונים דינמיים ל-Skill ומה הסכנה הגדולה? (רמז: Backticks מריצים פקודה לפני שClaude מעבד. הסכנה: הזרקת API Keys שנשלחים ל-API)
  5. מתי להשתמש ב-Skill, מתי ב-Hook, ומתי ב-CLAUDE.md — ומה עקרון ההבדל? (רמז: Skill = תהליך לפי בקשה, Hook = אוטומטי על אירוע, CLAUDE.md = כללים קבועים תמיד-פעילים)
סיכום הפרק

Skills הם השלב שבו Claude Code מפסיק להיות כלי שצריך להסביר לו מה לעשות בכל פעם — ומתחיל להיות מערכת אוטומציה אמיתית. התובנה המרכזית היא שכל תהליך חוזר ב-Claude Code הוא מועמד ל-Skill, וברגע שאתה כותב הוראות פעם אחת ומארז אותן כפקודה — אתה חוסך זמן בכל הפעלה עתידית ומקבל תוצאות עקביות. בשילוב עם Hooks (פרק 1), Custom Agents (פרק 2), ו-MCP (פרק 3), Skills מאפשרים לבנות Pipelines מורכבים שמתאימים את עצמם למצב הפרויקט דרך Shell Commands דינמיים. בפרק הבא נעבור ל-Plugins — שם נלמד לארוז Skills, Agents, Hooks ו-MCP Servers ביחד כחבילה שלמה שאפשר לשתף דרך המארקטפלייס.

צ'קליסט — סיום פרק 4