איך הופכים משימה חוזרת ל-Skill שעוזר ל-AI לעבוד בדרך שלכם

מתי כדאי ליצור אחד?

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

לפני הכתיבה, נסחו משפט אחד: "כשמבקשים ממני [משימה], קבל [קלט], בצע [שלבים], והחזר [תוצר]". אם קשה למלא את החסר, כדאי לחדד את התהליך. הגדירו גם גבולות: מה עושים כשחסר קובץ, אילו עובדות חייבים לבדוק, ואילו פעולות דורשות אישור. בתיעוד OpenAI מומלץ לכתוב Skill ממוקד סביב מטרה מזוהה, ולבדוק בקשות שצריכות להפעיל אותו לצד בקשות דומות שלא צריכות. המדריך הרשמי לבנייה ולבדיקה

איך יוצרים ומשתמשים ב-Skill ב-Codex?

הדרך הנוחה למתחילים היא לבקש מ-Codex ליצור Skill בעזרת $skill-creator, ולתאר את המשימה החוזרת. אפשר גם ליצור תיקייה וקובץ SKILL.md בעצמכם. זהו שלד פשוט לשימוש אישי, לדוגמה של ביקורת על עדכון פרויקט:

---
name: weekly-update-review
description: Review a weekly project update for missing decisions, owners and deadlines.
---

Use this skill when reviewing a draft weekly project update.

1. Read the draft and the source notes supplied by the user.
2. Read references/review-rules.md before checking the draft.
3. Mark claims that lack support in the supplied notes.
4. List open tasks with an owner and deadline when those details exist.
5. Use assets/update-template.md for the revised update.
6. Return the revised update and a short list of unanswered questions.

Do not invent decisions, owners or deadlines.

שימו לב לדוגמה: התיאור אומר מתי להפעיל את ה-Skill; ההוראות אומרות איך לעבוד; והמשפט האחרון מגדיר מה אסור להסיק. שלבים 2 ו-5 מחברים את הוראות הליבה לשני קבצים מהמבנה שהוצג למעלה. קובץ הסקריפט שבתרשים הוא אפשרות להרחבה עתידית; אין סיבה להוסיף שלב להרצתו כשאפשר להשלים את המשימה בעזרת הוראות וכלים קיימים. הנחיות OpenAI למבנה הקובץ ולקבצי העזר

בתיעוד העדכני, Codex טוען Skills מקומיים ממיקומי משתמש ומפרויקט, ובפרויקט הוא סורק תיקיות .agents/skills לאורך הנתיב עד שורש המאגר. אחר כך אפשר לבקש, למשל: "השתמש ב-$weekly-update-review כדי לבדוק את הטיוטה הזאת". ב-Codex CLI ובהרחבת סביבת הפיתוח אפשר גם לפתוח את רשימת ה-Skills באמצעות /skills; בממשקי ChatGPT בוחרים Skill באמצעות @. פרטי ההפעלה והמיקום עשויים להשתנות בין מוצרים וגרסאות, ולכן כדאי לבדוק את התיעוד של הסביבה שבה אתם עובדים. תיעוד OpenAI על הפעלה ומיקומי התקנה

מתי משתמשים בקובצי ייחוס ובמקורות חיצוניים?

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

לדוגמה, Skill לבדיקת עדכון פרויקט יכול להפנות ל-references/review-rules.md רק בשלב הביקורת. במסמך הזה אפשר לפרט מה נחשב החלטה, איך מסמנים משימה בלי בעלים ומתי צריך לבקש הבהרה. אם כל הבקשות מחייבות את אותם שלושה כללים קצרים, עדיף להשאיר אותם ב-SKILL.md; אם מדובר בעמודים של חומר רקע, ההפניה ממוקדת שומרת על הוראות הליבה קריאות.

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

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

כמה Skills וכמה סוכנים: איך הם משתלבים?

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

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

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

איך יודעים שהוא באמת עוזר?

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

ממה להימנע?

תיאור רחב מדי. אם Skill לבדיקת עדכוני פרויקט מוצג כמתאים לכל משימה ניהולית, הוא עלול להיבחר גם כשאין בו צורך. שם ותיאור מדויקים חוסכים התנגשויות עם Skills אחרים. כשמותקנים Skills רבים, Codex עשוי לקצר את התיאורים שמוצגים לו בתחילת העבודה; לכן כדאי להציב את תנאי ההפעלה החשובים בתחילת התיאור. תיעוד OpenAI על גילוי Skills

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

התקנה עיוורת של Skill זר. Skill עשוי לכלול הוראות וסקריפטים. לפני שמשתמשים בו, קראו את SKILL.md ואת הקבצים שהוא מפנה אליהם; בדקו מה הסקריפטים עושים, אילו נתונים הם קוראים, ולאילו שירותים הם ניגשים. Skill אינו מעניק הרשאה מעצמו, אבל הוראות לא אמינות עלולות לנסות לגרום לסוכן להשתמש בגישה שכבר קיימת. בתיעוד ה-API של OpenAI מוזכר במפורש סיכון של הזרקת הוראות והוצאת מידע דרך Skills. הנחיות האבטחה הרשמיות ל-Skills

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

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

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