איך בונים Skill שעובד ב-ChatGPT? המדריך המלא שיהפוך הוראות כלליות לנוהל עבודה

עד לא מזמן, המונח סקיל (Skill) היה מזוהה בעיקר עם Claude של אנטרופיק (Anthropic). החברה הציגה את Agent Skills באוקטובר 2025, ובהמשך פרסמה את הפורמט כתקן פתוח שנועד לאפשר שימוש גם מחוץ לסביבת אנטרופיק. מאז, הסקילים באמת יצאו מגבולות Claude והפכו לאחד הנושאים המדוברים בעולם הבינה המלאכותית. גם OpenAI אימצה את התקן וכיום מציגה סקילים כדרך להרחיב את היכולות של ChatGPT ו-Codex באמצעות תהליכי עבודה שאפשר להפעיל שוב ושוב. ככל שהמונח נעשה נפוץ יותר, כך גם קל יותר לבלבל בינו לבין פרומפט ארוך ששומרים לשימוש חוזר. בניית סקיל יכולה להיראות כמו פעולה טכנית קטנה: כותבים כמה הוראות, מצרפים דוגמה או שתיים ומקווים שבפעם הבאה ה-AI יעבוד בדיוק כמו שרצינו. בפועל, זה בדרך כלל לא מספיק.

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס קלוד קוד (Claude code) וסביבת אנטרופיק

לפרטים נוספים לחצו כאן >>

מה יש בתוך Skill?

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

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

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

התחילו ממטרה אחת ברורה

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

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

התיאור הוא שער הכניסה

התיאור של הסקיל הוא לא טקסט שיווקי. השם והתיאור הם האותות המרכזיים שעוזרים למערכת להחליט אם הסקיל מתאים לבקשה. רק לאחר הבחירה בו, המערכת טוענת את ההוראות המלאות. תיאור כמו “עוזר בכתיבה” כמעט לא אומר כלום. כתיבה של מה? עבור מי? בעברית או באנגלית? האם מדובר בשכתוב, עריכה, כתיבה מאפס או בדיקת עובדות?

השם והתיאור עוזרים למערכת להחליט אם הסקיל מתאים לבקשה

תיאור טוב יהיה למשל: “עורך מאמרים וסקירות טכנולוגיות בעברית לקהל לא טכני. יש להשתמש בו כאשר המשתמש מבקש לכתוב, לשכתב, לפשט או לבדוק כתבה על AI וטכנולוגיה”.

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

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

כתבו תהליך, לא רשימת משאלות

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

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

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

התאימו את רמת הפירוט למשימה

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

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

משימה רגישה לטעויות דורשת תהליך מדויק, גבולות ובדיקות

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

הגדירו תוצאה שאפשר לבדוק

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

במקום “כתבה טובה”, אפשר לבקש ״כתבה באורך 700 עד 900 מילים, בעברית פשוטה לקהל לא טכני, עם כותרת ראשית, כותרות משנה, הסבר קצר לכל מונח מקצועי, בלי להוסיף עובדות שלא הופיעו במקורות, ועם בדיקת דיוק בסוף״.

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

הסבירו את ההיגיון רק כשזה עוזר

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

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

קבעו מתי שואלים ומתי ממשיכים

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

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

תנו גבולות, אבל אל תהפכו אותם לגדר אינסופית

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

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

השתמשו בקבצים נלווים רק כשיש להם תפקיד

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

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

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

הוסיפו בדיקה עצמית עם קריטריונים ברורים

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

איך מתחילים בפועל?

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

ב-Codex CLI או בתוסף של Codex לסביבת הפיתוח אפשר לפתוח את רשימת ה-Skills באמצעות skills/, או להקליד $ ולבחור ב-Skill Creator. הקלדת skill-creator@ או skill-creator$ כטקסט רגיל לא תעבוד בכל ממשק.

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

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

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

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

בדקו את ה-Skill מול בקשות אמיתיות

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

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

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

שמרו על הוראות שיחזיקו לאורך זמן

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

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

חמשת המרכיבים שהופכים Skill לנוהל עבודה ברור

המבנה הפשוט של Skill טוב

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

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