שיתוף מיומנויות סוכן בין מאגרים ללא זליגת שינויים

כיצד לשתף מיומנויות סוכן (agent skills) בין מאגרים

כדי לשתף מיומנויות סוכן בין מאגרים, הפסיקו להעתיק את הקבצים והתחילו להסתמך עליהם כעל תלות (dependency). החזיקו מאגר מיומנויות אחד, תייגו אותו (tag), ואפשרו לכל פרויקט להצמיד (pin) גרסה ספציפית. לאחר מכן, הוסיפו בדיקת תקינות (smoke test) לכל מיומנות, ובצעו סקירה לכל עדכון גרסה באותו אופן שבו אתם סוקרים עדכון של ספריות חיצוניות.

התהליך מורכב מארבעה חלקים: מקור אמת אחד משותף, גרסה מוצמדת לכל מאגר, בדיקת תקינות לכל מיומנות, ומסלול סקירה. כל המפורט להלן מסביר מדוע כל חלק קיים, מה הכלים שיופצו ב-2026 עושים בנידון, וכיצד לבנות את המערכת כולה על גבי שרת git מרוחק בניהול עצמי (self-hosted), ללא תלות בשירותים חיצוניים.

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

היכן מיומנויות מאוחסנות, ומדוע שיתוף הוא משימה מורכבת

Claude Code טוען מיומנויות משלושה מקורות, ותיעוד המיומנויות מפרט כל נתיב.

• ~/.claude/skills/<skill-name>/SKILL.md הוא אישי. הוא נטען בכל הפרויקטים שלך ולא של אף אחד אחר.
• .claude/skills/<skill-name>/SKILL.md הוא ברמת הפרויקט. הוא נטען עבור כל מי שמושך את ה-repository הזה.
• <plugin>/skills/<skill-name>/SKILL.md מגיע בתוך תוסף. הוא נטען בכל מקום שבו התוסף מופעל.

האפשרות האמצעית היא השימושית ביותר עבור צוות, מכיוון שהיא נשמרת ב-commit וכל מי שמשכפל את ה-repo מקבל אותה. זהו גם המקום שבו מתחילות הבעיות. מיומנות ב-.claude/skills/ שייכת ל-repository אחד. יש לך שמונה כאלה. לכן, המיומנות מועתקת שמונה פעמים.

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

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

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

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

פעולת העתק-הדבק עובדת ביום הראשון. היא נכשלת ביום השישים. מישהו מתקן הוראה שגויה ב-payments repo ולא נוגע בשבעת האחרים. מישהו אחר מוסיף חוק לגבי עימוד (pagination) ב-orders. כעת, אותו שם של מיומנות מניב שתי ביקורות שונות בהתאם לספרייה שבה הסוכן הופעל, ואף אחד מהמפתחים אינו מודע לכך.

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

בעיה שנייה: היעדר קיבוע של גרסאות

גם כאשר צוות מרכז את המיומנויות (skills) במקום אחד, שיטת השיתוף המקובלת היא העתקה: סקריפט התקנה, שורת curl במסמך הקליטה, או alias ב-shell שמסנכרן תיקייה. כל אלו מתקינים את מה שנמצא בראש ה-branch ברגע נתון.

משמעות הדבר היא ששני מפתחים שעובדים על אותו commit של אותה אפליקציה עשויים להריץ הוראות שונות, כיוון שהם ביצעו את הסנכרון בימים שונים. המשמעות היא גם שלא ניתן לענות על השאלה הקריטית לאחר הרצה כושלת של סוכן: איזו גרסה של המיומנות יצרה את התוצאה הזו? ללא תיעוד של ה-revision, ההרצה אינה ניתנת לשחזור, ולכן לא ניתן לפעול לתיקון הדיווח על ה-bug.

בעיה שלישית: איש אינו יודע אם המיומנות עדיין עובדת

למיומנות (skill) אין מהדר (compiler). מדובר בהוראות המיועדות למודל, ולכן היא עלולה להפסיק לעבוד גם כאשר הקובץ נותר זהה לחלוטין ברמת הבייט. שדרוג של המודל משנה את רמת הדיוק שבה הוא עוקב אחר הוראות ארוכות. כלי שורת פקודה שהמיומנות מפעילה עשוי לשנות את שם ה־flag. כתובת URL בקובץ עזר עשויה להתחיל להחזיר שגיאת 404, והסוכן ימשיך לעבוד מתוך דף השגיאה.

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

מה פותרים הכלים ששוחררו בשנת 2026

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

