סקילים ופקודות מותאמות ב-Claude Code: להפוך עוזר קוד לכלי שמכיר אתכם

מאת צוות מדיה דיל · 07.08.2026 · AI · 16 דק׳

סקילים ופקודות מותאמות ב-Claude Code, מדריך מלא לכל פקודות ה-/ המובנות, custom slash commands, Agent Skills, SKILL.md, progressive disclosure, hooks, subagents ו-plugins.

מפתח שמשתמש ב-Claude Code שבוע-שבועיים מגלה תבנית חוזרת: הוא כותב שוב ושוב את אותן הוראות. ״סקור את הקוד ותתמקד בבאגים, לא בסגנון״. ״כתוב הודעת commit לפי הקונבנציה שלנו״. ״בנה קומפוננטת React עם הטסטים והסטיילינג בדיוק כמו שאנחנו עושים בפרויקט״. כל פעם מחדש, באותן מילים, בתקווה שהתוצאה תצא עקבית. הסקילים והפקודות המותאמות של Claude Code נולדו בדיוק בשביל להפסיק את החזרה הזו: במקום להסביר לכלי כל פעם מה אתם רוצים, אתם מלמדים אותו פעם אחת — והוא זוכר, מריץ באותה צורה, וזמין בלחיצה. זה ההבדל בין ״עוזר גנרי חכם״ ל״עוזר שמכיר את הקוד, את הסטנדרטים ואת זרימת העבודה הספציפית שלכם״.

מה זה בכלל סקיל ומה זו פקודה מותאמת

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

חשוב לדעת: בגרסאות העדכניות של Claude Code הפקודות המותאמות מוזגו אל תוך מערכת הסקילים. קובץ בשם deploy.md בתיקיית commands וקובץ SKILL.md בתיקיית skills בשם deploy — שניהם יוצרים בדיוק את אותה פקודה, /deploy, ועובדים אותו דבר. כלומר אין באמת שתי משפחות נפרדות אלא מנגנון אחד: פקודה היא סקיל בסיסי, וסקיל הוא פקודה עם יכולות אופציונליות נוספות — תיקיית קבצים תומכים, שליטה במי מפעיל אותה, ויכולת של Claude לטעון אותה לבד. הסקילים בנויים על תקן פתוח (Agent Skills) שעובד בכמה כלי AI ולא רק ב-Claude Code, כך שסקיל שכתבתם ניתן להעברה. לאורך המאמר נשמור על ההבחנה בין "פקודה" ל"סקיל" כי היא עוזרת ללמידה, אבל זכרו שמדובר באותה מערכת.

ההבדל בין השניים הוא בעיקר בעוצמה ובאוטונומיה. פקודה מותאמת (custom slash command) היא בעיקרה תבנית פרומפט — טקסט קבוע שאתם מזריקים לשיחה. סקיל (Agent Skill) הוא יחידה עשירה יותר: היא יכולה לכלול לא רק הוראות אלא גם סקריפטים להרצה, קבצי משאבים, ותיאור שמאפשר ל-Claude עצמו להחליט מתי להפעיל אותה — לא רק כשאתם מבקשים במפורש. פקודה היא ״כפתור שאתה לוחץ עליו״; סקיל הוא ״יכולת שהמערכת יודעת לשלוף לבד ברגע הנכון״. שתי המשפחות חולקות את אותה מטרה: להפוך ידע וזרימת עבודה חד-פעמיים לנכס קבוע, שאפשר לשתף עם צוות, לתחזק ולשפר לאורך זמן — בדיוק כמו קוד.

למה זה משנה: עקביות, שיתוף וזיכרון ארגוני

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

סקיל מקבע את הידע הזה. ברגע שכתבתם סקיל ״בניית קומפוננטה״ שכולל את כל הפרטים — מבנה התיקיות, אופן הסטיילינג, כתיבת הטסט, ה-props הטיפוסיים — כל מי שמריץ אותו מקבל את אותה איכות, בלי תלות בזיכרון או בניסוח. זה הופך את הידע מ״משהו שיושב בראש של המפתח הוותיק״ ל״נכס משותף בריפו״. חבר צוות חדש שמריץ את הפקודה מקבל מיד את הסטנדרט של הצוות, גם אם מעולם לא שמע עליו. וכמו כל נכס בריפו, סקילים עוברים בקרת גרסאות: הם יושבים כקבצים לצד הקוד, נכנסים ל-git, עוברים code review, ומשתפרים בהדרגה. כשמישהו מגלה שהסקיל מפספס משהו, הוא מתקן את הקובץ — וכל הצוות נהנה מהשיפור מיד. זה בדיוק ההבדל בין ידע שנשחק לבין ידע שמצטבר.

פקודות Slash מותאמות — המדריך המעשי

פקודה מותאמת היא פשוט קובץ Markdown בתיקייה ייעודית. יש שתי רמות: פקודות פרויקט יושבות בתיקיית commands בתוך תיקיית ההגדרות של הריפו — הן נכנסות ל-git ומשותפות לכל מי שעובד על הפרויקט, המקום לפקודות שקשורות לקודבייס הספציפי. פקודות אישיות יושבות בתיקיית ההגדרות בבית שלכם — הן זמינות בכל הפרויקטים במחשב אבל פרטיות, מתאימות להרגלי עבודה אישיים שלא רלוונטיים לצוות. שם הקובץ הוא שם הפקודה: קובץ בשם review יוצר את הפקודה review. פשוט ככה — יוצרים קובץ, מקלידים לוכסן, והפקודה שם.

מבנה הקובץ וה-frontmatter

הגוף של הקובץ הוא ההוראות ש-Claude יקבל. בראש הקובץ אפשר להוסיף בלוק הגדרות (frontmatter) שמעצב את ההתנהגות. השדות המרכזיים: description — תיאור קצר שמופיע בתפריט הפקודות כדי שתדעו מה הפקודה עושה; argument-hint — רמז לארגומנטים הצפויים שמוצג בזמן ההקלדה; allowed-tools — אילו כלים מותר לפקודה להשתמש בהם בלי לבקש אישור, מה שמאפשר למשל להתיר הרצת git diff אוטומטית בלי שתתבקשו לאשר בכל פעם; ו-model — קיבוע מודל ספציפי לפקודה, למשל מודל מהיר וזול לפקודות פשוטות ומודל חזק למשימות מורכבות. כל השדות אופציונליים; פקודה מינימלית היא קובץ עם שורת הוראה אחת ותו לא.

