איך לשתף כישורי סוכן בין מאגרי קוד בלי פערי גרסאות

איך לשתף כישורי סוכן בין מאגרי קוד

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

יש לכך ארבעה חלקים: מקור אמת משותף, גרסה נעולה לכל מאגר, בדיקת smoke לכל כישור, ונתיב בדיקה. בהמשך מוסבר מדוע כל חלק קיים, כיצד הכלים שיוצאים בשנת 2026 מתמודדים עם העניין, וכיצד לבנות את המערכת כולה ב־git remote באירוח עצמי, ללא מעורבות של שירות חיצוני.

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

היכן מיומנות נמצאת ומדוע קשה לשתף אותה

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

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

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

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

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

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

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

העתקה והדבקה עובדות ביום הראשון. ביום השישים הן נכשלות. מישהו מתקן הוראה שגויה במאגר payments, ואינו נוגע בשבעת האחרים. מישהו אחר מוסיף כלל בנוגע לעימוד במאגר orders. כעת אותו שם של skill מוביל לשני reviews שונים, בהתאם לתיקייה שממנה ה־agent הופעל, ואף אחד מהמפתחים אינו יודע זאת.

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

בעיה שנייה: שום דבר אינו מקבע גרסה

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

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

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

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

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

מה פותרים הכלים שיוצאים ב־2026

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

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

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

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

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

נוהלי ספקים. Google תיארה כיצד היא בונה את ה־skills ב־google/skills, בפוסט על האופן שבו היא בונה, בודקת ומגדילה את היקף השימוש ב־agent skills. אם מתעלמים מהיקף הפעילות, המנגנון הוא continuous integration (CI) רגיל. כל skill עובר linters שבודקים מטא־נתונים של frontmatter, מספר שורות, מבנה תיקיות ושמות, לפני שהשינוי ממוזג. כלי לבדיקת קישורים מכשיל את הבנייה בכל URL שמחזיר 404, וכך מזהה קישור שנראה סביר אך הומצא על ידי agent. המחברים חייבים לספק לצד ה־skill גם סדרת prompts להערכה וגם rubric לניקוד. משימות הערכה מתוזמנות רצות מדי שבוע מול הספרייה כולה כדי לזהות נסיגות באיכות, ולכל skill יש owner מוגדר שאמור לתקן אותו כאשר האיכות יורדת.

התבנית המשותפת לכל שלוש התשובות

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

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

זהו המבנה של dependency. Skills הפכו ל־artifact משותף מהר יותר מהתפתחותם של כלי הניהול סביבם, ולכן הכלים שאתם כבר סומכים עליהם הם הבחירה הבטוחה ביותר.

פריסה לצוות קטן מול remote של git באירוח עצמי

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

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

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

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

אם ה־remote שלכם הוא Gitea, Forgejo, GitLab או מאגר bare באמצעות SSH ב־VPS שבבעלותכם, שום דבר מההמשך אינו משתנה. כל מה שנדרש כאן הוא git וקישור סמלי.

הצמדה באמצעות תת־מודול של git

תת־מודול מתעד commit מדויק אחד של repository אחר בתוך ה־repository שלכם. הרשומה הזו היא ההצמדה. בכל פרויקט שמשתמש בו:

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 רגיל של הפרויקט, בעוד שהקבצים עצמם נמצאים בתת־המודול ב־commit שבחרתם.

בדקו את ההצמדה:

git submodule status

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

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

קידומת - מציינת שתת־המודול מעולם לא אותחל, ולכן .claude/skills/api-review מצביע על שום דבר וה־skill אינו נטען בשקט. תקנו זאת באמצעות git submodule update --init. קידומת + מציינת שה־commit שנשלף שונה מזה שתועד, ולכן אותו מפתח מריץ הוראות שאף אחד אחר אינו מריץ. ב־clone חדש צריך להפעיל 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 היא נתיב הבדיקה. היא מציגה את אותו שינוי שכל repository אחר שמשתמש ברכיב יראה, ומתאימה ל־pull request.

הצמדה באמצעות marketplace של תוספים במקום זאת