קובצי Lock. כלי שורת הפקודה skills מבית Vercel Labs (‏vercel-labs/skills, ברישיון MIT, גרסה 1.5.22 נכון ל-5 באוגוסט 2026) מתקין מיומנויות (skills) ממאגר git לתוך הספרייה שהסוכן שלכם מצפה לה, והוא מכיר את המבנה של יותר משבעים סוכנים. npx skills add <repo> מתקין, npx skills update משדרג, ו-npx skills list מציג את מה שמותקן. התיעוד של מה שמותקן נשמר פעם אחת לכל משתמש במקום פעם אחת לכל מאגר, ובקשה פתוחה באותו פרויקט (issue 283) דורשת פקודת skills install שתתקין מחדש את כל המיומנויות המעוקבות מתוך קובץ ה-lock, כדי שמכונה שנייה תסתיים עם אותו סט. קראו את הבקשה הזו כדוח סטטוס. רעיון ה-lockfile הוכרע. החלק שנוגע לכל פרויקט עדיין נמצא בבנייה.

מפרטים ובדיקות. SkillSpec נוקט בגישה השנייה. הוא מתייחס ל-SKILL.md כאל חוזה לבדיקה ולא כאל טקסט שניתן לסמוך עליו, במטרה המוצהרת להפוך מיומנויות ל"ניתנות למעקב, לבדיקה ולהוכחה". skillspec doctor <path> מדווח היכן סוכן צפוי לנתק את השרשור. skillspec boundary map <path> מדווח למה המיומנות יכולה להגיע, ו-skillspec boundary assess <path> מדרג את הממצאים הללו לפי סיכון. זהו crate בשפת Rust, ברישיון כפול MIT או Apache 2.0, בגרסה 0.2.2 נכון ל-29 ביולי 2026. התקינו את הגרסה המקובעת (pinned) במקום את החדשה ביותר:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

--locked מבצע build עם גרסאות התלויות שבהן ה-crate פורסם, כך שה-build לא משתנה תחת ידיכם. skillspec --version אמור להדפיס 0.2.2. מספר שונה אומר שקובץ בינארי ישן יותר שנמצא מוקדם יותר ב-PATH שלכם הוא זה שרץ.

פרקטיקת Vendor. גוגל תיארה כיצד היא בונה את המיומנויות ב-google/skills בפוסט על אופן הבנייה, הבדיקה והסקייל של מיומנויות סוכנים. אם מסירים את הסקייל, המנגנון הוא אינטגרציה רציפה (CI) רגילה. כל מיומנות עוברת linters עבור מטא-דאטה של frontmatter, ספירת שורות, מבנה ספריות ושמות לפני המיזוג. בודק קישורים (link checker) גורם לכישלון ה-build בכל URL שמחזיר 404, מה שתופס קישור סביר שהסוכן המציא. מחברים חייבים לספק חבילת הנחיות הערכה (evaluation prompt suite) ומדריך ניקוד לצד המיומנות. משימות הערכה מתוזמנות רצות לאחר מכן מדי שבוע מול כל הספרייה כדי לתפוס רגרסיות, ולכל מיומנות יש בעלים מוגדר שצפוי לתקן אותה כאשר האיכות יורדת.

התבנית שמתחת לשלוש התשובות

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

1. מקור אמת יחיד. למיומנות יש בית אחד בלבד, וכל מאגר (repository) מפנה לבית הזה במקום להחזיק עותק.
2. גרסה נעולה לכל מאגר. כל פרויקט מתעד את ה-revision המדויק שבו הוא משתמש, כך ששדרוג הוא פשוט commit באותו פרויקט עם כותב ותאריך.
3. בדיקת תקינות (smoke test) לכל מיומנות. בדיקה אחת שניתן להריץ, המוכיחה שהמיומנות עדיין מפיקה את התוצאה המובטחת.
4. נתיב סקירה. שינוי במיומנות משותפת עובר סקירה, וכל צרכן רואה את ה-diff לפני שהוא מאמץ את השינוי.

זוהי התבנית של תלות (dependency). מיומנויות הפכו לארטיפקט משותף מהר יותר מכפי שהכלים סביבן התפתחו, לכן הכלים שאתם כבר סומכים עליהם הם האמצעי הבטוח ביותר לשימוש.

מבנה עבור צוות קטן בשרת Git מרוחק בניהול עצמי

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

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