מעבר לארבעת השדות הבסיסיים יש עוד שדות שימושיים: when_to_use להוספת ביטויי טריגר שמסבירים ל-Claude מתי להפעיל; disable-model-invocation ו-user-invocable לשליטה במי מפעיל (נרחיב בהמשך); context ו-agent להרצה בסוכן משנה; paths להגבלת הפעלה לפי סוג קובץ; effort לרמת עומק החשיבה; ו-metadata לנתונים חופשיים משלכם. פרט דיוק חשוב: התיאור (description יחד עם when_to_use) נחתך ב-1,536 תווים ברשימת הסקילים כדי לחסוך בהקשר — לכן שמים את מה שהכי חשוב בהתחלה.

ארגומנטים: להפוך פקודה קבועה לפקודה גמישה

פקודה שמריצה בדיוק אותו דבר כל פעם שימושית, אבל פקודה שמקבלת קלט שימושית הרבה יותר. Claude Code תומך בהעברת ארגומנטים: המשתנה ARGUMENTS נותן לכם את כל מה שהוקלד אחרי שם הפקודה כמחרוזת אחת, והמשתנים הממוספרים (1, 2, 3) נותנים גישה לארגומנטים בודדים לפי מיקום, בדיוק כמו סקריפט shell. כך פקודת fix-issue יכולה לקבל מספר תקלה, וההוראה בגוף הקובץ מפנה אליו: ״טפל בתקלה מספר זה — קרא את התיאור, אתר את הקוד הרלוונטי, הצע תיקון והרץ את הטסטים לפני שתסיים״. עכשיו אותה פקודה עם מספר תקלה שונה מריצה את הזרימה על תקלה ספציפית — בדיוק כמו פונקציה שמקבלת פרמטר.

הרצת bash והפניה לקבצים בתוך הפקודה

שתי יכולות הופכות פקודות מטקסט קבוע לכלי דינמי אמיתי. הראשונה היא הרצת פקודות shell: כשמקדימים שורה בסימן קריאה, Claude Code מריץ אותה ומזריק את הפלט לתוך ההקשר לפני שהמשימה מתחילה. כך אפשר לבנות פקודה שתמיד מתחילה מהמצב העדכני — למשל פקודת commit ששואבת את מצב ה-git ואת ה-diff בפועל ברגע ההפעלה, ואז כותבת הודעת commit על סמך הנתונים האמיתיים ולא על הנחות. היכולת השנייה היא הפניה לקבצים: סימן שטרודל לפני נתיב קובץ מכניס את תוכנו להקשר, כך שאפשר לכתוב ״בדוק את הקובץ הזה״ בלי ש-Claude יצטרך לחפש אותו קודם.

Namespacing ודוגמאות מעשיות

כשמצטברות הרבה פקודות, אפשר לארגן אותן בתיקיות משנה, וזה יוצר מרחבי שם: קובץ בתיקיית frontend הופך לפקודה frontend:component. זה שומר על סדר כשיש עשרות פקודות ומאפשר לקבץ אותן לפי תחום. הכוח האמיתי מתגלה בשימוש — פקודות שצוותים בונים בפועל כוללות commit שכותבת הודעת commit לפי הפורמט של הצוות, test שמריצה את חבילת הבדיקות ומתקנת עד שהכול ירוק, pr שמכינה תיאור Pull Request מלא לפי התבנית של הריפו, explain שמסבירה קטע קוד מסובך לחניכת מפתחים חדשים, ו-refactor שמפשטת קוד נבחר בלי לשנות התנהגות ולפי הקונבנציות המקומיות. כל אחת היא קובץ Markdown קצר; יחד הן הופכות את Claude Code מעוזר גנרי לחבר צוות שמכיר בדיוק איך הצוות עובד.

מדריך מלא: כל פקודות ה-/ המובנות ב-Claude Code

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

ניהול הקשר ושיחה

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

/clear — מתחיל שיחה חדשה ונקייה: מוחק את היסטוריית השיחה הנוכחית כדי לפנות לגמרי את חלון ההקשר, אבל שומר על זיכרון הפרויקט (קובצי CLAUDE.md). זו הפקודה שמריצים כשעוברים למשימה חדשה שלא קשורה לקודמת, כדי ש-Claude לא ייגרר להקשר לא רלוונטי.
/compact — מסכם את השיחה הארוכה לגרסה תמציתית ומפנה מקום בחלון ההקשר, בלי לאבד את מה שחשוב. אפשר להוסיף הנחיה על מה להתמקד בסיכום. מריצים אותה כשהשיחה ארוכה וההקשר מתחיל להתמלא, אבל עדיין רוצים להמשיך מאותה נקודה.
/context — מציג ויזואלית כמה מחלון ההקשר תפוס וממה בדיוק (הוראות המערכת, הגדרות הכלים, קבצים שנקראו, וגוף השיחה) — רשת צבעונית שעוזרת להבין מתי הגיע הזמן לעשות compact או clear.
/resume — מציג רשימה של שיחות קודמות ומאפשר לחזור לאחת מהן ולהמשיך בדיוק מהמקום שבו עצרתם — גם אחרי שסגרתם את הטרמינל.
/rewind — מגלגל אחורה את הקוד ואת השיחה לנקודה מוקדמת יותר או ל-checkpoint שמור. זהו מנגנון ה-undo של Claude Code: אם סדרת שינויים יצאה לא טוב, במקום לתקן ידנית חוזרים אחורה לנקודה יציבה.
/memory — פותח לעריכה את קובצי הזיכרון (CLAUDE.md), ברמת הפרויקט או ברמה האישית. כאן מגדירים את ההנחיות הקבועות ש-Claude יטען בכל שיחה בפרויקט — קונבנציות, סגנון, ומידע שחשוב שיזכור תמיד.
/add-dir — מוסיף תיקייה נוספת לגישת הסשן בלי להעביר אליה את הסשן. שימושי במונו-רפו או כשמשימה אחת נוגעת בכמה פרויקטים במקביל.
/export — מייצא את השיחה הנוכחית לקובץ טקסט, לצורך תיעוד, שיתוף עם הצוות או שמירה של פתרון מוצלח.

