שיתוף הסקיל שלכם

תרחיש א': סקיל פרטי, מקומי בלבד

השימוש הפשוט ביותר: להשאיר את הסקיל על המכונה שלכם. רוב הסביבות שתומכות בפורמט נותנות להתקין סקיל מתיקייה מקומית. למשל ב־Claude Code:

claude skill install /path/to/your-skill-folder

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

תרחיש ב': שיתוף עם צוות או חבר

אתם רוצים שעמית ישתמש בסקיל שלכם. שני דפוסים נפוצים:

1. דחיסת התיקייה ושליחתה. ארזו את תיקיית הסקיל ב־ZIP (zip -r my-skill.zip my-skill/), שלחו ב־Slack / מייל / Drive. המקבל חייב לחלץ את ה־ZIP קודם ולא להתקין מהקובץ הדחוס ישירות. רוב הסביבות (כולל Claude Code) מתקינות מנתיב לתיקייה רגילה, לא מקובץ ZIP. אחרי החילוץ הוא מריץ claude skill install /path/to/extracted/my-skill. תוודאו שהתיקייה המחולצת מכילה את SKILL.md בשורש שלה ולא נמצאת קומה אחת מתחת (חלק מכלי החילוץ עוטפים את התוכן בתיקייה נוספת בשם הארכיון).
2. Push ל־repo פרטי ב־git. הוא מבצע clone, ומתקין מה־clone המקומי עם אותה פקודה. קל יותר להישאר מסונכרנים תוך כדי איטרציה (git pull + התקנה מחדש מושך את השינויים שלכם). עובד טוב לצוות.

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

תרחיש ג': קטלוג פנים־ארגוני

אם לצוות או לחברה שלכם יש קטלוג פנימי משותף (דירקטוריה פנימית של סקילים שהמהנדסים יכולים להתקין ממנה), עברו את תהליך התרומה של הארגון שלכם. דפוסים נפוצים: PRs ל־monorepo פנימי ב־git, registry פרטי של npm, או סקריפט התקנה פנימי מותאם. תוכן הסקיל לא משתנה. רק מנגנון ההפצה שונה.

תרחיש ד': פרסום לקטלוג ציבורי

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

• ה־registry של Anthropic לסקילים (כשיהיה זמין באופן כללי), המקום הקנוני לסקילים לשימוש כללי.
• קטלוגים קהילתיים ספציפיים לנושא. הקטלוג בקונטקסט הישראלי agentskills.co.il מקבל הגשות קהילתיות לסקילים רלוונטיים למשתמשים ישראלים (עברית, APIs ישראליים, חוק ישראלי). קיימים קטלוגים קהילתיים אחרים לנישות אחרות.

תהליך התרומה משתנה בין קטלוגים. רוב הקטלוגים הציבוריים מבקשים: את תיקיית SKILL.md, תיאור של מה הסקיל עושה, וצורה כלשהי של ביקורת (lint אוטומטי + אישור אנושי). קטלוגים ששולחים תוכן דו־לשוני מבקשים קובץ ליווי לכל שפה ו־metadata.json sidecar עם נתוני תצוגה ספציפיים לקטלוג. קראו את מדריך התרומה של הקטלוג לפני שאתם מגישים.

רשימת ולידציה לפני שיתוף

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

• ל־YAML frontmatter יש name, description, ו־license. אין מפתחות מקוננים נוספים
• השדה name שווה לשם הבסיס של התיקייה
• כל קובץ שאתם מפנים אליו מ־SKILL.md ב־references/ או scripts/ באמת קיים בתיקייה
• לתיאור יש דפוס ברור "Use when..." וגם סעיף "Do NOT use for..."
• אם יש לכם כמה גרסאות שפה או metadata.json sidecar, הם עקביים פנימית (ה־slugs תואמים, אין תרגומים חסרים)
• תריצו את הסקיל בעצמכם בסשן Claude Code טרי ותוודאו שהוא נטען ומתנהג כצפוי

גרסאות ומעקב שינויים

כשאתם מעדכנים את הסקיל, תקפיצו גרסה איפשהו (או שדה version ב־frontmatter, או ב־metadata.json אם יש לכם, או tag ב־git). semver עובד טוב: patch (0.0.X) לתיקונים, minor (0.X.0) לתוספות, major (X.0.0) לשינויים שוברים או הזזות scope.

לקטלוגים ציבוריים, הקטלוג בדרך כלל יטפל בהפצת ה־changelog לעוקבים של הסקיל שלכם. לסקילים פרטיים או של צוות, מספיק להחזיק CHANGELOG.md פשוט ליד SKILL.md.

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

המפרט לא מגדיר מנגנון update אוטומטי, אז אספקת העדכונים תלויה בסביבה. התקנה מקומית מתיקייה דורשת מהמשתמש להריץ מחדש claude skill install /path/to/folder אחרי git pull או אחרי חילוץ ZIP חדש. התקנה מקטלוג ציבורי (למשל npx skills-il add ...) דורשת הרצה מחדש של פקודת ההתקנה כדי לקבל את הגרסה האחרונה. חלק מהקטלוגים שולחים התראה לעוקבים כשסקיל שהם התקינו מקפיץ גרסה. monorepo פנים־ארגוני בדרך כלל מתכנס על סקריפט קצר git pull && reinstall שרץ על לוח זמנים.

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

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