גרסאות (releases) הן תגיות. השתמשו בתגיות עם הערות (annotated tags), כיוון שהן נושאות הודעה ותאריך; כתבו את ההודעה כסיבה שבגללה צרכן ירצה לשדרג את הגרסה:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

אם השרת המרוחק שלכם הוא Gitea, Forgejo, GitLab או מאגר חשוף (bare repository) מעל SSH ב-VPS שלכם, שום דבר מהבא להלן אינו משתנה. כל מה שמתואר כאן הוא git בתוספת קישור סימבולי (symlink).

קיבוע גרסה באמצעות git submodule

submodule מתעד commit ספציפי של מאגר אחר בתוך המאגר שלכם. תיעוד זה הוא הקיבוע (pin). בכל פרויקט צורך:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

ה־symlink הוא הרכיב שמאפשר זאת. רכיב skill ברמת הפרויקט יכול להיות symlink לספרייה אחרת בדיסק, ו-Claude Code עוקב אחריו וקורא את SKILL.md מהיעד. כך ה-skill נטען כ-skill רגיל של הפרויקט, בעוד שהקבצים עצמם נמצאים בתוך ה-submodule ב-commit שבחרתם.

בדיקת הקיבוע:

git submodule status

שורה תקינה מתחילה ברווח, לאחר מכן ה-commit, הנתיב, וה-tag הקרוב ביותר:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

סימן - בתחילת השורה מציין שה-submodule לא עבר אתחול, לכן .claude/skills/api-review מצביע לריק וה-skill לא נטען ללא הודעת שגיאה. תקנו זאת באמצעות git submodule update --init. סימן + בתחילת השורה מציין שה-commit הנוכחי שונה מזה שתועד, כלומר המפתח מריץ הוראות שאף אחד אחר לא מריץ. שכפולים (clones) חדשים דורשים git clone --recurse-submodules, ושורה זו צריכה להופיע ב-README, כיוון ש-clone רגיל משאיר את vendor/agent-skills ריק ולא מציג שגיאה.

שדרוג הוא פעולה מכוונת, וזו כל המטרה:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

השורה diff היא נתיב הסקירה. היא מציגה את אותו שינוי שכל מאגר צורך אחר יראה, והיא מתאימה להכללה ב-pull request.

הצמדת גרסאות באמצעות Marketplace של תוספים

אם אינכם מעוניינים לחייב כל מפתח ללמוד לעבוד עם submodules, מערכת התוספים של Claude Code מבצעת את ההפצה עבורכם, והיא פועלת מול שרת מרוחק בניהול עצמי. הציבו קטלוג בנתיב .claude-plugin/marketplace.json במאגר ה-skills:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

קיימים כאן שני מקורות שונים, ובלבול ביניהם הוא טעות נפוצה. המקור של ה-marketplace, כלומר המקום ממנו נמשך הקטלוג עצמו, מקבל ref עבור branch או tag ואינו מקבל sha. מקור של תוסף בתוך הקטלוג מקבל את שניהם, וכאשר שניהם מוגדרים, ה-sha הוא ה-pin הקובע. לכן, ה-pin המצביע על commit ספציפי שייך לרשומה בקטלוג.

כל מאגר צורך מצהיר על ה-marketplace בקובץ ה-.claude/settings.json המגובה ב-commit שלו:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

חבר צוות שנותן אמון בתיקיית הפרויקט יקבל הנחיה להתקין את ה-marketplace, והתוסף יופעל עבורו ללא צורך בדף wiki שינחה אותו לעשות זאת. ה-skills יגיבו לאחר מכן ל-/team-skills:api-review, כיוון ש-skills של תוספים נמצאים ב-namespace לפי שם התוסף ולא יכולים להתנגש עם skill של הפרויקט בעל שם זהה. לאחר שתדחפו tag חדש, הצרכנים ירעננו את המידע באמצעות /plugin marketplace update acme-agents, ולאחר מכן יריצו את /reload-plugins אם סיכום ההתקנה יבקש זאת.

כתיבת בדיקת עשן (smoke test) עבור מיומנות אחת

בדיקת עשן היא הרצה מתוסרטת של סוכן מול תשתית (fixture) בעלת תקלה ידועה, בצירוף טענה (assertion) אחת. Claude Code רץ ללא אינטראקציה עם -p, ומיומנות שמופעלת על ידי משתמש עובדת שם: הכניסו את /skill-name למחרוזת ה-prompt והיא תורחב לפני תחילת ההרצה.

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md הוא קובץ קצר עם תקלה מכוונת אחת. הטענה היא שהמיומנות תזהה ותציין את התקלה. jq -e מסיים את פעולתו עם קוד יציאה שאינו אפס כאשר המסנן שלו מפיק null, לכן מיומנות שמפסיקה לזהות את התקלה המוזרקת תגרום לכישלון התסריט. claude עצמו מסיים עם קוד יציאה שאינו אפס כאשר ההרצה נכשלת, ו-set -euo pipefail הופך כל אחד מהכישלונות הללו לבדיקה שנכשלה.

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