בחירת מודל ועומק חשיבה

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

/model — מחליף בין המודלים של Claude. בלי ארגומנט נפתח בורר; אפשר גם לבחור auto. עוברים למודל חזק למשימה מורכבת, ולמודל קל ומהיר למשימות פשוטות וחוזרות.
/effort — קובע את רמת עומק החשיבה: low, medium, high, xhigh, max. עומק גבוה יותר מייצר תשובה יסודית יותר אך יקרה ואיטית יותר; לעריכה מכנית קטנה אין טעם בעומק מקסימלי.
/fast — עובר למצב המהיר ביותר עם לטנציה נמוכה, בלי לרדת במודל. מתאים לפעולות קלות שבהן חשובה תגובה זריזה.

איכות קוד וביקורת

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

/code-review (או /review) — סוקר את השינויים הנוכחיים (ה-diff) ומחפש באגים לצד הזדמנויות לפישוט וניקוי. אפשר לקבוע רמת עומק, ולהוסיף --fix כדי להחיל את התיקונים ישירות על הקוד.
/security-review — בודק את השינויים או ענף שלם מול פרצות אבטחה נפוצות. גם כאן --fix מחיל את התיקונים המומלצים.
/simplify — מציע פישוטים וניקיונות לקוד הקיים, בלי לשנות את ההתנהגות — ממוקד באיכות ולא בבאגים.
/test — כותב או מעדכן טסטים שתואמים לסגנון הבדיקות של הפרויקט, כולל מקרי קצה.
/verify — בונה ומריץ את הקוד בפועל כדי לוודא שהשינוי עובד; --fix מתקן את מה שנשבר. זה ההבדל בין "נראה תקין" ל"רץ תקין".

הגדרות, הרשאות ו-hooks

כאן מעצבים את חוקי המשחק של הסשן — מה מותר, מה אוטומטי, ומה דורש אישור.

/config (או /settings) — פותח את עורך ההגדרות או קובע ערך ישירות מהשורה. זה השער לקובץ settings.json שבו יושבות רוב ההעדפות.
/permissions — ממשק לניהול כללי ההרשאות: אילו כלים ופקודות מותר להריץ בלי לבקש אישור בכל פעם. כאן מכווננים את האיזון בין זהירות למהירות.
/hooks — מציג ומאפשר לבדוק את ה-hooks המוגדרים — הסקריפטים שרצים אוטומטית באירועים כמו סיום עריכה או לפני commit.
/keybindings — פותח את קובץ קיצורי המקלדת להתאמה אישית של הפעולות הנפוצות.
/theme — קובע ערכת נושא בהירה או כהה לממשק, לפי ההעדפה שלכם.

אינטגרציות והרחבות

הפקודות שמחברות את Claude Code לעולם שמחוצה לו — מערכות חיצוניות, מאגרי plugins, סוכני משנה וסביבת הפיתוח.

/mcp — מנהל את חיבורי שרתי ה-MCP: הפעלה, כיבוי והגדרה של החיבורים למערכות חיצוניות כמו בסיסי נתונים, GitHub או Slack. הרחבנו על הפרוטוקול עצמו במדריך על ארכיטקטורת MCP.
/plugins — מנהל plugins ממאגרים או מתיקיות מקומיות: התקנה, הסרה ועדכון של חבילות שאורזות פקודות, סקילים ו-hooks יחד.
/agents — מנהל את סוכני המשנה (subagents) וההגדרות המותאמות שלהם — ההקשרים המבודדים שמבצעים משימות בצד.
/install-github-app — מתקין את אפליקציית ה-GitHub של Claude Code, שמאפשרת אינטגרציה עם Pull Requests ותגובות אוטומטיות.
/login ו-/logout — התחברות והתנתקות מחשבון claude.ai.
/ide — הגדרת האינטגרציה עם סביבת הפיתוח (VS Code, JetBrains) לעבודה משולבת בעורך.

התחלה, תכנון ואבחון

הפקודות שמלוות פרויקט מהצעד הראשון ועד פתרון תקלות.

/init — סורק את הקודבייס ויוצר קובץ CLAUDE.md ראשוני עם תיעוד הפרויקט. זו נקודת הפתיחה המומלצת לכל פרויקט חדש — היא נותנת ל-Claude הקשר בסיסי על המבנה והקונבנציות.
/plan — עובר למצב תכנון: לפני ביצוע שינוי גדול, Claude מציג קודם את הגישה המלאה לאישור שלכם, ורק אחרי שאישרתם מתחיל לבצע. בלם בטיחות למשימות משמעותיות.
/status — מציג את מצב הסשן הנוכחי: המודל הפעיל, רמת העומק, משימות רקע ועוד — בלי להפריע לתשובה שרצה.
/doctor — מריץ בדיקת תקינות של ההתקנה ומאבחן בעיות הגדרה נפוצות. הפקודה הראשונה שמריצים כשמשהו לא עובד כמו שצריך.
/help — מציג את רשימת כל הפקודות הזמינות עם תיאוריהן. הדרך המהירה והמדויקת ביותר לגלות מה קיים בגרסה שמותקנת אצלכם.
/cost (או /usage) — מציג את צריכת הטוקנים והעלות של הסשן, כדי לשמור על שקיפות תקציבית.
/pr — פותח את ה-Pull Request של הריפו הנוכחי בדפדפן.
/diff — מציג בממשק אינטראקטיבי את השינויים שעדיין לא נכנסו ל-commit, לבדיקה מהירה לפני שמירה.

שלוש משפחות, ממשק אחד: כשאתם מקלידים לוכסן, אתם רואים זו לצד זו את הפקודות המובנות (לוגיקה קשיחה שרצה מיד, כמו /clear ו-/model), את הסקילים המובנים (זרימות עבודה מוכנות כמו /code-review ו-/security-review), ואת הפקודות והסקילים שאתם בניתם. ההבחנה הזו חשובה: את המובנות אי אפשר לשנות אבל אפשר לסמוך עליהן; את שלכם אתם מעצבים בדיוק לפי הצורך. יחד הן הופכות את הלוכסן לשלט המרכזי של כל העבודה — וברגע שמפנימים כמה כוח יושב שם, קשה לחזור לעבוד בלי זה.