אם אינכם רוצים לבקש מכל מפתח ללמוד לעבוד עם submodules, מערכת התוספים של Claude Code מבצעת עבורכם את ההפצה, והיא פועלת מול remote באירוח עצמי. הציבו קטלוג ב־.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 הוא ההצמדה האפקטיבית. לכן ההצמדה ל־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 עבור skill אחד

smoke test הוא הרצה מתוסרטת של agent מול fixture עם תקלה ידועה, ובדיקה אחת. Claude Code פועל באופן לא־אינטראקטיבי עם -p, ו־skill שמופעל על ידי המשתמש פועל גם שם: הציבו את /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 הוא קובץ קצר עם תקלה מכוונת אחת. הבדיקה קובעת שה־skill מציין את התקלה. jq -e מסתיים בקוד שאינו אפס כאשר ה־filter שלו מפיק null, ולכן skill שמפסיק לזהות את התקלה שנשתלה יגרום לסקריפט להיכשל. claude עצמו מסתיים בקוד שאינו אפס כאשר ההרצה נכשלת, ו־set -euo pipefail הופך כל אחד מהכשלים האלה לבדיקה שנכשלה.

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

ב־CI הוסיפו --bare. בלעדיו, claude -p טוען את אותו הקשר שסשן אינטראקטיבי היה טוען, כולל hooks, plugins ו־CLAUDE.md מהמכונה שעליה הוא פועל. לכן תצורה אישית של חבר צוות עלולה לשנות את התוצאה. מצב bare מדלג על כל הגילוי האוטומטי. פירוש הדבר הוא שהוא מדלג גם על ה־skill שאתם בודקים, ולכן יש לטעון אותו במפורש. מצב 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, האירוע הראשון בהרצה מדווח אילו plugins נטענו, וכולל מערך plugin_errors עבור אלה שלא נטענו. הכשילו את משימת ה־CI כאשר plugin_errors אינו ריק. כך תזוהה הפניה ל־revision שאינו קיים עוד, מצב שאחרת נראה כאילו ה־agent מתעלם בשקט מכללי הארגון שלכם.

מיומנות משותפת היא הוראה הניתנת להרצה

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

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

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

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

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

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

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

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

• את ההבדלים של כל גוף SKILL.md, משום שזהו הטקסט שהסוכן שלך יבצע.
• כל החלפת פקודה, משום שהחלפות אלה מופעלות במחשב שלך בעת טעינת היכולת.
• כל שינוי ב־allowed-tools, משום ששורה זו מעניקה כלים ללא בקשת אישור.
• את הרצת הבדיקות שמאחורי התג. אם המאגר המשותף מריץ בדיקות smoke משלו ב־CI, לתג שאליו אתם מקבעים את הגרסה צריכה להיות הרצה מוצלחת מצורפת.

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

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

כמה דברים משתנים מתחת למיומנות בלי שאיש יערוך אותה. שדרוג מודל משנה את מידת האמינות שבה הוא ממלא אחר הוראה ארוכה, ולכן מיומנות שהסתמכה על כך שהמודל יגיע לשלב תשע עלולה להפסיק להגיע אליו. כלי שורת פקודה משנה את שמו של דגל, ולכן הסוכן מפעיל את הדגל הישן, קורא את השגיאה ומאלתר. כתובת URL שאליה יש הפניה מתחילה להחזיר 404. מעטפת סוכן משנה את אופן בחירת המיומנויות, ולכן description שבעבר זכה בהתאמה אינו זוכה בה עוד. כאשר הליך מתחיל להסתיים מוקדם באופן כזה, עדכון גרסה לא יפתור את הבעיה. ההוראות עצמן זקוקות למבנה שכופה ביצוע של השלבים האחרונים. זו הגישה שעליה מבוססת המיומנות unlazy ושיטת Depth Tree שלה.

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

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

FAQ

כיצד משתפים יכולת agent אחת בין כמה מאגרים?

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

האם אפשר לקבע יכולת agent לגרסה מסוימת?

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

מה צריך smoke test של יכולת לבדוק?

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

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

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

האם יכולת משותפת תפעל ב־agents שאינם Claude Code?

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