להתקין, לבדוק, לשפר ולהחזיק במשרד

התקנת סקיל שהכנו

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

1. בעמוד Customize > Skills, לחצו על כפתור Add בפינה הימנית העליונה
2. מתוך שלוש האפשרויות שנפתחות (Create with Claude, Write skill instructions, Upload a skill) - בחרו Upload a skill
3. בחרו את קובץ ה-ZIP מהמחשב
4. המתינו לעיבוד - הסקיל יופיע ברשימה עם המתג שלו
5. ודאו שהמתג דולק כדי שהסקיל יהיה זמין לשימוש

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

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

1

1. 1לחיצה על שורת הסקיל (כאן legal-docx) פותחת את מסך הפרטים שלו.

1

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

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

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

מה מותר לכם לעשות עם סקיל, לפי מקורו

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

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

1

1. 1שתי פעולות בלבד: לנסות בשיחה, ולהסיר. אי אפשר לערוך, להוריד או לשתף סקיל שהותקן מהספרייה.

וכך זה נראה בסקיל שהועלה דרך החשבון שלכם:

1

2

1. 1כפתור Share לשיתוף הסקיל עם הארגון. הוא אינו מופיע בסקיל שהותקן מהספרייה.
2. 2חמש פעולות במקום שתיים. נוספו עריכה בשיחה, החלפת גרסה והורדה. Replace הוא המנגנון להחלפת גרסה בלי לאבד את שם הסקיל.

מה זה אומר בפועל

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

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

כשהסקיל מופעל יותר מדי

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

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

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

בדיקות הפעלה

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

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

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

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

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

בדיקות איכות

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

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

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

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

שיפור וגרסאות

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

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

כיבוי, הסרה ושיתוף

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

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

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

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

דוח בדיקות קצר לכל גרסה

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

כך נראה דוח מלא

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

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

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

הנתיבים המעודכנים מבוססים על Anthropic Help Center, Use skills in Claude, מאי 2026.

המסגרת המשרדית לפני שימוש ב-Skills

Skill עשוי לכלול הוראות, קבצים, קוד ותלויות. לכן יש להבחין בין Skill שבנה המשרד, Skill ששיתף עמית ו-Skill שמקורו חיצוני.

מדוע סקיל דורש בדיקה

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

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

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

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

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

מה יכול להיות בתוך סקיל

תיקיית סקיל יכולה להכיל כל אחד מהרכיבים הבאים, וכל אחד מהם דורש התייחסות שונה בבדיקה - לא כל הרכיבים מסוכנים באותה מידה:

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

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

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

לקרוא את קובץ ההוראות עצמו

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

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

1

2

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

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

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

שני מסלולים לגיטימיים, ובדיקה שחלה על שניהם

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

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

מה באמת מבדיל

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

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

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

ללא קוד כברירת מחדל

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

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

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

מודל רמזור: שלוש רמות סיכון

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

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

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

רשימת בדיקה לסקיל חיצוני

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

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

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

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

מידע משפטי רגיש

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

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

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

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

באילו נתונים בודקים סקיל חדש?

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

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

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

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

מינימום הרשאות

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

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

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

ניהול משרדי

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

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

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

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

ערכת ניהול משרדית

1. מרשם ה-Skills של המשרד

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

2. טופס אישור גרסה

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

3. דוח אירוע חריג

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

4. לוח התחזוקה

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

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

עדכניות משפטית

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

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

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

התנהגות חריגה

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

1. הפסיקו את השימוש בסקיל מיידית
2. כבו אותו
3. אל תעלו אליו מידע נוסף
4. תעדו בדיוק מה קרה
5. שמרו את הקבצים ואת הפלט שהתקבל
6. דווחו לגורם האחראי במשרד
7. בדקו אם נחשף מידע רגיש
8. בחנו החלפת הרשאות או פרטי גישה, אם רלוונטי

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

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

הסקיל אינו עורך הדין

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

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

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

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

עדכון, הקפאה והוצאה משימוש

Skill אינו נכס חד-פעמי. יש לקבוע מחזור חיים:

1. אישור גרסה ראשונה.
2. רישום בעל תהליך ובודק.
3. בדיקה תקופתית או לאחר שינוי דין ונוהל.
4. תיעוד תקלות ושינויים.
5. השבתה כאשר לא ניתן להבטיח עדכניות.
6. מחיקה או ארכוב של גרסאות שאינן מאושרות.

הנחיות הסיכון נשענות גם על Anthropic Help Center, Use skills in Claude ו-Use Claude Cowork safely, 2026.