ב-CI, הוסיפו את --bare. בלעדיו, claude -p טוען את אותו הקשר שהיה נטען בסשן אינטראקטיבי, כולל hooks, תוספים ו-CLAUDE.md מהמכונה שעליה הוא רץ, כך שהגדרות אישיות של חבר צוות עלולות לשנות את התוצאה. מצב Bare מדלג על כל זיהוי אוטומטי, מה שאומר שהוא מדלג גם על המיומנות שאתם בודקים, לכן טענו אותה במפורש. מצב Bare גם אינו קורא את פרטי ההתחברות של המנוי שלכם, לכן הגדירו תחילה את ANTHROPIC_API_KEY בסביבת העבודה:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

עם --output-format stream-json, האירוע הראשון של ההרצה מדווח אילו תוספים נטענו ונושא מערך plugin_errors עבור אלו שלא נטענו. הכשילו את משימת ה-CI אם ה-plugin_errors אינו ריק. זה מזהה הפניה (pin) המכוונת לגרסה שכבר אינה קיימת, מה שעלול להיראות אחרת כסוכן שמתעלם בשקט מכללי הבית שלכם.

מיומנות משותפת היא הוראה בת-ביצוע

שני מאפיינים הופכים זאת למילולי, ושניהם חשובים כאשר הקובץ מגיע מצוות אחר.

ראשית, SKILL.md יכול להריץ פקודות shell לפני שהמודל קורא דבר מה. שורה כזו בגוף הטקסט היא עיבוד מקדים:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

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

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

לכן, יש להתייחס לעדכון מיומנות בדיוק כמו לעדכון תלות (dependency). יש לקבע (pin) לפי commit מדויק בכל מקום שהמנגנון מאפשר זאת, כיוון שניתן להזיז תגית (tag) וענף (branch) זז מעצם הגדרתו. במכונה מאובטחת, "disableSkillShellExecution": true בהגדרות מחליף כל החלפת פקודה בטקסט המילולי [shell command execution disabled by policy] במקום להריץ אותה, ויישום דרך הגדרות מנוהלות מונע מהמשתמש לעקוף זאת. מיומנויות ארוזות ומנוהלות פטורות מהגדרה זו.

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

מה לקרוא בעת עדכון גרסה

• את ה-diff של כל גוף SKILL.md, כיוון שטקסט זה הוא ההנחיה שהסוכן שלך יבצע.
• כל החלפת פקודה (command substitution), כיוון שאלו רצות על המכונה שלך בעת טעינת ה-skill.
• כל שינוי ב-allowed-tools, כיוון ששורה זו מעניקה הרשאות לכלים ללא בקשת אישור.
• את הרצת הבדיקה שמאחורי ה-tag. אם המאגר המשותף מריץ בדיקות תקינות (smoke tests) ב-CI, ה-tag שאליו אתה מבצע pinning צריך להיות מקושר להרצה תקינה (green run).

סוקר שאינו יכול לקרוא את כל ה-diff בתוך עשר דקות בוחן skill שגדל יתר על המידה. פצל אותו. אותו טיעון תקף למסמכי המאגר שהסוכנים שלך קוראים: שמור כללים קבועים בקבצים המתוארים ב-פיצול בין AGENTS.md ל-HUMAN.md ושיקולים ארכיטקטוניים ב-קובץ DESIGN.md שנכתב עבור סוכנים, והשאר את ה-skills כנהלים ממוקדים.

כאשר שינוי במודל או בכלי משבש מיומנות

דברים רבים משתנים "מתחת למכסה המנוע" של מיומנות מבלי שאיש יערך אותה. שדרוג מודל משנה את רמת האמינות שבה מבוצעת הוראה ארוכה, ולכן מיומנות שהסתמכה על כך שהמודל יגיע לשלב תשע עלולה להפסיק להגיע אליו. כלי שורת פקודה משנה שם של flag, ולכן ה-agent מריץ את ה-flag הישן, קורא את השגיאה ומאלתר. כתובת URL שנעשה בה שימוש מתחילה להחזיר שגיאת 404. מנגנון ה-harness של ה-agent משנה את האופן שבו הוא בוחר מיומנויות, כך ש-description שנהג לנצח בהתאמה אינו עושה זאת עוד.

