רשימת תיוג של 10 דקות לפני שיתוף

10 טעויות הכתיבה הנפוצות ביותר

1. תיאור עמום מדי. "סקיל לדברים ישראליים" מנותב גרוע. תשתמשו בדפוס "Use when X, Y, Z. Do NOT use for A, B".
2. אין סעיף "Do NOT use for". בלעדיו ה־LLM טוען את הסקיל שלכם בקונטקסט שגוי ומפיק תשובה שגויה בביטחון.
3. קלקות בעברית ב־display_description או ב־SKILL_HE.md. "שכבת האסטרטגיה", "שתי שאלות עוגן", סדר מילים מילולי מאנגלית. קורא ישראלי ילידי מזהה את זה ב־5 שניות.
4. ספי קצבה מומצאים, מספרי טפסים מומצאים, או ציטוטי חוק מומצאים. מדרגות מס שגויות ל־2026. מספרי טפסים שגויים של ביטוח לאומי. המבקר מצליב מול מקורות ראשוניים. המצאות נדחות חזק.
5. slug שלא תואם לשם התיקייה. צינור ה־sync מרים את שם התיקייה. metadata.name חייב להיות זהה בדיוק.
6. אין דוגמת עבודה בגוף. בלי דוגמאות, ה־LLM ממציא edge cases.
7. הפניות לקבצים ב־references/ או scripts/ שלא קיימים. ולידטור מקומי תופס את זה. תריצו אותו.
8. slug שגוי ב־supported_agents. claude במקום claude-code, gemini במקום gemini-cli. מציג עיגולים אפורים ריקים בכרטיס.
9. קווי em dash במקום כלשהו ב־SKILL.md, ב־SKILL_HE.md, או ב־metadata.json. קונבנציית הפרויקט היא בלי em dashes, נקודה. תשתמשו בפסיקים, סוגריים, נקודתיים.
10. שכחתם להקפיץ גרסה ב־metadata.json אחרי עריכות. ה־sync דורס את התוכן בשקט, אבל מחוון הגרסה של הקטלוג נשאר ישן וזרימת ה־admin של update-skill לא מקבלת למי להפיץ אצל העוקבים.

רשימת התיוג של 10 דקות לפני שיתוף (מילולי)

תריצו אותן בסדר. כל אחת היא פקודת shell אחת או קריאה של 30 שניות.

1. תעשו grep לשלושת הקבצים בחיפוש תו ה־em dash (U+2014). הפלט חייב להיות ריק.
2. jq -r '.name' metadata.json ותאמתו שזה שווה ל־basename "$(pwd)".
3. תקראו את ה־description שלכם בקול. הוא עונה על "מתי ה־LLM צריך לטעון את זה?" במשפט אחד? יש בו סעיף "Do NOT use for"?
4. תקראו את SKILL_HE.md בקול (או תנו לדובר עברית ילידי לקרוא). זה נקרא כמו עברית, או כמו אנגלית מתורגמת?
5. תבחרו מספר אחד, אחוז, או סכום בשקלים בגוף שלכם. תפתחו את המקור הראשוני שלו. תוודאו שזה תואם.
6. תבחרו את הפרק עם הכי הרבה לוגיקת החלטה. תמצאו את דוגמת העבודה. תגזרו אותה מחדש על נייר כדי לוודא שהמתמטיקה נכונה.
7. תעשו רשימה של הקבצים ב־references/ וב־scripts/. לכל אחד, תעשו grep ב־SKILL.md כדי לוודא שיש אליו הפניה.
8. אם אתם מפרסמים לקטלוג עם תצוגה מקדימה רנדרית, פתחו את סביבת ה־dev של הקטלוג (או staging) ותוודאו שהכל נראה נכון, כולל אייקוני סוכנים נתמכים או לוגואים של פלטפורמות.
9. תקפיצו גרסה (ב־frontmatter, ב־metadata.json, או ב־git tag, איפה שאתם עוקבים).
10. אם בערוץ ההפצה שלכם רץ סקריפט ולידציה, תריצו אותו מקומית פעם אחרונה לפני push.

אם כל ה־10 עוברים, שתפו. אם משהו נופל, תתקנו מקומית קודם.

המבחן "האם תשובת הברירת מחדל של הצ'אטבוט הייתה יותר טובה?"

השאלה הכי חשובה ששואלים לפני שיתוף: האם המשתמש היה יותר טוב בלי הסקיל שלכם, וקיבל את תשובת ברירת המחדל של ה־LLM?

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

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

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

מתי לשלוח סקיל ומתי MCP server

מסגור לסיום: אם ה"סקיל" שלכם הוא באמת "תגיד ל־LLM איך לקרוא ל־API הזה ולפרסר את התשובה", אל תכתבו סקיל. תכתבו MCP server. שרתי MCP מטפלים יותר טוב ב־state חי, קל יותר להחזיק אותם מעודכנים, ומשתלבים באופן טבעי עם סקילים שמטפלים בקבלת ההחלטות.

חלוקה נקייה:

• סקיל: איך לפרש את התשובה משרת MCP. מה לעשות עם הנתונים. חוקי ההחלטה.
• MCP server: איך להביא את הנתונים. החוזה של ה־API. ה־state הנוכחי.

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

איפה למצוא סקילים לדוגמה ללמוד מהם

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

אם יש לכם גישה לקטלוג skills-il (https://agentskills.co.il/skills?sort=installs), שלוש דוגמאות פתיחה לפי מורכבות:

• הכי קטן: מפרמט טלפון ישראלי (israeli-phone-formatter), פורמטר ממוקד וצמוד
• קטן עם scripts/: מאמת תעודת זהות (israeli-id-validator), מוסיף אלגוריתם ספרת ביקורת דטרמיניסטי
• בינוני עם references/: ערכת SEO ו־GEO בעברית (hebrew-seo-geo-toolkit), דו־לשוני עם הרבה סקשנים ושימוש אמיתי ב־references/

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