המדריך לבניית סקילים שבודקים את עצמם

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

סקיל הוא תיקייה, לא קובץ

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

סקיל טוב אינו רק קובץ הוראות

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

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

על התשתית הזאת בנויה החלוקה של אנטרופיק.

תשע קטגוריות, רעיון אחד שימושי

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

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

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

ארבעה כללים שקובעים אם סקיל בכלל יופעל

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

הטריגר עוזר למודל לדעת מתי להפעיל אותו

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

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

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

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

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

איך מתרגמים את זה לעבודה יומיומית

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

ארבעה סוגים: עושים, מעצבים, כללים ובודקים

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

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

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

הבודקים

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

האם מתקיימים תנאים שאפשר לאמת

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

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

קרא את המסמך המאושר המצורף.

נתח אותו וזהה מה בדיוק הופך אותו לתקין: מבנה, שדות חובה, טון, נתונים.

כתוב לי צ'קליסט של חמש עד שמונה בדיקות.

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

בסיום הוסף את הצ'קליסט בתחתית הסקיל הקיים שלי כהוראה.

לאחר מכן מוסיפים לסקיל העושה (doer) את ההוראות הבאות:

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

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

הכללים

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

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

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

ראיין אותי כדי לחלץ את הכללים שקיימים רק בראש שלי
לגבי המשימה: [תיאור המשימה].

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

בסוף סכם את כל ה״מלכודות״ שעלו, שורה אחת לכל כלל,
והוסף אותן בתחתית הסקיל הקיים.

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

מתי כלל צריך להפוך לסקיל נפרד

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

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

כלל שחוזר בכמה תהליכים כבר צריך מקור אמת משלו

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

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

1. העבר אותם לסקיל חדש בשם: [שם]
2. כתוב לו תיאור שמציין בדיוק מתי יש להשתמש בו, במילים
   שמשתמש באמת יקליד.
3. עדכן את הסקילים [רשימה]: הסר מהם את הכללים הישנים,
   והחלף בשורה אחת שמפנה לסקיל החדש לפני כל פעולה רלוונטית.

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

איפה הבדיקה עדיין חלשה

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

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

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

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

אימות חזק באמת נשען על מקור חיצוני למדידה

איך מתחילים?

פתחו את רשימת הסקילים שלכם ותספרו כמה מהם עושים (doers), כמה מהם מעצבים (Formatters) וכמה מהם בודקים (Checkers). אם בחלק השלישי התשובה היא אפס, אתם כנראה במצב של רוב המשתמשים. כדי להתחיל, בחרו סקיל אחד שכבר עובד אבל עדיין דורש מעבר ידני, והורידו את תיקיית skill-hardening שבנינו עבורכם ומיועדת לשימוש חופשי.

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

כך בנויה תיקיית skill-hardening

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