זו הסיבה לכך שבמערך הזה יש חשיבות מכרעת ל-smoke test. הריצו את הבדיקה של כל מיומנות לפי לוח זמנים וגם בעת ביצוע push. מסיבה זו, Google מריצה את משימות ההערכה שלה מדי שבוע על כל הספרייה, ו-cron job שבועי על גבי VPS קטן מספיק לצוות עם עשר מיומנויות. זו הדרך היחידה לגלות על תקלה לפני שהמפתח מגלה זאת.

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

FAQ

כיצד ניתן לשתף מיומנות סוכן (agent skill) אחת בין כמה מאגרים?

יש להציב את המיומנות במאגר git ייעודי, לתייג גרסאות (releases) בתוכו, ולגרום לכל פרויקט צורך להפנות לתגית במקום להעתיק את הקובץ. קיימים שני מנגנונים יעילים לכך. git submodule מתעד commit מדויק, וקישור סימבולי (symlink) מתוך .claude/skills/<name> אל תוך ה-submodule יגרום לו להיטען כמיומנות רגילה של הפרויקט. שוק תוספים (plugin marketplace) מבצע את אותה עבודה דרך /plugin, כאשר הקיבוע (pin) מוצהר בתוך .claude/settings.json של המאגר הצורך. שתי השיטות מתעדות את הגרסה בהיסטוריית ה-git, כך שניתן לדעת אילו הוראות הפיקו הרצה מסוימת של סוכן.

האם ניתן לקבע (pin) מיומנות סוכן לגרסה ספציפית?

לא מתוך SKILL.md, כיוון של-frontmatter הזה אין מפתח version. הקיבוע חייב להגיע מהשכבה שעוטפת את הקובץ. git submodule מקבע commit מדויק מעצם הגדרתו. בשוק התוספים של Claude Code, מקור תוסף מקבל ref עבור ענף (branch) או תגית, ו-sha עבור commit מדויק, כאשר ה-sha גובר אם שניהם נוכחים. מקור השוק עצמו מקבל ref בלבד. העדיפו קיבוע ל-commit, כיוון שניתן להזיז תגית לאחר שכבר סקרתם אותה.

מה צריכה בדיקת עשן (smoke test) למיומנות לאמת?

אמתו מול משהו יציב. הריצו את המיומנות באופן לא אינטראקטיבי מול fixture המכיל תקלה ידועה, ולאחר מכן בדקו שזהה ספציפי מופיע בפלט, למשל מזהה חוק (rule id) שהמיומנות אמורה לדווח עליו. בקשת פלט מובנה עם --output-format json ו---json-schema הופכת את הבדיקה למדויקת, ו-jq -e גורם לסקריפט להיכשל כאשר הערך חסר. לעולם אל תבצעו אימות על משפט מלא, כיוון שמודל עשוי לשנות את ניסוח תשובותיו בין הרצות.

האם בטוח להתקין מיומנות משותפת ממאגר של צוות אחר?

התייחסו לכך כאל תלות קוד (code dependency), כיוון שמדובר בהוראות בנות-ביצוע. SKILL.md יכול להריץ פקודות shell בזמן הטעינה דרך צורת החלפת הפקודה !, והשדה allowed-tools ב-frontmatter יכול לאשר מראש כלים ללא בקשת אישור. קראו את ה-diff בכל עדכון גרסה, קבעו ל-commit מדויק במקום לענף, והעדיפו מקור שהצוות שלכם שולט בו. במכונות מנוהלות, "disableSkillShellExecution": true בהגדרות עוצר הרצת החלפות פקודה לחלוטין.

האם מיומנות משותפת תעבוד בסוכנים אחרים מלבד Claude Code?

זה תלוי ב-frontmatter שבו אתם משתמשים. מפרט ה-Agent Skills מגדיר שישה מפתחות: name, description, license, compatibility, metadata ו-allowed-tools. מיומנות המוגבלת למפתחות אלו תיטען בכלים המממשים את המפרט, והיא תיטען גם ב-Claude Code ללא שינויים. מפתחות ספציפיים לתשתית ותכונות גוף (body) החורגות מהמפרט יתעלמו או יידחו במקומות אחרים, לכן הימנעו מהם בכל מיומנות שאתם מתכננים לשתף באופן נרחב.