תרחיש אמיתי: יום עבודה שלם עם הפקודות

הכוח של הפקודות מתגלה לא כשמסתכלים על כל אחת בנפרד, אלא כשרואים איך הן משתרשרות ליום עבודה שלם. נניח שהצטרפתם לפרויקט חדש. הצעד הראשון הוא /init — Claude סורק את הקודבייס ובונה קובץ CLAUDE.md שמתאר את המבנה, כך שמעכשיו כל שיחה מתחילה עם הקשר בסיסי במקום מאפס. עכשיו יש משימה משמעותית: להוסיף מודול תשלומים. במקום לתת ל-Claude לרוץ עליה ישירות, מריצים /plan — הוא מציג קודם את הגישה המלאה: אילו קבצים ייגעו, איזה מבנה, אילו טסטים. אתם קוראים, מתקנים פרט אחד, מאשרים — ורק אז הביצוע מתחיל, בלי הפתעות.

אחרי שהקוד נכתב, לא ממהרים ל-commit. מריצים /code-review כדי לתפוס באגים והזדמנויות לפישוט, ואז /security-review — כי מודול תשלומים נוגע בכסף ובנתונים רגישים, ופרצה כאן יקרה. שתי הסקירות מחזירות הערות; חלקן מתקנים עם --fix, חלקן ידנית. עכשיו /verify בונה ומריץ בפועל — לא "נראה תקין" אלא "רץ תקין". הכול ירוק. השיחה כבר ארוכה וחלון ההקשר מתחיל להתמלא, אז /context מראה כמה נשאר, ו-/compact מסכם את מה שהיה כדי לפנות מקום בלי לאבד את החוט. לבסוף /diff לבדיקה אחרונה, commit, ו-/pr לפתיחת ה-Pull Request בדפדפן. בין לבין, אם שינוי יצא לא טוב — /rewind מחזיר לנקודה יציבה. זה לא אוסף פקודות מנותקות; זו זרימת עבודה שלמה שבה כל פקודה תופסת את התפקיד שלה בדיוק ברגע הנכון, והלוכסן הוא השלט שמנצח על כולן.

Agent Skills — הרמה הבאה

פקודות מותאמות מצוינות, אבל יש להן תקרה: הן טקסט שאתם מפעילים במפורש. Agent Skills הם השלב הבא — יחידות ידע עשירות יותר שיכולות לכלול הרבה מעבר להוראה בודדת, ושהמערכת יודעת לשלוף לבד ברגע הנכון. סקיל הוא תיקייה שבמרכזה קובץ בשם SKILL.md, שנפתח ב-frontmatter עם שני שדות מרכזיים: name — שם הסקיל; ו-description — התיאור שהוא הלב של המנגנון, כי הוא אומר ל-Claude מתי הסקיל רלוונטי. ככל שהתיאור מדויק וכולל את מילות ההפעלה הנכונות, כך Claude יידע לשלוף את הסקיל בדיוק כשצריך. לצד הקובץ, התיקייה יכולה לכלול קבצים נוספים: סקריפטים בפייתון או ב-shell, תבניות, קבצי נתונים ומסמכי עזר. הסקיל הוא חבילה שלמה, לא רק טקסט.

Progressive Disclosure: למה סקילים לא מציפים את ההקשר

השאלה המתבקשת: אם יש לי חמישים סקילים, האם כולם נטענים לזיכרון בכל שיחה? התשובה — לא, וזה המנגנון החכם ביותר בארכיטקטורה. סקילים עובדים בשיטת חשיפה הדרגתית: בהתחלה Claude רואה רק את השם והתיאור של כל סקיל — כמה עשרות מילים, זול וקל. רק כשמשימה מתאימה לתיאור של סקיל מסוים, Claude טוען את התוכן המלא של אותו קובץ SKILL.md — וגם אז, הסקריפטים והמשאבים הכבדים נטענים רק אם הם באמת נדרשים. כך אפשר להחזיק ספרייה ענקית של יכולות בלי לשלם על כולן בכל שיחה. זה בדיוק כמו אינדקס בספר: לא קוראים את כולו, קוראים את מה שרלוונטי לשאלה.

איך Claude מחליט להפעיל סקיל

בניגוד לפקודה, שאתם מפעילים בהקלדת לוכסן, סקיל יכול להיות מופעל על ידי המודל עצמו. כשאתם מבקשים ״תמלא לי את הטופס הזה״, Claude סורק את התיאורים של הסקילים הזמינים, מזהה שסקיל ה-PDF רלוונטי, וטוען אותו לבד — בלי שביקשתם אותו בשם. זו הסיבה שהתיאור כל כך קריטי: הוא הטריגר שקובע אם הסקיל יישלף בזמן הנכון או יישאר רדום. עדיין אפשר להפעיל סקיל גם ידנית עם לוכסן, בדיוק כמו פקודה — אז מקבלים את שני העולמות: הפעלה אוטומטית כשהמערכת מזהה צורך, והפעלה מפורשת כשאתם רוצים שליטה. סקיל יכול גם להצהיר אילו כלים מותר לו להשתמש בהם, וחלק מהסקילים אף רצים בסוכן משנה נפרד — הקשר מבודד שמבצע את המשימה ומחזיר רק את התוצאה, בלי להעמיס את השיחה הראשית בכל שלבי הביניים.

שליטה מדויקת: מי מפעיל את הסקיל ומתי

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

disable-model-invocation: true אומר "רק אני מפעיל". Claude לא ייגע בסקיל לבד, גם אם נראה לו רלוונטי. זה הכרחי לכל פעולה עם תופעות לוואי — /commit, /deploy, /send-slack-message — כי אתם לא רוצים ש-Claude יחליט לפרוס לפרודקשן רק כי הקוד "נראה מוכן". בונוס: השדה גם מוריד את הסקיל מההקשר עד שמפעילים אותו, וחוסך טוקנים.

user-invocable: false הוא ההפך — "רק Claude מפעיל". מתאים לידע רקע שלא הגיוני שמשתמש יקרא לו כפקודה: סקיל שמסביר איך מערכת ישנה עובדת. Claude צריך לדעת את זה כשרלוונטי, אבל אין טעם שהוא יופיע בתפריט הפקודות. בלי אף אחד מהשדות — שניכם יכולים.

