Skills — יכולות ארוזות מראש
Skill: מעבר לכלי בודד
בפרק המבוא לנושא הוצג Skill בקצרה כ"מתכון" מוכן למשימה שלמה. עכשיו אפשר להיות מדויקים יותר: skill הוא חבילת הוראות עבודה שמורה מראש למשימה מסוג ידוע — לא פעולה בודדת כמו tool, אלא תהליך שלם, כולל השלבים, הסדר שלהם, והכללים שצריך לעקוב אחריהם כדי לבצע אותו נכון.
ההבדל המהותי מ-tool: tool עונה על "מה אפשר לעשות" (קרוא קובץ, שלח בקשת רשת), בעוד skill עונה על "איך עושים דבר שלם נכון" — ולעיתים קרובות משתמש בכמה tools שונים ברצף מסוים כדי להשיג את זה, בדיוק כפי שגם אדם שממלא נוהל עבודה כתוב משתמש בכמה כלים בדרך.
איך המודל בוחר להפעיל Skill
כל skill זמין מגיע עם תיאור קצר של מה הוא עושה ומתי מתאים להשתמש בו — בדיוק כמו description של tool. כשמגיעה משימה חדשה, המודל משווה אותה מול תיאורי ה-skills הזמינים, ואם הוא מזהה התאמה טובה, הוא בוחר להפעיל את ה-skill הרלוונטי במקום להמציא תהליך אד-הוק בעצמו מאפס.
ברגע שה-skill מופעל, ההוראות המלאות שלו נטענות לתוך הקונטקסט של המודל — כעת יש לו "נוהל עבודה" מפורט לעקוב אחריו, לא רק תיאור קצר. זה שונה מ-subagent (שראינו בפרק 3): skill הוא תוכן/הוראות שנטענות לתוך אותה לולאה, ולא בהכרח לולאה אגנטית נפרדה משלו — אם כי לעיתים skill מפעיל בעצמו subagent כחלק מהתהליך שלו.
מה יש בתוך Skill בפועל
skill טיפוסי מכיל לפחות הוראות טקסטואליות מפורטות — תיאור השלבים, הכללים והמלכודות הנפוצות למשימה הספציפית. הרבה פעמים הוא מגיע גם עם קלט/פלט צפויים (מה מצפים לקבל כפרמטרים, ומה הפלט הסביר בסיום), ולפעמים אף עם סקריפטים או כלי-עזר משלו, ייעודיים למשימה הזו בלבד ולא רלוונטיים מחוץ לה.
ההבדל בין skill טוב לבין תיאור כללי מדי הוא ברמת הפירוט: skill טוב כולל דוגמאות קונקרטיות, מקרי קצה ידועים, וסדר פעולות ברור — כך שהתוצאה עקבית בכל פעם שהוא מופעל, ולא תלויה בכל פעם מחדש באיך המודל "מרגיש" לגשת למשימה.
דוגמה: אותה משימה עם ובלי Skill
משימה: "תבצע code review לקובץ הזה". בלי skill, המודל יגיע לזה אד-הוק — יקרא את הקובץ, יחליט בעצמו על אילו היבטים להסתכל (סגנון? באגים? אבטחה?), ובלי מבנה קבוע לתוצאה. פעמיים שיבקשו ממנו לעשות אותו דבר, הוא עלול להתמקד בהיבטים שונים בכל פעם.
עם skill מוגדר ל-code review: ההוראות כבר מפרטות בדיוק אילו קטגוריות לבדוק (נכונות, אבטחה, ביצועים, קריאות), באיזה סדר, ובאיזה פורמט להציג ממצאים — כך שהתוצאה עקבית ומקיפה בכל הפעלה, בלי תלות בזיכרון או בשיקול דעת אד-הוק של המודל באותו רגע.
{
"type": "skill_invocation",
"name": "code-review",
"matched_because": "הבקשה תואמת את תיאור ה-skill: 'סקירת קוד לפי רשימת קטגוריות קבועה'",
"input": {
"file": "src/cart.ts"
}
}
מתי כדאי לבנות Skill, ומתי כלי גולמי מספיק
skill משתלם כשמדובר במשימה חוזרת מסוג ידוע, עם תהליך שרוצים שיהיה עקבי בכל פעם (code review, כתיבת דוח שבועי בפורמט קבוע, תהליך פריסה) — ההשקעה בכתיבת ההוראות פעם אחת חוסכת "המצאת גלגל" מחדש בכל הפעלה, ומבטיחה תוצאה אחידה.
לעומת זאת, למשימה חד-פעמית או פשוטה מספיק גישה ישירה לכלים בלבד — בניית skill למשהו שקורה פעם אחת בלבד היא השקעה שלא מחזירה את עצמה. ככלל אצבע: אם היית כותב לעצמך נוהל עבודה כתוב למשימה הזו כי אתה חוזר עליה שוב ושוב, כנראה שגם למודל כדאי skill.