Mods ל־Claude Code: מדריך להתאמה אישית ולהפחתת סיכוני אבטחה

Anthropic הכריזה ב־1 באוקטובר 2026 על Mods ל־Claude Code: פונקציות TypeScript שמשנות את ההתנהגות והממשק, מופצות באמצעות תוספים ופועלות ב־CLI וביישום למחשב. למפתחים בישראל זו אפשרות להתאים את כלי העבודה לצוות, אבל גם להכניס למחשב קוד בעל גישה רחבה. המדריך הבא מציע מסלול להתחלה זהירה: דוגמה רשמית, שינוי מצומצם ובדיקות לפני חיבור לקוד של החברה.

011. מגדירים שינוי קטן ומבינים את גבולות ההרשאות

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

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

022. מכינים סביבת ניסוי וטוענים את הדוגמה הרשמית

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

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

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

033. כותבים לוגיקה קטנה לפני החיבור ל־Mod

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

function makeLabel(value: string): string {
  const label = value.trim();
  return label || "סביבת בדיקה";
}

console.assert(makeLabel("  ניסוי  ") === "ניסוי");
console.assert(makeLabel("   ") === "סביבת בדיקה");

זהו קוד TypeScript רגיל, לא Mod מוכן ולא דוגמה ל־API של Anthropic. הוא מדגים טיפול ברווחים ובקלט ריק בלי לקרוא קבצים או לפנות לרשת. חברו פונקציה כזאת רק לנקודת ההתאמה המתועדת בדוגמה הרשמית; אם אין בה נקודה מתאימה, בחרו שינוי אחר שהמדריך אכן מדגים.

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

044. בודקים תוצאה, תופעות לוואי וקוד של אחרים

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

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

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

055. מעבירים לצוות רק אחרי שיש דרך חזרה

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

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