לשליטה עדינה יותר יש את שדה paths: תבניות glob שמגבילות מתי Claude טוען סקיל אוטומטית. סקיל עם paths של *.tsx ייטען לבד רק כשעובדים על קבצי React, ולא יעמיס את ההקשר כשעובדים על משהו אחר. ונקודת אבטחה קריטית: כשסקיל יושב ב-.claude/skills של פרויקט, שדה allowed-tools שלו נכנס לתוקף רק אחרי שאישרתם אמון בתיקייה. סקיל יכול להעניק לעצמו הרשאות רחבות — לכן בדקו סקילים של פרויקט לפני שאתם נותנים בו אמון, בדיוק כמו שהייתם בודקים קוד לפני הרצה. וההרשאה של allowed-tools מתאפסת בהודעה הבאה שלכם, כך שהיא חלה רק על התור שבו הפעלתם את הסקיל. למי שרוצה לשלוט ברמת ההגדרות: אפשר להתיר או לחסום סקילים ספציפיים דרך כללי הרשאות, ולכוונן נראות של סקיל דרך ההגדרה skillOverrides בלי לגעת ב-SKILL.md עצמו — שימושי לסקילים שמגיעים מריפו משותף.

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

מעבר לבסיס, סקילים מציעים כמה יכולות שהופכות אותם מטקסט לכלי אמיתי. הראשונה היא context: fork — הרצת הסקיל בתוך סוכן-משנה מבודד. במקום שהסקיל ירוץ בשיחה הראשית ויעמיס עליה, נוצר הקשר נפרד שמבצע את המשימה ומחזיר רק את התוצאה. שדה agent נלווה קובע איזה סוג סוכן מריץ (למשל Explore לחקירת קוד לקריאה בלבד). אידיאלי למשימות ארוכות כמו מחקר או סקירה, שלא רוצים שיציפו את השיחה.

היכולת השנייה היא הזרקת הקשר דינמי: כשמקדימים שורה בסימן קריאה ומקיפים פקודה בגרשיים הפוכים, Claude Code מריץ אותה עוד לפני שהתוכן מגיע ל-Claude, ומחליף את השורה בפלט בפועל. כך סקיל commit יכול לשאוב את git diff האמיתי ברגע ההפעלה במקום לנחש. לפקודות רב-שורתיות משתמשים בבלוק קוד שנפתח בשלושה גרשיים וסימן קריאה. חשוב: זו הרצה מקדימה, לא משהו ש-Claude מבצע — הוא רואה רק את התוצאה המוגמרת.

היכולת השלישית היא משתני הזרקה שהופכים סקיל לגמיש. מלבד $ARGUMENTS ו-$1/$2 שכבר הכרנו, יש משתנים מובנים: ${CLAUDE_SKILL_DIR} מצביע לתיקיית הסקיל עצמו — כך אפשר להריץ סקריפט מצורף בלי לדעת מראש איפה הותקן הסקיל; ${CLAUDE_PROJECT_DIR} מצביע לשורש הפרויקט; ו-${CLAUDE_SESSION_ID} נותן מזהה סשן, שימושי ללוגים. אפשר גם להגדיר ארגומנטים בשם דרך שדה arguments — עם arguments של issue ו-branch, המשתנה $issue מתרחב לארגומנט הראשון ו-$branch לשני, קריא הרבה יותר.

יכולת רביעית: קבצים תומכים. סקיל הוא תיקייה, ולצד SKILL.md אפשר לשים reference.md עם תיעוד מפורט, examples.md עם דוגמאות, ותיקיית scripts עם סקריפטים. הכלל: שמרו את SKILL.md מתחת ל-500 שורות, והפנו לקבצים הכבדים מתוכו — כך הם נטענים רק כשבאמת צריך, בדיוק לפי עקרון החשיפה ההדרגתית. ולבסוף, כדאי להבין את מחזור החיים: ברגע שסקיל מופעל, התוכן שלו נכנס לשיחה ונשאר עד סוף הסשן — Claude לא קורא את הקובץ מחדש בכל תור. כשההקשר מתמלא ומתבצע compaction, Claude Code שומר את הסקילים שהופעלו בתוך תקציב טוקנים (עד 5,000 טוקן לכל סקיל, 25,000 במצטבר), מהחדש לישן — כך שסקיל ישן שהפעלתם מזמן עלול לרדת, וכדאי להפעיל אותו מחדש אם צריך.

איפה סקילים חיים — הנתיבים המדויקים

המיקום של הסקיל קובע מי יכול להשתמש בו, ולכל רמה נתיב מדויק. סקיל אישי יושב ב-~/.claude/skills/<שם>/SKILL.md וזמין בכל הפרויקטים במחשב שלכם. סקיל פרויקט יושב ב-.claude/skills/<שם>/SKILL.md בתוך הריפו, נכנס ל-git וזמין רק בפרויקט הזה. סקיל plugin מגיע כחלק מחבילה ומקבל מרחב שם עם שם ה-plugin. וברמה הארגונית יש סקילים מנוהלים (managed) שנפרסים לכל הארגון דרך הגדרות מנוהלות.

כשאותו שם קיים בכמה רמות יש סדר עדיפויות: ארגוני גובר על אישי, אישי גובר על פרויקט, וכל אחד מהם גובר על סקיל מובנה באותו שם — כך שסקיל code-review משלכם יחליף את המובנה. עוד שתי נקודות מעשיות: זיהוי שינוי חי — כשאתם מוסיפים, עורכים או מוחקים סקיל, Claude Code קולט את השינוי באמצע הסשן בלי restart (למעט יצירת תיקיית סקילים חדשה מאפס). וסביבות ענן — סשנים בענן, ב-Cowork ובמשימות מתוזמנות לא קוראים את ~/.claude/skills שבמחשב שלכם; כדי שסקיל אישי יהיה זמין שם צריך להפעיל אותו לחשבון claude.ai או לשמור אותו בריפו של הפרויקט.

סקילים מובנים: מה מגיע מוכן

