בניית Skill, שלב אחר שלב

מה צריך להכין לפני שמתחילים

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

שלוש דרכי בנייה והבחירה ביניהן

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

מהו קובץ MD

בדיוק כמו שיש קובץ Word, קובץ PDF וקובץ Excel, יש גם קובץ מסוג MD (קיצור של Markdown). זהו פשוט פורמט של קובץ טקסט, סיומתו .md, ואפשר לפתוח אותו בכל עורך טקסט פשוט במחשב, לרבות Notepad.

למה דווקא בפורמט הזה משתמשים לסקילים? משתי סיבות מעשיות:

• הוא קל יותר לבנייה ולקריאה עבור הבינה המלאכותית.
• הוא חסכוני יותר במשאבי עיבוד לעומת אותו תוכן בקובץ Word או PDF - כלומר עבודה מהירה וזולה יותר.

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

מהו SKILL.md

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

הקובץ בנוי משני חלקים, ממש כמו מסמך משפטי:

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

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

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

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

מהו YAML

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

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

בית משפט: השלום בתל אביב
מספר תיק: 12345-06-26
התובע: ישראל ישראלי

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

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

כך זה נראה בפועל בסקיל שלנו:

שני שדות הם חובה: name - מזהה טכני ולא כותרת: אותיות אנגליות קטנות בלבד, מקפים במקום רווחים, בלי עברית ובלי אותיות גדולות (למשל legal-chronology), עד 64 תווים, ואינו יכול להכיל את המילים anthropic או claude - שתיהן שמורות והשימוש בהן יפסול את הסקיל; ו-description - תיאור ברור של מה ה-Skill עושה ומתי להשתמש בו, עד 1024 תווים, אך מומלץ להישאר תמציתי. התיאור הוא רכיב מרכזי בהחלטה אם להפעיל את ה-Skill.

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

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

מבנה תיקיית סקיל

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

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

מאיפה מגיעים חומרי העזר

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

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

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

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

מקרה הבוחן: סקיל לבניית כרונולוגיה משפטית

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

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

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

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

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

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

פתיחת שיחת הבנייה

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

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

הכלי שתפקידו לבנות סקילים

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

כדי להפעיל אותו, פותחים את הבקשה במשפט מפורש:

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

שיטה שמשדרגת את התוצאה: בקשו שאלות מנחות

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

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

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

ראיון האפיון בשיחה

במקום לנחש מה אתם צריכים, המערכת שואלת שאלות ממוקדות כדי להבין את התהליך לעומק. בפועל, זה לא נראה כמו שיחה חופשית - המערכת מציגה לוח שאלות עם כפתורי בחירה מובנים, ממוספר ("1 of 3", "2 of 3" וכך הלאה), עם אפשרות "Something else" לתשובה חופשית או "Skip" לדילוג.

כך נראתה השאלה הראשונה במקרה הבוחן שלנו - איזה סוגי קבצים הסקיל צריך לקלוט:

1

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

השאלה השנייה עסקה בפורמט הפלט הרצוי:

1

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

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

1

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

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

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

יצירת הסקיל

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

1. האם השם (name) ברור, קריא וממוקד, ואינו עולה על 64 תווים
2. האם התיאור (description) מסביר גם מה הסקיל עושה וגם מתי להשתמש בו
3. האם ההוראות בגוף הקובץ תואמות בדיוק את מה שסוכם בראיון
4. האם רשומים בפירוש האיסורים שהוגדרו (למשל: לא להמציא תאריך)
5. האם מסומנות נקודות העצירה לאישור אנושי
6. האם יש בקובץ הנחיה להציג במפורש חוסר ודאות, ולא להסתיר אותו

לפני שהסקיל נארז לקובץ סופי, המערכת בדקה אותו על נתוני דוגמה - לא רק כתבה את ההוראות וסיימה:

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

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

1

1. 1כרטיס הסקיל המוכן - legal-chronology - עם כפתור "Save skill" להתקנה ישירה, וכפתור להורדת הקובץ.

ולחיצה על "Save skill" בפועל:

1

1. 1הודעת אישור - "Skill saved" - עם קישור Manage לניהול ישיר. הסקיל מותקן ופעיל מיד, בלי צעד נוסף.

ומיד לאחר מכן, ברשימת הסקילים (Customize ← Skills, כפי שנפגוש בפירוט במדריך 4), הסקיל החדש כבר שם - בראש הרשימה:

1

1. 1legal-chronology - הסקיל שבנינו הרגע, כבר מותקן ופעיל, לצד הסקילים שהיו קיימים מקודם.

אנטומיה של הסקיל המשפטי שיצרנו

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

1

1. 1"עקרון-העל: איסור המצאת תאריכים" - הכלל המרכזי מוצג ככותרת בולטת, לא קבור באמצע הטקסט. שימו לב לרמת הדיוק: המערכת חילקה את רמת הוודאות לארבע קטגוריות (exact, inferred, approximate, missing) במקום פשוט "ברור" מול "לא ברור".

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

חלק המטא-נתונים (השם והתיאור) נראה כך:

כשהסקיל גדל: ארגון לפי תחום

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

דוגמה מלאה: מקלט מבולגן לטבלה מסודרת

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

קלט (קטעים משלושה מסמכים שהועלו):

פלט מצופה (שורות מתוך טבלת הכרונולוגיה):

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

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

1

2

3

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

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

ביקורת לפני אריזה

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

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

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

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

אריזה ושמירת גרסה

כפי שראינו בפועל בפרק הקודם, כשבונים סקיל דרך שיחה במערכת התומכת בכך, אין צורך לארוז ידנית שום קובץ ZIP - המערכת עושה זאת ומציגה כפתור "Save skill" שמתקין את הסקיל ישירות בלחיצה אחת. אריזה ידנית לקובץ ZIP רלוונטית בעיקר כשמורידים סקיל ממקור חיצוני, או כשרוצים להעביר סקיל בין חשבונות (ראו מדריך 4). במקרה הזה, מבנה נכון הוא: תיקיית הסקיל עצמה היא שורש הקובץ - לא תת-תיקייה בתוך תיקייה נוספת - וה-SKILL.md נמצא ישירות בתוכה.

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

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

אותו עיקרון, תהליכים אחרים

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

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

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

נקודות פתיחה מוכנות

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

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

בדיקה מול המבנה הרשמי לפני האריזה

• תיקיית ה-Skill נקראת כמו ה-name שהוגדר.
• בתיקייה קיים קובץ SKILL.md.
• הקובץ מתחיל ב-YAML הכולל name ו-description.
• כל קובץ שמוזכר בהוראות קיים בנתיב הנכון.
• בנית ידנית בלבד: קובץ ה-ZIP מכיל את תיקיית ה-Skill כתיקיית השורש. בנית בשיחה? דלגו על הסעיף הזה, המערכת אורזת בעצמה.
• הבדיקה הראשונית מתבצעת על מידע מומצא.

מקור רשמי: Anthropic Help Center, How to create custom skills, יוני 2026.

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