Claude Code מגיע עם סקילים מובנים שממחישים את הכוח. בעבודה עם מסמכים יש סקילים ליצירה ועריכה של Word, מצגות PowerPoint, גיליונות Excel וקבצי PDF, כולל מילוי טפסים ו-OCR. באיכות קוד יש סקיל לסקירת קוד שמתמקד בבאגים, סקיל לבדיקת אבטחה, וסקיל לפישוט קוד. בוויזואליזציה ועיצוב יש סקילים ליצירת גרפים, פוסטרים ו-artifacts אינטראקטיביים. ויש גם skill-creator — סקיל שכל תפקידו לעזור לכם לבנות סקילים חדשים, כלי שבונה כלים. הרשימה לא סטטית: כל ארגון יכול להוסיף סקילים משלו, וזה בדיוק הרעיון.

איך זה משתלב: hooks, subagents, MCP ו-Plugins

סקילים ופקודות הם חלק ממערכת רחבה יותר של התאמה אישית. Hooks הם סקריפטים שרצים אוטומטית באירועים מסוימים — למשל להריץ formatter אחרי כל עריכת קובץ, או לחסום פעולה מסוכנת לפני שהיא קורית; בעוד סקיל הוא ״מה לעשות כשמבקשים״, hook הוא ״מה לעשות תמיד, אוטומטית״. Subagents הם הקשרים מבודדים שמבצעים משימה בצד ומחזירים תוצאה, וסקיל יכול להשתמש בהם כדי לא להעמיס את השיחה הראשית. MCP הוא הפרוטוקול שמחבר את Claude למערכות חיצוניות — בסיסי נתונים, GitHub, Slack, כלים פנימיים; בעוד סקיל מלמד את Claude איך לעשות משהו, MCP נותן לו גישה למקורות ולפעולות חיצוניות, נושא שהרחבנו עליו במדריך על ארכיטקטורת MCP. Plugins הם חבילות שאורזות יחד פקודות, סקילים, hooks ושרתי MCP כדי לשתף מערך שלם של התאמות במכה אחת. יחד, ארבעת הרכיבים הופכים את Claude Code מכלי גנרי לפלטפורמה שאפשר לעצב סביב הצרכים של הארגון — הבסיס הרחב יותר מפורט במדריך המקיף על Claude Code.

איך בונים סקיל משלכם — צעד אחר צעד

הערך מגיע בבנייה. השלב הראשון הוא לזהות את החזרה: הסימן שמשהו ראוי להיות סקיל הוא שאתם עושים אותו יותר מפעם-פעמיים באותו אופן. אם בכל פעם שאתם מייצרים מאמר אתם מסבירים מחדש את המבנה, הכותרות, ה-SEO וה-schema — זה מועמד מושלם. השלב השני הוא ליצור את התיקייה והקובץ: בתוך תיקיית הסקילים פותחים תיקייה בשם הסקיל ובתוכה SKILL.md, כשה-name וה-description מתארים בדיוק מתי הסקיל רלוונטי. השלב השלישי הוא לכתוב את ההוראות — לפרט את הכללים: מבנה הכותרת, אורך הפסקאות, פורמט ה-HTML, שדות ה-SEO, מבנה ה-FAQ, וההנחיה לסיים בקריאה לפעולה. ככל שתהיו ספציפיים יותר, התוצאה תהיה עקבית יותר.

השלב הרביעי הוא להוסיף משאבים אם צריך: אם הסקיל דורש נתונים או סקריפט — למשל קובץ עם רשימת הקטגוריות המותרות, או סקריפט שמכניס את המאמר לבסיס הנתונים — שמים אותם בתיקייה ומפנים אליהם. השלב החמישי הוא לבדוק ולשפר: מריצים על כמה מקרים, בודקים איפה התוצאה מפספסת, ומחדדים. סקיל טוב הוא לא כזה שנכתב מושלם בפעם הראשונה, אלא כזה שמשתפר בכל שימוש. השלב האחרון הוא לשתף: מכניסים ל-git, וכל הצוות מקבל את הסקיל. הדרך הקלה ביותר להתחיל היא דווקא לבקש עזרה מ-Claude עצמו — סקיל ה-skill-creator המובנה מלווה אתכם בבניית סקיל חדש, כולל מבנה התיקייה, ניסוח התיאור לטריגר מדויק, ובדיקת הביצועים.

דוגמה מלאה מקצה לקצה: בניית פקודת commit של הצוות

כדי לחבר את כל החלקים, נבנה יחד פקודה אמיתית שצוותים משתמשים בה בפועל — פקודת commit שכותבת הודעות לפי הפורמט של הצוות. נתחיל מהבעיה: כל מפתח בצוות כותב הודעות commit בסגנון אחר, וההיסטוריה נראית מבולגנת. הכלל שרוצים לאכוף פשוט — פורמט conventional commits, כותרת קצרה בעברית, וגוף שמסביר את ה"למה" ולא רק את ה"מה". במקום להסביר את זה לכל מפתח, מקבעים אותו בפקודה.

יוצרים קובץ בשם commit.md בתיקיית הפקודות של הפרויקט. בראש הקובץ שמים frontmatter קצר: שדה description שיסביר בתפריט מה הפקודה עושה ("כתיבת הודעת commit לפי פורמט הצוות"), ושדה allowed-tools שמתיר להריץ git diff ו-git status בלי לבקש אישור בכל פעם. עכשיו מגיע החלק החכם: בגוף הקובץ מקדימים שתי שורות בסימן קריאה שמריצות git status ו-git diff, כך שהפלט האמיתי של מצב הריפו נכנס להקשר לפני שהמשימה מתחילה. Claude לא מנחש מה השתנה — הוא רואה את השינויים בפועל.

אחר כך כותבים את ההוראות עצמן: "על סמך ה-diff שלמעלה, כתוב הודעת commit. השורה הראשונה: קידומת conventional commit (feat/fix/refactor וכו') ואחריה תיאור קצר בעברית עד 60 תווים. אחרי שורה ריקה, גוף שמסביר למה השינוי נדרש ומה ההשלכה שלו. אל תמציא שינויים שלא מופיעים ב-diff." זהו — שומרים את הקובץ, ומרגע זה כל מי שמקליד /commit מקבל הודעה שנכתבת מהשינויים האמיתיים, בפורמט אחיד, בלי לזכור את הכללים. מפתח חדש שהצטרף אתמול מייצר commit באותה איכות כמו הוותיק בצוות.

השלב הבא הוא לשפר: אחרי שבוע מגלים שההודעות לפעמים ארוכות מדי. פותחים את commit.md, מוסיפים שורה על אורך הגוף, מכניסים ל-git — וכל הצוות מקבל את השיפור מיד. ואם רוצים לקחת את זה צעד קדימה, אפשר להפוך את הפקודה לסקיל: מעבירים אותה לתיקיית skills עם קובץ SKILL.md, מוסיפים תיאור מדויק, ועכשיו Claude יכול אפילו להציע לבד לכתוב commit כשהוא מזהה שסיימתם עבודה משמעותית. מפקודה פשוטה של חמש שורות הגענו ליכולת ארגונית מלאה — וזה בדיוק המסלול שכל סקיל טוב עובר.

מקרי שימוש עסקיים: מעבר למפתח הבודד

עד כאן דיברנו בעיקר על מפתחים, אבל הערך הארגוני גדול יותר. סוכנות או צוות פיתוח יכולים לבנות ספרייה שלמה של סקילים שמקבעת את הסטנדרטים שלהם: סקיל onboarding שמסביר למפתח חדש את מבנה הפרויקט והקונבנציות במקום מסמך שאף אחד לא קורא; סקיל deploy שמריץ את כל שלבי הפריסה בסדר הנכון עם הבדיקות שביניהם, כך שגם מי שלא מכיר את התהליך לא יכול לשבור אותו; סקיל ביקורת שבודק כל שינוי מול צ׳קליסט אבטחה ואיכות פנימי לפני מיזוג; וסקיל תוכן שמייצר מאמרים, תיאורי מוצר או תשובות שירות בקול ובפורמט האחיד של המותג. הערך המצטבר הוא שהידע של הארגון מפסיק להישחק: כשמפתח ותיק עוזב, הידע שלו לא הולך איתו אם הוא כבר מקובע בסקילים; כשמצטרף מפתח חדש, הוא מקבל את הסטנדרטים מהיום הראשון. זה בדיוק סוג העקביות שדיברנו עליו במדריך על Design Systems, רק שכאן זה חל על זרימות העבודה ולא רק על העיצוב.

Plugins ומרקטפלייסים: לשתף מערך שלם במכה אחת

ברגע שבניתם ספרייה של פקודות, סקילים ו-hooks, עולה שאלה טבעית: איך משתפים את כל המערך הזה — לא קובץ-קובץ אלא כחבילה אחת? כאן נכנסים ה-Plugins. Plugin הוא חבילה שאורזת יחד פקודות מותאמות, סקילים, hooks ואפילו הגדרות של שרתי MCP, ומאפשרת להתקין את כולם בפעולה אחת. במקום להעביר למפתח חדש עשרה קבצים ולהסביר איפה כל אחד יושב, הוא מריץ /plugins, מתקין את ה-plugin של הצוות, ומקבל מיד את כל מערך העבודה — הפקודות, הסטנדרטים והאוטומציות — מוכן לשימוש.

מעבר לצוות בודד, יש מרקטפלייסים: מאגרים שמהם אפשר למשוך plugins שאחרים בנו ושיתפו. זה הופך את ההתאמה האישית ממשהו שכל אחד ממציא מחדש למשאב משותף — בדיוק כמו ספריות קוד פתוח, רק שכאן מדובר בזרימות עבודה. ארגון יכול לבנות plugin פנימי שמקבע את כל הסטנדרטים שלו ולהפיץ אותו לכל הצוותים; קהילה יכולה לשתף plugin לעבודה עם framework מסוים. הרעיון המרכזי חוזר: ידע וזרימת עבודה מפסיקים להיות משהו שיושב בראש של אדם אחד, והופכים לנכס שאפשר לארוז, להפיץ, לנהל בגרסאות ולשפר יחד. זו אותה תובנה שמנחה את כל המאמר — רק שכאן היא מגיעה לרמת הארגון כולו.

Best Practices: איך לכתוב סקיל טוב

לא כל סקיל נולד שווה. תיאור מדויק הוא הכול — אם הסקיל מופעל על ידי המודל, התיאור הוא הטריגר; תיאור עמום יגרום לסקיל להיטען מדי הרבה או מדי מעט, ותיאור ספציפי עם מילות מפתח יגרום לו להישלף בדיוק בזמן. ספציפיות מנצחת כלליות: ״כתוב קוד נקי״ חסר ערך, אבל ״השתמש ב-named exports, קרא לקבצים ב-kebab-case, וכתוב טסט לכל פונקציה ציבורית״ מייצר תוצאה עקבית. פרקו לרכיבים — סקיל ענק שמנסה לעשות הכול קשה לתחזוקה, ועדיף כמה סקילים ממוקדים עם אחריות אחת ברורה. שמרו את הכבד בנפרד — אל תדחסו סקריפטים ארוכים או נתונים לתוך SKILL.md אלא הפנו אליהם מקבצים נפרדים, כך החשיפה ההדרגתית עובדת לטובתכם. ומעל הכול, התייחסו לסקיל כמו לקוד: בקרת גרסאות, code review ושיפור מתמשך. סקיל שנכתב פעם אחת ולא נגעו בו יתיישן; סקיל שמתוחזק ישתפר.

מדידה ושיפור: איך יודעים שסקיל באמת עובד

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

את הלולאה הזו אפשר לעשות ידנית, אבל יש כלי ייעודי: התוסף skill-creator מהמרקטפלייס הרשמי מאוטמט את כל התהליך. הוא שומר מקרי בדיקה ב-evals.json, מריץ כל מקרה בסוכן-משנה מבודד עם ספירת טוקנים וזמן, בודק כל טענה מול הפלט וכותב pass/fail ל-grading.json, ומסכם ל-benchmark.json את שיעור ההצלחה מול העלות — כך רואים אם השיפור בדיוק שווה את התוספת בטוקנים ובזמן. הוא אפילו מריץ השוואת A/B עיוורת בין שתי גרסאות של הסקיל, כדי לוודא שעריכה היא באמת שיפור לפני שמכניסים אותה ל-git. זה ההבדל בין "כתבתי סקיל ומקווה שהוא טוב" ל"מדדתי שהוא משפר".

מגבלות ומלכודות שכדאי להכיר

כמו כל כלי, גם לסקילים יש גבולות. הם לא קסם — סקיל הוא הוראות, ואם ההוראות עמומות גם התוצאה תהיה; סקיל לא הופך משימה לא מוגדרת למוגדרת, הוא רק מקבע הגדרה שכבר עשיתם. יש overhead של תחזוקה — ספרייה של עשרות סקילים דורשת תחזוקה, וסקיל שמפנה לקובץ שכבר לא קיים או שמשקף קונבנציה ישנה גרוע מאין סקיל, כי הוא מייצר תוצאה שנראית נכונה אבל אינה. יש סכנת טריגרים חופפים — אם שני סקילים מתארים את עצמם דומה מדי, המערכת עלולה לבחור את הלא נכון, ולכן תיאורים ברורים ומובחנים חשובים ככל שהספרייה גדלה. ולבסוף, סקיל אינו תחליף להבנה: סקיל שמריץ deploy מבלי שאף אחד מבין מה הוא עושה הוא סיכון, כי הכלי מאיץ ביצוע אך לא פוטר מאחריות להבין את התהליך. מלכודת ספציפית לתוכן: אם בונים סקיל שמייצר נתונים מובנים כמו FAQPage schema, חשוב שהסקיל יאכוף שהנתונים תואמים לתוכן הגלוי בפועל, אחרת נוצרת סכמה שמפרה את ההנחיות ועלולה לגרור עונש — נושא שהרחבנו עליו במדריך על נתונים מובנים ו-Schema Markup.

טעויות נפוצות שמאטות מתחילים — ואיך להימנע מהן

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

טעות שלישית נפוצה היא תיאור עמום בסקיל. אם הסקיל אמור להישלף אוטומטית על ידי המודל, התיאור הוא הטריגר היחיד — ותיאור כמו "עוזר עם קוד" יגרום לו להיטען בזמן הלא נכון או לא להיטען בכלל. תיאור טוב כולל את מילות המפתח המדויקות שבהן המשתמש ישתמש. טעות רביעית: לשכוח שההקשר מוגבל. מפתחים חדשים נוטים להשאיר שיחה אחת רצה שעות, עד שחלון ההקשר מתמלא והאיכות יורדת. הרגל בריא הוא להריץ /clear כשעוברים משימה, ו-/compact כשהשיחה ארוכה אבל עדיין רלוונטית. הטעות האחרונה, והמסוכנת ביותר, היא לתת לפקודה הרשאות רחבות מדי דרך allowed-tools בלי לחשוב. פקודה שמותר לה להריץ כל דבר בלי אישור נוחה — עד שהיא עושה משהו שלא התכוונתם. הכלל הפשוט: התירו אוטומטית רק פעולות קריאה בטוחות, והשאירו פעולות שמשנות מצב תחת אישור. זהירות קטנה בהגדרה חוסכת תקלה גדולה בהמשך.

שאלות נפוצות

מה ההבדל בין פקודה מותאמת לסקיל?

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

איפה שומרים פקודות וסקילים?

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

האם כל הסקילים נטענים לזיכרון בכל שיחה?

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

האם צריך לדעת לתכנת כדי לבנות סקיל?

לא בהכרח. סקיל בסיסי הוא קובץ Markdown עם הוראות בשפה טבעית. יכולת תכנות עוזרת כשרוצים לצרף סקריפטים או לוגיקה, אבל הרבה סקילים שימושיים הם טקסט בלבד. אפשר גם להיעזר בסקיל skill-creator המובנה שמלווה את הבנייה.

מה ההבדל בין סקיל ל-MCP?

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

האם אפשר לשתף סקילים בין צוותים?

כן. סקילים ופקודות ברמת הפרויקט משותפים דרך git, ו-Plugins מאפשרים לארוז יחד מערך שלם של פקודות, סקילים, hooks ושרתי MCP ולהפיץ אותו במכה אחת בין צוותים או בקהילה.

מתי לבחור פקודה ומתי סקיל?

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

האם סקילים עובדים גם בעברית?

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

מה ההבדל בין פקודה מובנית לפקודה מותאמת?

פקודה מובנית מגיעה מוכנה עם Claude Code ומריצה לוגיקה קבועה — למשל /clear שמנקה את ההקשר או /model שמחליף מודל. פקודה מותאמת אתם כותבים בעצמכם כקובץ Markdown בריפו. שתיהן מופעלות מאותו תפריט שנפתח בהקלדת לוכסן, זו לצד זו.

איך רואים את כל הפקודות הזמינות?

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

האם פקודות וסקילים זמינים גם ב-IDE ולא רק בטרמינל?

כן. Claude Code זמין כתוסף ל-VS Code ו-JetBrains, ואת האינטגרציה מגדירים עם /ide. הפקודות והסקילים שהגדרתם ברמת הפרויקט זמינים בכל מקום שבו הפרויקט נפתח — הם יושבים בריפו, לא בטרמינל ספציפי.

מה קורה אם פקודה מותאמת מתנגשת בשם עם פקודה מובנית?

עדיף פשוט להימנע — אל תקראו לפקודה שלכם בשם של פקודה מובנית כמו clear או model. אם יש הרבה פקודות, ארגנו אותן בתיקיות משנה שיוצרות מרחבי שם (למשל frontend:component), כך שהשמות נשארים ייחודיים וברורים גם כשהספרייה גדלה.

האם שינוי בקובץ פקודה נכנס לתוקף מיד?

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

האם סקיל נשאר בזיכרון לאורך כל השיחה?

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

איך גורמים לסקיל להיטען רק כשעובדים על סוג קובץ מסוים?

משתמשים בשדה paths ב-frontmatter עם תבנית glob. סקיל עם paths של *.tsx ייטען אוטומטית רק כשעובדים על קבצי React, וכך לא יעמיס את ההקשר בזמנים לא רלוונטיים.

האם סקילים עובדים גם מחוץ ל-Claude Code?

כן, חלקית. הסקילים בנויים על תקן פתוח (Agent Skills) שעובד בכמה כלי AI, כך שהמבנה הבסיסי ניתן להעברה. עם זאת, חלק מהיכולות הן הרחבות ייחודיות ל-Claude Code (כמו הזרקת הקשר דינמי), ולכן לא כל תכונה תעבוד בכל כלי.

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

תגיות: Claude Code · Agent Skills · Slash Commands · SKILL.md · MCP · Progressive Disclosure

← חזרה לבלוג · צור קשר