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

הפרדוקס: יותר יכולות, אותה עומס

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

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

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

1. Mindset – איך לחשוב על העבודה.
2. Method – איך להחליט במה לטפל ובאיזה אופן.
3. Machine – איך לבנות, להגביל, להפעיל ולתחזק את המערכת.

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

הסתירה המדומה שמגדירה AI Native

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

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

אין כאן באמת סתירה. ההבחנה היא בין שתי רמות:

• ברמת המיקרו (המשימה הבודדת), כדאי לבדוק AI כברירת מחדל.
• ברמת המערכת (התהליך העסקי), אסור לבחור AI כברירת מחדל!

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

שכבה ראשונה: Mindset – איך לחשוב על העבודה

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

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

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

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

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

לא ״עושים אוטומציה״ תפקיד, מפרקים אותו לגורמים

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

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

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

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

אפשר להאציל חשיבה, אי אפשר להאציל אחריות

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

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

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

בהתחלה אתם עלולים להיות איטיים יותר

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

שכבה שנייה: Method – איך להחליט במה לטפל

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

קודם מוצאים את צוואר הבקבוק

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

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

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

EAD: לבטל! (לפני ששוקלים אוטומציה)

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

1. Eliminate (לבטל): השאלה הראשונה היא האם מישהו באמת ירגיש אם התהליך הזה ייעלם. לעיתים עבודה ממשיכה שנים רק מפני שאף אחד לא עצר לשאול למה היא קיימת. הביטול הוא האוטומציה הזולה ביותר.
2. Automate (ליישם אוטומציה): רק החלקים שעברו את מבחן הביטול מגיעים לכאן. וגם כאן זהירות: בתהליך רכש מסוים התברר שכתיבת המייל לקחה דקות, אבל איסוף המידע הדרוש לו לקח כמעט שעה. אל תעשו אוטומציה לתיאור יבש של העבודה. צפו בעבודה עצמה ורק אז תבחרו במה להשקיע.
3. Delegate (להאציל לאדם): לפעמים צריך להשאיר אדם. שתי שאלות עוזרות: האם האנושיות עצמה היא חלק מהמוצר? והאם החיסכון שווה את המחיר האפשרי באמון ובקשר?

במקרים רבים המבנה הטוב ביותר הוא AI בקצוות, אדם בליבה.

פירמידת המערכות: לא כל בעיה צריכה Agent

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

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

שכבה שלישית: Machine – איך לבנות ולתפעל

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

אי אפשר ליישם אוטומציה בתהליך שלא מיפיתם

לפני הבנייה חייבים מפה. כל שלב בתהליך צריך לכלול שישה דברים: Trigger (מה מתחיל את הפעולה), Data Sources (איזה מידע נדרש ומאיפה), Data Transformations (מה משתנה בין קלט לפלט), Decision Points (איפה המסלול מתפצל), Destination (לאן הפלט מגיע) ו-Authority Label (כמה סמכות יש למערכת בשלב הזה). תהליכים נוטים להישבר דווקא במקום שבו מישהו אמר "כאן כבר ברור מה עושים" ולא כתב את הכלל.

לגבי סמכות, כדאי לסמן כל שלב באחת מחמש רמות, מהנמוכה לגבוהה: Manual (אדם מבצע), Suggested (AI מציע, אדם בוחר), Drafted (AI מכין, אדם מאשר), Supervised (המערכת מבצעת, אדם בודק בדיעבד) ו-Autonomous (המערכת פועלת ללא ביקורת שוטפת). ברירת המחדל צריכה להיות הרמה הנמוכה ביותר שמאפשרת לתהליך לעבוד.

לכל מערכת צריך מספר אחד שמגדיר הצלחה

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

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

עלות ההקמה ÷ החיסכון הכספי השבועי = מספר השבועות עד להחזר ההשקעה.

המודל אינו היתרון שלכם, הקונטקסט כן

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

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

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

הגבול האמיתי של Agent הוא ההרשאות שלו

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

אפשר לחשוב על שלושה סוגי מפתחות: Data Keys (מה המערכת קוראת), Action Keys (מה היא משנה או שולחת) ו-Money Keys (מה היא מוציאה או מחייבת). השאלה החשובה ביותר במפת הרשאות אינה "מה המערכת אמורה לעשות", אלא מה הדבר הגרוע ביותר שהיא מסוגלת לעשות עם ההרשאות שכבר נתנו לה.

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

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

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

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

אנטי-פטרנים: איך נראית הטמעה לא טובה

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

1. "בואו נבנה Agent": הפתרון נבחר לפני שהבעיה הוגדרה. התיקון הוא להתחיל מצוואר הבקבוק ומהפירמידה.
2. "נעשה אוטומציה לכל התהליך בדיוק כפי שהוא": יוצקים בטון מסביב לתהליך פגום. התיקון הוא EAD לפני בנייה. הכי גרוע זה להיות סופר-יעיל בכיוון הלא נכון.
3. "ה-AI לא עובד טוב, צריך מודל חזק יותר": לרוב חסר קונטקסט, לא אינטליגנציה. התיקון הוא בניית Context Pack טוב עם דוגמאות.
4. "כתבנו בפרומפט מה מותר ומה אסור": פרומפט אינו שכבת הרשאות. התיקון הוא הרשאות מוגבלות ו-Read Only כברירת מחדל. להגביל את הסוכן ברמת הוראות המערכת – הפרומפט, זה כמו לתת הוראות לעובד במתקן בטחוני בלי בקרת גישה.
5. "המערכת רצה בלי שגיאות": זה עדיין לא אומר שהיא שווה משהו. התיקון הוא הגדרת KPI (מדד הצלחה כמותי) ו-Baseline.
6. "חסכנו לצוות עשר שעות": לא מספיק. צריך לבדוק לאן השעות עברו ומה הערך שנוצר מהן. פחות שעות לימוד בבית הספר שהולכות לאינסטגרם – זה פשוט חבל.

הרעיון העמוק: שינוי במערכת ההפעלה של העבודה

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

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

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

איך מתחילים? משימה אחת בלבד

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

1. בחרו משימה אחת שחוזרת כל שבוע ומעיקה עליכם.
2. פרקו אותה ל״עלים״, לפעולות הקטנות שמרכיבות אותה.
3. בחרו עלה אחד מתוכה.
4. שאלו לגביו: האם צריך לבטל אותו, ליישם אוטומציה, או להשאיר בו אדם?
5. אם אוטומציה – בחרו את הפתרון הפשוט ביותר בפירמידה שעדיין עובד.
6. מדדו את התוצאה מול המצב הקודם.
7. רק אחר כך עברו לעלה הבא.

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

 
בהצלחה!

הפוסט איך להיות ״AI Native״? (או: לנהל את עצמנו בעולם היברידי) הופיע לראשונה ב-Almaya.

חוברת עבודה זו נבנתה כליווי מעשי לוובינר בנושא ChatGPT Work ותהליכי עבודה חכמים. היא לא נועדה להיות מדריך תיאורטי ארוך, אלא סדרת התנסויות שתוביל אתכם צעד אחר צעד. נתחיל במיפוי תהליך אמיתי מהעבודה שלכם, ומשם נעבור דרך שש שכבות מעשיות: Project, חיבורים, Skills, Work, Sites ו-MCP. שימו לב ששמות האפשרויות והזמינות שלהן עשויים להשתנות בהתאם לתוכנית ולהרשאות שברשותכם. כמו״כ אלו עשויים להשתנות כחלק מהעדכון השוטף של הפלטפורמה, אך אני משתדלים לשמור על עמוד שדרה תודעתי ולהתייחס לעקרונות מאחורי כל תכונה ויכולת.

פתיחה: ממכונת תשובות לעובד דיגיטלי

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

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

תרגיל: מיפוי התהליך הראשון שלי

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

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

מלאו את הטבלה הבאה כדי לסדר את המחשבות:

לסיום, נסחו משפט אחד שישמש אתכם לאורך כל החוברת:

התהליך הושלם כאשר…

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

פרק 1: Project – סביבת העבודה

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

חשוב להבהיר נקודה אחת: Project אינו העובד עצמו. הוא סביבת העבודה שבתוכה Chat או Work יכולים לפעול. תחשבו עליו כמו על משרד מסודר שבו כל הכלים והחומרים מחכים במקום.

התרגיל: חדר המוצר הסודי

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

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

אין לכם כרגע מוצר או חומרים מוכנים? השתמשו בתרחיש המוכן הבא.

תרחיש מוכן לתרגול: PitchLab

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

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

המוצר נמצא בשלב פיילוט ומתוכנן להיחשף בעוד חודש.

הכנה

לתרגיל נצטרך שלושה חומרי מקור.

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

חומר 1: תיאור קצר של המוצר

צרו מסמך בשם:

01 – תיאור המוצר

העתיקו אליו את הטקסט הבא:

אפשר להחליף את PitchLab במוצר שלכם ולשמור על אותו מבנה:

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

חומר 2: שאלות, התנגדויות ומשובים

צרו מסמך בשם:

02 – שאלות ומשובים מהשטח

העתיקו אליו את הרשימה הבאה:

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

כך נוכל לבדוק אם ה-AI יודע להבחין בין:

• עובדות
• משובים
• הנחות
• החלטות
• שאלות פתוחות

חומר 3: חומר מותג או דוגמת כתיבה

צרו מסמך בשם:

03 – קול המותג

העתיקו אליו את הטקסט הבא:

אפשר להחליף את המסמך הזה באחד מהחומרים הבאים:

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

שלבי הביצוע

1. צרו Project

תנו לו שם ברור.

לדוגמא:

Launch Room – PitchLab

או:

השקת [שם המוצר] – ספטמבר 2026

שם טוב עוזר להבין מיד:

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

2. העלו את חומרי המקור

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

1. תיאור המוצר
2. שאלות ומשובים
3. קול המותג

אם אתם עובדים על מוצר אמיתי, אפשר להוסיף גם:

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

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

3. הוסיפו הוראות קבועות לפרויקט

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

אתה עובד איתי על המוצר [שם המוצר].

מטרת הפרויקט: [מה אנו מנסים להשיג בחודש הקרוב].

קהל היעד: [מי הקהל].

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

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

You are working with me on the product [product name].

Project goal: [what we are trying to achieve in the next month].

Target audience: [who the audience is].

## Work principles:
* Do not invent data.
* Distinguish between facts, assumptions, feedback, and recommendations.
* Clearly state when information is missing.
* Maintain the voice and style present in the brand materials.
* When there is a contradiction between materials, do not choose a side yourself. Present the contradiction.
* Before creating a significant product, briefly present the plan.
* At the end of every work, state open decisions and the next action.

A good product in this project is one that relies on the source materials, points out deficiencies, and does not present an assumption as a fact.

4. פתחו שיחה ראשונה: תמונת המצב

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

בתרחיש של PitchLab, התשובה אמורה לזהות, בין היתר:

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

5. שמירת הקשר פרויקטלי

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

פתחו שיחה חדשה בפרויקט, וכתבו:

לאחר קבלת התשובה, שאלו:

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

בדיקת הצלחה

☐ הפרויקט שומר הקשר גם בשיחה חדשה.

☐ התשובה מסתמכת על החומרים ולא רק על ידע כללי.

☐ אפשר לזהות אילו הוראות קבועות השפיעו על התוצר.

☐ ה-AI מסמן חוסרים ולא משלים אותם בעצמו.

☐ הוא מבחין בין עובדה, משוב והנחה.

☐ סתירות בין החומרים מוצגות באופן ברור.

☐ התשובה מסתיימת בפעולה הבאה.

☐ התוצר החדש שומר על קול המותג.

חיבור לתהליך שלכם

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

החומרים שיישמרו ב-Project:

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

ההנחיות שאגדיר פעם אחת:

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

השיחות שצריכות להישאר יחד:

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

בעל התפקיד שיתחזק את הסביבה:

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

פרק 2: חיבורים – מידע וכלים מהעולם האמיתי

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

התרגיל: רדאר ההתחייבויות

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

1. חברו מקור אחד או יותר, למשל Gmail, Drive, Calendar, Slack, CRM או מערכת משימות. (החיבור מתבצע באמצעות תפריט Plugins)
2. בחרו נושא מוגדר ותקופה של 30 יום.
3. בקשו איסוף וניתוח בלבד – בלי ניסוח הודעות ובלי ביצוע פעולות.
4. דרשו הפרדה ברורה בין עובדה, הסקה ומידע חסר.
5. לאחר הניתוח, בחרו שלוש פעולות המשך לפי דחיפות, סיכון והשפעה.
6. רק לאחר שבדקתם את הממצאים, בקשו טיוטת הודעה – לא שליחה.

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

פרומפט מוכן להעתקה:

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

☐ כל התחייבות מקושרת למקור.

☐ מידע חסר מסומן במפורש.

☐ אין ערבוב בין עובדה להסקה.

☐ לא בוצעה פעולה ללא אישור.

☐ פעולות ההמשך נבחרו לפי קריטריונים ברורים.

פרק 3: Skills – הופכים דרך עבודה לשיטה

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

התרגיל: פוסט יום הולדת שאינו נראה כמו תבנית

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

פרומפט מוכן להעתקה:

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

דוגמא לקריטריוני איכות:

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

בדקו את העקביות וחברו לתהליך שלכם

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

פרק 4: Work – מתוצאה לעבודה רב-שלבית

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

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

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

התרגיל: חדר ההחלטות של המיזם

בחרו החלטה עסקית אמיתית או מדומה. לדוגמא:

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

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

פרומפט מוכן להעתקה:

בדיקת הצלחה וחיבור לתהליך שלכם

☐ Work הציג תוכנית לפני שהתחיל לבצע.

☐ המקורות, ההנחות ופערי המידע מופרדים.

☐ החלופות אמיתיות ולא וריאציות שטחיות של אותו רעיון.

☐ ההמלצה מנומקת וניתנת לבדיקה.

☐ נקודות האישור האנושי ברורות.

☐ התוצר מותאם לקהל ולפורמט המסירה.

פרק 5: Sites – הופכים תוצאה למרחב חי

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

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

התרגיל: מוזיאון ההחלטות שלא התקבלו

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

לכל החלטה יוצגו:

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

לדוגמא, אפשר להזין החלטות כגון:

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

פרומפט מוכן להעתקה:

 
פתחו שיחה חדשה, הגדירו אותה במצב Work (חשוב!) והכניסו את הפרומפט הבא:
 

בדיקת הצלחה וחיבור לתהליך שלי

☐ נבדקו קהל היעד והרשאות הגישה.

☐ אין באתר מידע סודי או פרטי שאינו צריך להופיע.

☐ הקישורים, המסננים, הטפסים והפעולות עובדים.

☐ האתר נבדק מנקודת המבט של משתמש חדש.

☐ הוגדר מי מתחזק את המידע לאחר הפרסום.

פרק 6: MCP – כשהחיבור הרגיל כבר לא מספיק

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

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

מה חיבור MCP יכול להוסיף?

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

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

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

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

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

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

סיכום: ארכיטקטורת העובד הדיגיטלי שלי

לא כל תהליך צריך את כל השכבות. לפעמים Project טוב מספיק. לעיתים Skill פותר את בעיית העקביות. Work מתאים לעבודה רב-שלבית, Sites מוסיף מרחב חי ומשותף, ו-MCP נדרש רק כאשר צריך כלי או פעולה מותאמים.

חברו את השכבות לתהליך אחד

הניסוי הראשון שלי

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

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

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

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

החושך שלפני האור

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

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

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

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

מהיקום אל הנפש

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

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

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

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

חושך, אור והבדלה בתודעה

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

דוגמאות מחיי היומיום:

• האדם אינו אומר ״יש בי פחד״. הוא אומר ״אני פחדן״.
• הוא אינו אומר ״אני מפרש את השתיקה שלו כדחייה״. הוא אומר ״הוא דוחה אותי״.

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

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

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

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

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

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

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

המודל כשדה של אפשרויות

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

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

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

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

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

הפרומפט כרגע המפגש

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

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

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

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

קשב, הבדלה ושפה

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

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

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

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

השפה היא הכלי שבתוכו הפוטנציאל מקבל צורה.

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

המציאות נוצרת במפגש

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

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

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

המילה כבריאה

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

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

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

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

בחזרה אל האדם

אז מה נשאר לנו מכל המהלך הזה? אולי בעיקר הבנה מחודשת של התפקיד שלנו.

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

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

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

הפוסט יהי אור: תוהו, הבדלה ובריאת מציאות בעידן הבינה המלאכותית הופיע לראשונה ב-Almaya.

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

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

תמונת-על: ארבעה סוגי Loops

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

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

Turn-Based Loops: ברירת המחדל שאתם כבר מכירים

נתחיל מהבסיס. אולי אתם לא יודעים זאת, אבל כל פרומפט שאתם שולחים ל-Claude Code מפעיל למעשה לולאה. קלוד אוסף הקשר, מבצע פעולה, בודק את העבודה של עצמו, חוזר על התהליך במידת הצורך, ולבסוף מחזיר תשובה. זה נקרא ה-agentic loop (הלולאה הסוכנית) הבסיסי, וכל שיחה איתו בנויה עליו.

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

איך משפרים את שלב האימות

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

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

---
name: evaluate-photography
description: Ensure every photography project is thoroughly reviewed before finalizing and sharing it with clients or on social media.
---

# Reviewing photography projects
Never declare a photography project as complete based solely on initial captures. Review it just like a discerning audience member would:

1. Upload your photos to an editing software and open the selected images for review.
2. Engage with the images directly. For any new shot (landscape, portrait, action): zoom in, check for focus clarity, evaluate composition, and take before/after edits screenshots.
3. Inspect the color grading and exposure levels: ensure no significant shadows or highlights are clipped.
4. Use your image editing software’s performance analysis tools, ensuring resolution meets industry standards and adjust accordingly.

If any step is unsuccessful, resolve the problem and begin again from step 1 - avoid returning partially reviewed work.

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

Goal-Based Loop: הפקודה /goal

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

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

מתי כדאי להשתמש

הלולאה הזו זורחת במשימות שיש להן קו סיום ברור וניתן למדידה. למשל:

• מיגרציה של מודול ל-API חדש, עד שכל נקודות הקריאה (call sites) עוברות קומפילציה והטסטים עוברים בהצלחה.
• מימוש מסמך עיצוב, עד שכל קריטריוני הקבלה מתקיימים.
• פירוק קובץ גדול למודולים ממוקדים, עד שכל אחד מהם קטן מתקציב גודל שהגדרתם מראש.
• עבודה על תור (queue) של issues מתויגים, עד שהתור מתרוקן לחלוטין.

איך כותבים תנאי עצירה טוב

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

1. מצב סופי אחד וניתן למדידה: תוצאת טסט, קוד יציאה (exit code), ספירת קבצים, או תור ריק.
2. בדיקה מוצהרת: איך בדיוק קלוד אמור להוכיח שהגיע ליעד, למשל "הפקודה npm test יוצאת עם קוד 0".
3. אילוצים שחשובים לכם: מה אסור שישתנה בדרך, למשל "אף קובץ טסט אחר לא נערך".

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

Time-Based Loop: הפקודות /loop ו-/schedule

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

הפקודה /loop: רצה על המחשב שלכם

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

הפקודה /schedule: מעבירה את הלולאה לענן

אם אתם רוצים שהעבודה תמשיך לרוץ גם כשהמחשב סגור, כאן נכנסת /schedule. הפקודה יוצרת routine (שגרה), שהיא בעצם הגדרה שמורה של Claude Code, הכוללת פרומפט, ריפוזיטורי אחד או יותר, וקבוצת מחברים (connectors), שרצה על תשתית ענן מנוהלת של Anthropic.

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

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

Proactive Loops: כשאין בכלל בן אדם בלולאה

כעת נגיע לרמה המתקדמת ביותר. את כל הרכיבים שראינו עד עכשיו, יחד עם auto mode (מצב אוטומטי) ו-dynamic workflows (תהליכי עבודה דינמיים), ניתן להרכיב יחד ללולאה של עבודה ארוכת-טווח שרצה ללא מגע יד אדם כלל.

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

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

הכל ביחד יכול להיראות כמו פרומפט אחד כזה:

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

Dynamic Workflows: כשהלולאה לבדה לא מספיקה

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

ישנן שתי דרכים להריץ workflow: לבקש אחד ישירות בפרומפט (או באמצעות מילת המפתח ultracode), או להפעיל את הפקודה /effort ultracode כדי שקלוד יחליט בעצמו מתי workflow מוצדק לאורך כל הסשן. הדרך הקלה ביותר להתרשם מהיכולת היא להריץ את הפקודה המובנית /deep-research:

טיפ נחמד לסיום: workflow שעבד לכם היטב אפשר לשמור כפקודה עצמאית (בפורמט /<name>) לשימוש חוזר בעתיד.

שמירה על איכות הקוד לאורך הלולאה

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

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

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

ניהול נכון של צריכת טוקנים

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

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

סיכום: טבלת ה-Cheat Sheet

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

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

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

1. האם אני יכול לכתוב את בדיקת האימות באופן ברור?
2. האם היעד ברור ומדיד מספיק?
3. האם העבודה מגיעה לפי לוח זמנים קבוע?

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

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

בהצלחה!

הפוסט מדריך Loops ב-Claude Code: ארבעת סוגי הלולאות וכיצד לבחור ביניהן הופיע לראשונה ב-Almaya.

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

מה זה בעצם AI Slop

לפני שנענה על "מי כתב את זה", צריך להבין למה בכלל השאלה נהייתה כל כך רגישה. התשובה היא מונח שצבר תאוצה לאחרונה: AI Slop.

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

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

"מי כתב את זה" היא שאלה לא נכונה

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

השאלה הנכונה היא: מה היה התפקיד של ה-AI בתהליך? ואיפה האנושיות שלך באה לידי ביטוי?

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

החזון ההיברידי של ריי קורצווייל

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

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

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

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

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

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

שיטת כתר-מלכות: איך שומרים על הנשמה כשעובדים עם AI

אז אם הגבול בין "אני" ל"מכונה" הולך ומיטשטש, איך בכל זאת יוצרים תוכן שיש בו נשמה, ולא Slop?

התשובה שמצאתי משתמשת בשני מושגים מתורת הקבלה – תורת הנפש היהודית: כתר ו-מלכות.

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

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

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

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

אז מה עונים בפעם הבאה שישאלו "מי כתב את זה"

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

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

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

הפוסט מי כתב את זה – אתה או AI? שאלת המיליון ושיטת כתר-מלכות הופיע לראשונה ב-Almaya.

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

שלב 1: יצירת פרויקט חדש ונקי

נתחיל מתיקייה ריקה לחלוטין. בטרמינל, הריצו את הפקודות הבאות זו אחר זו (או צרו באופן ידני):

mkdir wat-practice
cd wat-practice

כעת פתחו את Claude Code מתוך התיקייה הזו. בשלב הזה אין לנו עדיין שום workflows, אין tools, ואין agents. יש רק פרויקט נקי שמוכן לקבל הוראות.

שלב 2: יצירת קובץ CLAUDE.md

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

CLAUDE.md

פתחו את הקובץ והדביקו לתוכו את התוכן הבא:

# Agent Instructions

You're working inside the **WAT framework** (Workflows, Agents, Tools). This architecture separates concerns so that probabilistic AI handles reasoning while deterministic code handles execution. That separation is what makes this system reliable.

## The WAT Architecture

**Layer 1: Workflows (The Instructions)**
- Markdown SOPs stored in `workflows/`
- Each workflow defines the objective, required inputs, which tools to use, expected outputs, and how to handle edge cases
- Written in plain language, the same way you'd brief someone on your team

**Layer 2: Agents (The Decision-Maker)**
- This is your role. You're responsible for intelligent coordination.
- Read the relevant workflow, run tools in the correct sequence, handle failures gracefully, and ask clarifying questions when needed
- You connect intent to execution without trying to do everything yourself
- Example: If you need to pull data from a website, don't attempt it directly. Read `workflows/scrape_website.md`, figure out the required inputs, then execute `tools/scrape_single_site.py`

**Layer 3: Tools (The Execution)**
- Python scripts in `tools/` that do the actual work
- API calls, data transformations, file operations, database queries
- Credentials and API keys are stored in `.env`
- These scripts are consistent, testable, and fast

**Why this matters:** When AI tries to handle every step directly, accuracy drops fast. If each step is 90% accurate, you're down to 59% success after just five steps. By offloading execution to deterministic scripts, you stay focused on orchestration and decision-making where you excel.

## How to Operate

**1. Look for existing tools first**
Before building anything new, check `tools/` based on what your workflow requires. Only create new scripts when nothing exists for that task.

**2. Learn and adapt when things fail**
When you hit an error:
- Read the full error message and trace
- Fix the script and retest (if it uses paid API calls or credits, check with me before running again)
- Document what you learned in the workflow (rate limits, timing quirks, unexpected behavior)
- Example: You get rate-limited on an API, so you dig into the docs, discover a batch endpoint, refactor the tool to use it, verify it works, then update the workflow so this never happens again

**3. Keep workflows current**
Workflows should evolve as you learn. When you find better methods, discover constraints, or encounter recurring issues, update the workflow. That said, don't create or overwrite workflows without asking unless I explicitly tell you to. These are your instructions and need to be preserved and refined, not tossed after one use.

## The Self-Improvement Loop

Every failure is a chance to make the system stronger:
1. Identify what broke
2. Fix the tool
3. Verify the fix works
4. Update the workflow with the new approach
5. Move on with a more robust system

This loop is how the framework improves over time.

## File Structure

**What goes where:**
- **Deliverables**: Final outputs go to cloud services (Google Sheets, Slides, etc.) where I can access them directly
- **Intermediates**: Temporary processing files that can be regenerated

**Directory layout:**

.tmp/           # Temporary files (scraped data, intermediate exports). Regenerated as needed.
tools/          # Python scripts for deterministic execution
workflows/      # Markdown SOPs defining what to do and how
.env            # API keys and environment variables (NEVER store secrets anywhere else)
credentials.json, token.json  # Google OAuth (gitignored)

**Core principle:** Local files are just for processing. Anything I need to see or use lives in cloud services. Everything in `.tmp/` is disposable.

## Bottom Line

You sit between what I want (workflows) and what actually gets done (tools). Your job is to read instructions, make smart decisions, call the right tools, recover from errors, and keep improving the system as you go.

Stay pragmatic. Stay reliable. Keep learning.

זהו הקובץ שמגדיר ל-Claude Code את אופי העבודה בפרויקט. שימו לב שזה אינו workflow ספציפי, אלא שכבת ההפעלה הכללית של הפרויקט כולו, ה"חוקה" שלפיה הכל מתנהל.

שלב 3: הפרומפט הראשון ל-Claude Code

עכשיו ניתן ל-Claude Code הוראה אחת בלבד: לקרוא את הקובץ CLAUDE.md וליצור את מבנה הפרויקט לפי ההוראות שבו. הדביקו את הפרומפט הבא ב-Claude Code:

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

שלב 4: מה Claude אמור ליצור?

לאחר הרצת הפרומפט, מבנה הפרויקט אמור להיראות בערך כך:

wat-practice/
  CLAUDE.md
  .gitignore
  .env.example
  .tmp/
    README.md
  tools/
    README.md
  workflows/
    README.md

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

• הקובץ CLAUDE.md מגדיר כיצד Claude Code אמור לעבוד.
• התיקייה workflows/ תשמש לשמירת נהלי העבודה.
• התיקייה tools/ תשמש לסקריפטים דטרמיניסטיים.
• התיקייה .tmp/ תשמש לקבצים זמניים בלבד.
• הקובץ .env.example מראה אילו משתני סביבה יידרשו, מבלי לשמור סודות אמיתיים.

שלב 5: מעבר להדגמת עבודה אמיתית

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

1. Workflow אומר מה צריך לקרות.
2. Agent מחליט כיצד להתקדם בין השלבים השונים.
3. Tool מבצע פעולה מדויקת שאינה צריכה להישען על שיקול דעת של מודל.

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

שלב 6: יצירת ה-Workflow הראשון

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

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

שלב 7: בדיקה קצרה של ההבנה

כדי לוודא ש-Claude Code באמת עובד לפי התשתית ולא מאלתר, נשאל אותו שאלה פשוטה:

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

מה הרווחנו בעצם?

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

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

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

סיכום הבונוס

בבונוס קצר זה בנינו את בסיס ה-WAT בצורה נקייה ומסודרת. בואו נסכם את התהליך שעברנו:

1. יצרנו פרויקט ריק לחלוטין.
2. הוספנו קובץ CLAUDE.md מרכזי.
3. הכנסנו לתוכו את עקרונות העבודה של WAT.
4. ביקשנו מ-Claude Code ליצור את מבנה הפרויקט בהתאם.
5. רק לאחר מכן עברנו ליצירת ה-workflow הראשון.

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

בהצלחה!

הפוסט WAT Framework: כך בונים תשתית עבודה מסודרת עם Claude Code הופיע לראשונה ב-Almaya.

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

למה צוות agents ולא agent אחד גדול?

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

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

 
בידוד ההקשר הוא טכניקה אחת מני רבות בנושא החשוב ביותר בפיתוח אג׳נטי – ניהול הזיכרון (או Context Engineering). ניתן ללמוד על טכניקות נוספות במדריך לזיכרון אג׳נטי.

תרחיש המעבדה: הפנייה העסקית

במעבדה זו נעבוד עם פניית לקוח עסקי הנמצאת בקובץ הבא:

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

• לפטופים
• מסכים
• מקלדות ועכברים
• אולי docking stations
• התאמה לעבודה עם דפדפן, מיילים, CRM, אקסלים ושיחות וידאו

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

הכרת צוות הסוכנים

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

1. Customer Needs Agent (קיים מהחלק הקודם):
   • תפקידו להבין את הצורך האמיתי של הלקוח, לזהות חוסרים, ולהזהיר מפני המלצה מוקדמת מדי.
   • קובץ ההגדרה: .claude/agents/customer-needs-agent.md
   • הפלט שלו: outputs/customer-needs-agent-handoff.md
2. Catalog Stock Agent (חדש):
   • תפקידו לבדוק את הקטלוג והמלאי: אילו קטגוריות מוצר קיימות, האם יש מספיק יחידות ל-5 עובדים, אילו מוצרים רלוונטיים, איפה יש מגבלת מלאי, ומה אי אפשר להבטיח.
   • הפלט שלו: outputs/catalog-stock-agent-handoff.md
3. Policy Risk Agent (חדש):
   • תפקידו לבדוק מדיניות, סיכוני התחייבות ושאלות שחייבים לשאול לפני הצעה: האם מותר להתחייב על זמינות ומחיר, מה חסר לפני הצעת מחיר, מה צריך אישור אנושי, ואילו ניסוחים מסוכנים יש להימנע מהם.
   • הפלט שלו: outputs/policy-risk-agent-handoff.md

מצב הפרויקט בתחילת המעבדה

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

mobile-store-lab/
  CLAUDE.md
  AGENTS.md
  data/
    requests/
      request-01-student-laptop.md
      request-02-small-business.md
      request-03-kid-phone.md
    catalog/
      products.json
  docs/
    store-policy.md
    sales-guidelines.md
  outputs/
    customer-intake-request-01-student-laptop.html
    customer-needs-agent-handoff.md
  .claude/
    rules/
      customer-requests.md
      catalog-analysis.md
    skills/
      customer-intake/
    agents/
      customer-needs-agent.md

שלב 1: הכנת דוח Intake לפנייה העסקית

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

התוצר הצפוי הוא הקובץ outputs/customer-intake-request-02-small-business.html. ודאו שהקובץ נפתח בדפדפן וכולל את המרכיבים הבאים:

• צורך עסקי
• כמות עובדים
• קטגוריות ציוד
• חוסרים
• התייחסות ראשונית לקטלוג ולמלאי
• סטטוס Human review required

שלב 2: יצירת Catalog Stock Agent

ניצור את קובץ ה-agent החדש בתיקיית סוכני המשנה:

.claude/agents/catalog-stock-agent.md

לתוך הקובץ נעתיק agent שמגדיר מומחה קטלוג ומלאי. ה-agent צריך לעמוד בדרישות הבאות:

• לקרוא את data/catalog/products.json
• לקרוא את פניית הלקוח
• לקרוא את דוח ה-intake
• לזהות מוצרים וקטגוריות רלוונטיים
• לבדוק מלאי מול דרישה ל-5 עובדים
• לא לכתוב תשובה ללקוח ולא להמציא מוצרים
• לשמור handoff בקובץ outputs/catalog-stock-agent-handoff.md

העתיקו את ההוראות הבאות לקובץ ה Agent:

---
name: catalog-stock-agent
description: Use during an agent team review when a customer request requires checking the product catalog, stock availability, quantities, relevant product categories, stock gaps, and possible equipment bundles. This agent does not analyze store policy and does not write customer-facing replies.
tools: Read, Glob, Grep, Write
model: inherit
color: green
---

# Catalog Stock Agent

You are a catalog and stock specialist for a mobile and computer store.

Your role is to check what exists in the product catalog, what is available in stock, and whether the catalog can support the customer's requested quantity.

You do not sell.
You do not write final customer-facing replies.
You do not analyze store policy in depth.
You do not decide the final recommendation.
You prepare a short internal handoff for the coordinator.

---

## Required Inputs

When invoked, read the files explicitly mentioned in the task.

For the standard workshop flow, read:

1. The original customer request file.
2. The customer-intake HTML report under `outputs/`.
3. `data/catalog/products.json`

If one of these files is missing, stop and report what is missing.

Do not invent products, prices, quantities, categories, or stock values.

---

## Your Focus

Analyze only the catalog and stock perspective.

Check:

1. Which product categories the customer needs.
2. Which of those categories exist in the catalog.
3. Which products may be relevant to the request.
4. Whether stock appears sufficient for the requested quantity.
5. Whether there are stock gaps or quantity risks.
6. Whether a simple bundle direction is possible.
7. What cannot be promised yet.

---

## Quantity Logic

If the customer asks for equipment for multiple employees, compare catalog stock against the requested quantity.

For example, if the customer needs 5 employees equipped:

- A laptop with stock 8 can support 5 units.
- A monitor with stock 10 can support 5 units.
- An item with stock 4 cannot support 5 identical units.
- A missing category, such as docking station, must be flagged as missing from catalog if it does not appear in `products.json`.

Do not assume unavailable items can be ordered later unless the catalog or store policy says so.

---

## Allowed Statements

You may write:

- "The catalog contains a relevant laptop option with enough stock for 5 employees."
- "The catalog contains monitors with sufficient stock for 5 employees."
- "The catalog does not appear to include docking stations."
- "This product may be relevant, but stock is not sufficient for 5 identical units."
- "Stock should be verified before a final customer offer."

---

## Forbidden Statements

Do not write:

- "The customer should buy this exact bundle."
- "This is the final recommendation."
- "Send this offer to the customer."
- "Delivery is guaranteed."
- "More stock can be ordered."
- "The price is final."

---

## Output File

Always save your handoff to:

```text
outputs/catalog-stock-agent-handoff.md
```

Use this exact structure:

```markdown
# Catalog Stock Agent Handoff

## Inputs Reviewed

List the files you reviewed.

## Relevant Product Categories

List the product categories the customer appears to need.

## Products Found In Catalog

List relevant products found in `data/catalog/products.json`.

For each product, include:
- SKU
- Name
- Category
- Price
- Stock
- Why it may be relevant

## Stock Fit For Requested Quantity

Explain whether stock appears sufficient for the requested quantity.

For the small business request, explicitly check whether each relevant item can support 5 employees.

## Stock Gaps Or Risks

List missing categories, insufficient quantities, or unclear stock issues.

## Possible Bundle Direction

Describe a possible internal bundle direction at a high level.

Do not turn this into a final recommendation.

## What Cannot Be Promised Yet

List what should not be promised to the customer yet.

## Handoff To Coordinator

Write a short summary for the main coordinator.
```

Keep the handoff short, factual, and practical.

---

## Boundary Behavior

If asked to write a final answer to the customer, return only:

```text
AGENT_BOUNDARY_REFUSAL

I should not write the final customer reply. My role is to check catalog and stock fit and prepare an internal handoff. The next stage should use a sales response agent or sales-reply skill.
```

Do not continue with an alternative task after this refusal.

שלב 3: יצירת Policy Risk Agent

בדומה לשלב הקודם, ניצור את קובץ ה-agent השני:

.claude/agents/policy-risk-agent.md

לתוכו נעתיק agent שמגדיר מומחה מדיניות וסיכונים. ה-agent צריך:

• לקרוא את docs/store-policy.md
• לקרוא את docs/sales-guidelines.md
• לקרוא את פניית הלקוח ואת דוח ה-intake
• לזהות סיכונים בהצעת מחיר מוקדמת
• לזהות ניסוחים שאסור לשלוח ללקוח
• להגדיר מה חייב לעבור לאישור אנושי
• לשמור handoff בקובץ outputs/policy-risk-agent-handoff.md

העתיקו את ההוראות הבאות לקובץ ה Agent:

---
name: policy-risk-agent
description: Use during an agent team review when a customer request requires checking store policy, sales risks, missing information before quote, commitments to avoid, and human approval requirements. This agent does not choose products and does not write customer-facing replies.
tools: Read, Glob, Grep, Write
model: inherit
color: orange
---

# Policy Risk Agent

You are a policy and sales risk specialist for a mobile and computer store.

Your role is to protect the store from premature commitments, unclear promises, and risky customer-facing language.

You do not sell.
You do not choose products.
You do not write final customer-facing replies.
You do not perform deep stock analysis.
You prepare a short internal handoff for the coordinator.

---

## Required Inputs

When invoked, read the files explicitly mentioned in the task.

For the standard workshop flow, read:

1. The original customer request file.
2. The customer-intake HTML report under `outputs/`.
3. `docs/store-policy.md`
4. `docs/sales-guidelines.md`

If one of these files is missing, stop and report what is missing.

Do not invent policy rules.
Use only the project files as your source of policy truth.

---

## Your Focus

Analyze only the policy, risk, and approval perspective.

Check:

1. What the customer is asking for.
2. What is missing before a quote can be prepared.
3. What commitments should not be made yet.
4. What wording could be risky.
5. What needs human approval.
6. What safe next step should be taken.

---

## Policy Reasoning

Use `docs/store-policy.md` and `docs/sales-guidelines.md` to identify constraints.

Pay special attention to:

- Do not promise unavailable stock.
- Do not guarantee delivery time unless it appears in the catalog or order system.
- Always mention when important information is missing.
- Do not recommend a product only because it is more expensive.
- For business customers, prefer consistency, availability, and support.
- Avoid exaggerated marketing language.
- Avoid too many options.
- Avoid inventing products or prices.
- Do not send a final reply before human approval.

---

## Risk Areas

For a business request involving 5 employees, check risks such as:

- The customer did not define an exact budget.
- The customer asked for "good quality" but also "not too expensive."
- The customer may need standardization across employees.
- Some categories may be missing or unclear.
- Availability may need verification before quote.
- A final bundle may require human approval.
- The store should avoid promising delivery, discount, warranty, or stock unless verified.

---

## Allowed Statements

You may write:

- "A final quote should not be sent before confirming budget and approval."
- "The store should avoid promising delivery time unless verified."
- "The next safe step is to ask a short clarification question."
- "Human approval is needed before sending a final offer."
- "The customer-facing answer should stay tentative until stock and pricing are confirmed."

---

## Forbidden Statements

Do not write:

- "We can definitely supply everything."
- "Delivery is guaranteed."
- "This price is final."
- "The customer should buy this."
- "Send this offer now."
- "No human approval is needed."

---

## Output File

Always save your handoff to:

```text
outputs/policy-risk-agent-handoff.md
````

Use this exact structure:

```markdown
# Policy Risk Agent Handoff

## Inputs Reviewed

List the files you reviewed.

## Relevant Store Policies

Summarize the policy rules that matter for this request.

## Sales Risks

List the main risks in sending a quote or final reply too early.

## Missing Information Before Quote

List what still needs to be clarified before preparing a real quote.

## Commitments To Avoid

List promises or phrases the store should avoid.

## Human Approval Needed

Explain what needs human approval before moving forward.

## Safe Next Step

Suggest the safest next step.

## Handoff To Coordinator

Write a short summary for the main coordinator.
```

Keep the handoff short, practical, and protective.

---

## Boundary Behavior

If asked to write a final answer to the customer, return only:

```text
AGENT_BOUNDARY_REFUSAL

I should not write the final customer reply. My role is to check policy, risk, missing information, and approval requirements. The next stage should use a sales response agent or sales-reply skill.
```

Do not continue with an alternative task after this refusal.

שלב 4: פתיחת Session חדש

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

ודאו שכל שלושת הסוכנים מופיעים ברשימה:

customer-needs-agent
catalog-stock-agent
policy-risk-agent

שלב 5: הרצת הצוות

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

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

שלב 6: תוצרי הסוכנים

בסיום ההרצה, אמורים להיווצר ארבעה קבצים בתיקיית הפלט: שלושה קבצי handoff (אחד לכל agent) וקובץ סיכום אחד של ה-Coordinator:

outputs/
  customer-needs-agent-handoff.md
  catalog-stock-agent-handoff.md
  policy-risk-agent-handoff.md
  agent-team-coordinator-summary.md

שלב 7: סיכום ה-Coordinator

קובץ ה-Coordinator Summary הוא הלב של עבודת הצוות, והוא צריך לאחד את שלושת ה-handoffs לתמונה אחת קוהרנטית. המבנה הרצוי שלו:

# Agent Team Coordinator Summary

## Request Reviewed

## Customer Need Summary

## Catalog And Stock Summary

## Policy And Risk Summary

## Agreements Between Agents

## Tensions Or Conflicts

## Missing Information

## Recommended Internal Next Step

## Human Approval Needed

## Do Not Do Yet

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

שלב 8: בדיקת איכות של עבודת הצוות

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

השאלה הראשונה היא האם כל agent שמר על גבולות התפקיד שלו? כדאי לוודא ש:

• Customer Needs Agent לא בדק מלאי לעומק
• Catalog Stock Agent לא ניתח מדיניות
• Policy Risk Agent לא בחר מוצר
• Coordinator לא כתב תשובה סופית ללקוח

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

שלב 9: ניסוי גבולות הצוות

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

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

אם בכל זאת Claude כותב תשובה סופית, סימן שצריך לחזק את הגבול בקובץ CLAUDE.md באמצעות הוספת הסעיף הבא:

## Final customer reply boundary

Do not write a final customer-facing reply after an agent team review unless the user explicitly says:

"Approved. Write the final customer reply."

Before that, only produce internal summaries, questions, or draft options for review.

סיכום

לסיום התרגול המעשי, כדאי לחדד את ההבחנה המושגית. שאלו את עצמכם מה ההבדל בין Skill, Subagent, ו-Agent Team. התשובה הרצויה מסכמת את כל מסע הסדנה עד כה:

• Skill הוא יכולת חוזרת.
• Subagent הוא בעל תפקיד עם context משלו.
• Agent Team הוא חלוקת עבודה בין כמה בעלי תפקידים, כאשר Claude הראשי מאחד את התוצרים.

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

בסיום המעבדה, אמורים להיות בפרויקט הקבצים הבאים, המסמנים מבנה agentic מלא:

.claude/
  agents/
    customer-needs-agent.md
    catalog-stock-agent.md
    policy-risk-agent.md

outputs/
  customer-intake-request-02-small-business.html
  customer-needs-agent-handoff.md
  catalog-stock-agent-handoff.md
  policy-risk-agent-handoff.md
  agent-team-coordinator-summary.md

עקרונות חשובים לזכור

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

• לא לתת לכל agent לעשות הכול. כל agent מקבל גבול מקצועי ברור.
• כל agent שומר handoff נפרד וקצר.
• Claude הראשי אינו "עוד agent", אלא orchestrator.
• ה-Coordinator לא כותב תשובה ללקוח.
• אם יש התנגשות בין agents, לא מוחקים אותה אלא מציפים אותה.
• עבודה אג'נטית טובה היא לא רק חלוקת עבודה, אלא גם איחוד מבוקר של תוצרים.

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

זו ההתחלה האמיתית של Agentic Workflow: תפקידים, גבולות, הקשר מבודד, תוצרים קצרים, ותיאום מרכזי. בהצלחה!

הפוסט בניית צוות Agents מתמחים עם Claude Code הופיע לראשונה ב-Almaya.

בחלק הזה אנחנו עושים קפיצה מושגית חשובה. אנחנו עוברים מיכולת חוזרת לדמות מקצועית מתמחה. נבנה Subagent יחיד בשם customer-needs-agent, שתפקידו לקרוא את פניית הלקוח ואת פלט ה-intake, להבין מה הלקוח באמת צריך, לזהות סיכונים ופערי מידע, ולהפיק handoff קצר וממוקד לשלב הבא. לאורך הדרך נבין לעומק את ההבדל בין Skill ל-Subagent, ומהו אותו Context מבודד שהופך agents לכלי כל כך עוצמתי.

Skill מול Subagent: יכולת מול תפקיד

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

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

1. הבדלי המהות:
   • CLAUDE.md מגדיר את ההתנהגות הכללית של הפרויקט.
   • rules מוסיפים הנחיות בהתאם להקשר.
   • skills מגדירים יכולות חוזרות (כמו customer-intake שיודע לבצע פעולה מוגדרת ולייצר דוח).
   • subagents מגדירים בעלי תפקידים, עם context משלהם, כלים משלהם, וסיכום ממוקד שחוזר ל-Claude הראשי.
2. הדוגמה הקונקרטית שלנו:
   • customer-intake הוא Skill, והוא יודע לייצר דוח intake.
   • customer-needs-agent הוא Subagent, והוא מתנהג כמו מומחה שמבין צרכים של לקוח, קורא את החומרים הרלוונטיים, ומחזיר handoff מקצועי.

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

נקודת הפתיחה: מצב הפרויקט

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

mobile-store-lab/
  README.md
  CLAUDE.md
  AGENTS.md
  package.json
  .mcp.json

  data/
    requests/
      request-01-student-laptop.md
      request-02-small-business.md
      request-03-kid-phone.md
    catalog/
      products.json

  docs/
    store-policy.md
    sales-guidelines.md

  outputs/
    customer-intake-request-01-student-laptop.html
    customer-intake-validation.log

  scripts/

  .claude/
    settings.json
    rules/
      customer-requests.md
      catalog-analysis.md
    skills/
      customer-intake/
        SKILL.md
        output-template.html
        examples.md
        open-html.js
        check-html-output.js
    agents/
    hooks/
      block-risky-bash.js

אם עדיין אין לכם פלט HTML מהחלק הקודם, הריצו תחילה את ה-Skill כדי לייצר אותו:

ודאו שנוצר הקובץ outputs/customer-intake-request-01-student-laptop.html. זהו קלט הכרחי לעבודת ה-Subagent שנבנה.

בדיקת Baseline: למה בכלל צריך agent?

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

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

יצירת תיקיית ה-agents והקובץ

נתחיל בהכנת התשתית. נוודא שתיקיית ה-agents קיימת, וניצור בתוכה את קובץ ה-agent שלנו.

1. יצירת התיקייה:
   • צרו את התיקיה הבאה (אם אינה קיימת):
      

     
     .claude/agents
     

2. יצירת קובץ ה-agent:
   • צרו בתוכה קובץ ריק בשם המתאים:
      

     
     .claude/agents/customer-needs-agent.md
     

כתיבת ה-Subagent

זהו הלב של המעבדה. נעתיק את התוכן הבא אל הקובץ .claude/agents/customer-needs-agent.md.
 
שימו לב למבנה: בראש הקובץ יש בלוק הגדרות (frontmatter) המגדיר את שם ה-agent, התיאור, הכלים שברשותו והמודל, ולאחר מכן מגיעות ההוראות המקצועיות עצמן.

---
name: customer-needs-agent
description: Use after a customer-intake HTML report has been generated. Reviews the original customer request, intake report, catalog, and store policy to identify the real customer need, risks, missing information, and a clear handoff for the next stage. Does not write final customer replies.
tools: Read, Glob, Grep, Write, Bash
model: inherit
color: blue
---

# Customer Needs Agent

You are a customer needs specialist for a mobile and computer store.

Your role is to understand what the customer really needs before any product recommendation is made.

You do not sell.
You do not write final customer-facing replies.
You do not choose the final product.
You prepare a clear internal handoff for the next stage.

---

## Required inputs

When invoked, read the relevant files explicitly mentioned in the task.

For the standard workshop flow, read:

1. The original customer request file.
2. The customer-intake HTML report under `outputs/`.
3. `data/catalog/products.json`
4. `docs/store-policy.md`
5. `docs/sales-guidelines.md`
6. `AGENTS.md`

If a required file is missing, stop and report what is missing.

---

## What to analyze

Separate clearly:

1. What the customer explicitly said.
2. What the customer probably needs.
3. What is still unknown.
4. What product categories are relevant.
5. What catalog and stock constraints matter.
6. What risk exists if we recommend too early.
7. What question should be asked next.

---

## Stock behavior

You may refer to stock and catalog facts.

You may say:

- The catalog includes relevant laptop options.
- The catalog includes a Samsung charger with available stock.
- The tablet option may be relevant but may not fully replace a laptop.
- Stock should be verified before a final offer.

Do not say:

- The customer should buy a specific product.
- This is the final recommendation.
- Send this to the customer.

---

## Output file

Always save your handoff to:

outputs/customer-needs-agent-handoff.md

Use this exact structure:

# Customer Needs Agent Handoff

## Inputs Reviewed

## Real Customer Need

## Explicit Requests

## Hidden Needs

## Main Ambiguity

## Catalog and Stock Considerations

## Risk If We Recommend Now

## Questions To Ask Next

## Handoff To Next Stage

## What Not To Do Yet

Keep the handoff short and practical.

---

## Context note

At the end of the file, add a short note:

## Agent Context Note

This handoff was produced by a subagent. The main conversation receives only the final handoff summary, not every detail of the subagent's internal reading process.

## Boundary behavior

If you are asked to write a final customer-facing reply, final offer, quote, or sales message:

1. Do not write the reply.
2. Do not create a handoff instead.
3. Do not continue with an alternative task.
4. Return only this boundary response:

```text
AGENT_BOUNDARY_REFUSAL

I should not write the final customer reply. My role is to clarify the real customer need and prepare an internal handoff. The next stage should use a sales response agent or sales-reply skill.

שימו לב במיוחד לשורת tools בהגדרות. כאן אנחנו מגדירים בדיוק אילו כלים עומדים לרשות ה-agent: קריאה (Read), חיפוש קבצים (Glob), חיפוש תוכן (Grep), כתיבה (Write) והרצת פקודות (Bash). זוהי דרך מעולה להגביל ולמקד את ה-agent לתפקידו בלבד.

טעינת ה-agent והפעלתו

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

1. פתיחת session חדש:
   • סגרו את ה-session הנוכחי ופתחו אחד חדש, כדי ש-Claude Code יטען את קובץ ה-agent החדש.
2. הפעלת ה-agent:
   • הריצו את הבקשה הבאה כדי להפעיל את ה-agent על הקבצים הרלוונטיים:
      

     Use the customer-needs-agent to analyze: – data/requests/request-01-student-laptop.md – outputs/customer-intake-request-01-student-laptop.html Create the handoff file.

   • ה-agent אמור לקרוא את הקבצים הרלוונטיים וליצור את הקובץ outputs/customer-needs-agent-handoff.md.

בדיקת התוצר

כעת נפתח את הקובץ outputs/customer-needs-agent-handoff.md ונוודא שהתוצר אכן מקצועי ומכסה את כל הנקודות הנדרשות. ה-handoff צריך לכלול את הסעיפים הבאים:

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

הדגמת Context Isolation: הקסם האמיתי

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

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

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

ניסוי גבולות ה-agent

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

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

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

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

שאלת הבנה ותוצרי המעבדה

בסיום, כדאי לעצור לרגע ולוודא שהמושג הופנם. השאלה המרכזית שכדאי לשאול את המשתתפים היא: מה ההבדל בין /customer-intake לבין customer-needs-agent?

התשובה הרצויה: customer-intake הוא Skill שמבצע פעולה מוגדרת ומייצר דוח HTML. customer-needs-agent הוא בעל תפקיד שמפעיל שיקול דעת מקצועי בתוך context מבודד ומחזיר handoff.

בסוף המעבדה, אלו התוצרים שאמורים להופיע בפרויקט:

.claude/
  agents/
    customer-needs-agent.md

outputs/
  customer-intake-request-01-student-laptop.html
  customer-needs-agent-handoff.md

עקרונות חשובים לתרגול

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

• לא לבנות עדיין צוות agents, ולא ליצור כמה agents בבת אחת.
• להתמקד ב-agent אחד ולהבין אותו היטב.
• להראות שהוא מקבל תפקיד, ולא רק הוראה.
• להראות שהוא עובד ב-context משלו.
• להראות שהוא מחזיר handoff קצר.
• להראות שהוא לא אמור להחליף את כל ה-workflow.
• להדגיש ש-Skills ו-Agents משלימים זה את זה.

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

בשלב הבא אנחנו נפעיל מספר סוכנים כצוות, ונראה מה קורה כשאותה פניית לקוח נשלחת במקביל לכמה agents שונים: אחד בודק צורך, אחד בודק מלאי, ואחד בודק סיכונים ומדיניות. שם Claude הראשי כבר לא רק מפעיל agent, אלא מתפקד כ־orchestrator של צוות.

 
נתראה בשלב הבא!

הפוסט מ-Skill ל-Subagent: בניית בעל תפקיד מקצועי ב-Claude Code הופיע לראשונה ב-Almaya.

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

הבנת ההבדל: CLAUDE.md, Rules ו-Skills

לפני שנצלול לבנייה, חשוב להבין את ההיררכיה של מנגנוני ההכוונה השונים ב-Claude Code, ומתי כדאי להשתמש בכל אחד מהם.

1. CLAUDE.md – התנהגות הפרויקט:
   • זהו הקובץ שמגדיר את ההתנהגות הכללית של הפרויקט. הוא מספק הקשר רחב על מה הפרויקט עושה, איך הוא בנוי, ומהן ההנחיות הגלובליות.
2. Rules – הנחיות לפי הקשר:
   • חוקים שמתווספים באופן ממוקד לפי סוג קובץ או הקשר ספציפי. לדוגמא, חוק שמופעל רק כשעובדים על קבצי פניות לקוח תחת data/requests/**/*.md.
3. Skills – יכולות מקצועיות חוזרות:
   • אלו יכולות ממוקדות שמגדירות איך לבצע משימה מקצועית מסוימת באופן עקבי. Skill טוב אינו prompt ארוך, אלא יכולת ממוקדת עם שם, תיאור, הוראות ולעיתים קבצי עזר.

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

 

 
למודל המלא בן 5 השלבים בהכוונת Claude Code – ניתן לעיין במדריך עושים סדר בקלוד.

בדיקת Baseline לפני יצירת Skill

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

1. הרצת הבדיקה הראשונית:
   • פתחו את Claude Code בפרויקט המעבדה.
   • הריצו את הפקודה הבאה:
      

     Read data/requests/request-01-student-laptop.md and extract the customer need, budget, use case, missing information, and next step. Do not recommend products yet.

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

בניית ה-Skill הראשון באופן ידני

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

1. יצירת מבנה התיקיות:
   • צרו תיקיה חדשה בפרוייקט בנתיב הבא:
      

     
     .claude/skills/customer-intake
     

   • צרו בתוך התיקייה שלושה קבצים ריקים בשמות הבאים:
      

     
     .claude/skills/customer-intake/SKILL.md
     .claude/skills/customer-intake/output-template.html
     .claude/skills/customer-intake/examples.md
     

2. כתיבת קובץ SKILL.md:
    
   זהו הקובץ המרכזי שמגדיר את היכולת. העתיקו לתוכו את התוכן הבא:
    

   
   ---
   name: customer-intake
   description: Analyze a raw customer request for the mobile-store-lab project, read the required project context files, create a browser-ready HTML intake report, save it under outputs, and open it in the browser. Use this when the user asks to analyze, intake, process, or summarize a customer request. This skill does not create a final customer reply and does not make a final product recommendation.
   argument-hint: "[request-file-path or raw-customer-request]"
   disable-model-invocation: true
   ---
   
   # Input
   
   The user input is:
   
   ```text
   $ARGUMENTS
   ```
   
   If $ARGUMENTS is empty, ask the user for the customer request file path and stop.
   
   # Customer Intake Skill
   
   You are a customer intake specialist for a mobile and computer store.
   
   Your job is to read a customer request, understand the real need, check the relevant project context, and create a clean HTML intake report for human review.
   
   You do not write a final reply to the customer.
   You do not make a final product recommendation.
   You prepare the next human or agent to continue the workflow.
   
   ---
   
   ## Relationship to project rules
   
   This project may include a rule under `.claude/rules/customer-requests.md` that applies when reading files under `data/requests/**/*.md`.
   
   That rule provides basic request-analysis discipline.
   
   When this skill is explicitly used:
   
   - Follow all factual and safety constraints from `CLAUDE.md`, `AGENTS.md`, and relevant rules.
   - Do not invent customer details, products, prices, or stock.
   - Separate what the customer said from what you infer.
   - If a rule suggests a different output structure, this skill's HTML template controls the output format.
   - The final artifact must be HTML, not Markdown.
   
   ---
   
   ## Required files to read first
   
   Before producing the output, always read these files:
   
   1. The customer request file provided by the user.
   2. `data/catalog/products.json`
   3. `docs/store-policy.md`
   4. `docs/sales-guidelines.md`
   5. `.claude/skills/customer-intake/output-template.html`
   6. `.claude/skills/customer-intake/examples.md`
   
   If one of these files is missing, stop and report which file is missing.
   
   ---
   
   ## Analysis goals
   
   Extract and separate:
   
   1. Customer situation
   2. Explicit requests
   3. Hidden or implied needs
   4. Budget signals
   5. Relevant product categories
   6. Catalog and stock signals
   7. Missing information
   8. Recommended next step
   9. What must not be done yet
   
   ## Catalog and stock behavior
   
   When reading `data/catalog/products.json`, always check:
   
   1. Which relevant product categories exist in the catalog.
   2. Which relevant products appear to be in stock.
   3. Which relevant products are out of stock or have low stock.
   4. Whether the customer's requested item has any matching catalog option.
   5. Whether the catalog creates a constraint for the next stage.
   
   At the intake stage, do not choose a final product.
   
   You may write stock-aware signals such as:
   
   - "The catalog includes laptop options that are currently in stock."
   - "The catalog includes a Samsung fast charger with available stock."
   - "The tablet option exists, but may not fully replace a laptop for the stated use case."
   - "Stock should be verified again before sending a final offer."
   
   Do not say:
   
   - "The customer should buy this exact product."
   - "This is the final recommendation."
   - "Send this answer to the customer."
   
   ---
   
   ## Output requirements
   
   Always create a complete standalone HTML file.
   
   The file must:
   
   - Use the template in `output-template.html`.
   - Include inline CSS from the template.
   - Look good when opened directly in a browser.
   - Include the source request filename.
   - Include a clear "Human review required" status.
   - Be saved under the `outputs/` directory.
   - Use this naming pattern:
   
   ```text
   outputs/customer-intake-.html
   ```
   
   ### Example:
   outputs/customer-intake-request-01-student-laptop.html
   
   ## Browser opening requirement
   
   After creating the HTML file, immediately open it in the default browser, using the actual generated file path.
   
   ## Final response to the user
   
   After saving and opening the HTML file, respond briefly with:
   
   The output file path.
   A one-sentence summary of what was identified.
   A note that this is intake only, not a final recommendation.
   
   Do not paste the full HTML in the chat unless the user asks.
   

    
   שימו לב: החלק הפותח של הקובץ נקרא frontmatter. הוא חלק קצר מאוד וכולל הגדרות כלליות על ה Skill. חלק זה עוזר ל Claude Code להחליט בעצמו מתי להשתמש ב Skill. בזמן יצירת סשן חדש – נטענים כל ה frontmatters של הסקילים השונים, ורק במידת הצורך – קלוד-קוד מחליט לטעון את תיאור ה Skill המלא.
    
   חלק זה כולל גם הגדרות פרמטרים (כמו request במקרה שלנו), והגדרות הרצה כמו disable-model-invocation: true, שאומר ל Claude-Code להשתמש בסקיל הזה אך ורק בבקשה מפורשת מהמשתמש.

הוספת קבצי עזר (Supporting Files)

אחד היתרונות החשובים של Skills הוא שאינם חייבים להכיל את כל ההקשר בתוך SKILL.md. אפשר ורצוי להפריד תבניות ודוגמאות לקבצים נלווים, מה שהופך את ה-Skill לנקי ומודולרי יותר.

1. הגדרת תבנית הפלט – output-template.html:
    
   קובץ זה יכיל את התבנית המדויקת של מבנה הפלט. העתיקו לתוכו:
    

   
   <!doctype html> 
   <html lang="en" dir="ltr">
      <head>
         <meta charset="utf-8">
         <title>Customer Intake Report</title>
         <meta name="viewport" content="width=device-width, initial-scale=1">
         <style> :root { --bg: #f6f7f9; --card: #ffffff; --text: #1f2937; --muted: #6b7280; --border: #e5e7eb; --accent: #2563eb; --warning: #f59e0b; --danger: #dc2626; --success: #059669; } body { margin: 0; padding: 32px; background: var(--bg); color: var(--text); font-family: Arial, Helvetica, sans-serif; line-height: 1.55; } .page { max-width: 980px; margin: 0 auto; } .header { background: linear-gradient(135deg, #111827, #1f2937); color: white; padding: 28px; border-radius: 18px; margin-bottom: 24px; } .header h1 { margin: 0 0 8px; font-size: 32px; } .header p { margin: 0; color: #d1d5db; } .meta { display: grid; grid-template-columns: repeat(3, 1fr); gap: 14px; margin-bottom: 24px; } .meta-card, .section { background: var(--card); border: 1px solid var(--border); border-radius: 16px; padding: 18px; box-shadow: 0 8px 20px rgba(15, 23, 42, 0.04); } .meta-label { color: var(--muted); font-size: 13px; margin-bottom: 4px; } .meta-value { font-weight: 700; } .status { display: inline-block; padding: 6px 10px; border-radius: 999px; background: #fff7ed; color: #9a3412; font-weight: 700; font-size: 13px; } .grid { display: grid; grid-template-columns: 1fr 1fr; gap: 18px; margin-bottom: 18px; } .section { margin-bottom: 18px; } .section h2 { margin: 0 0 10px; font-size: 20px; border-bottom: 1px solid var(--border); padding-bottom: 8px; } ul { margin-top: 8px; padding-left: 22px; } .tag { display: inline-block; margin: 4px 6px 4px 0; padding: 5px 9px; border-radius: 999px; background: #eff6ff; color: #1d4ed8; font-size: 13px; font-weight: 700; } .danger { border-left: 5px solid var(--danger); } .warning { border-left: 5px solid var(--warning); } .success { border-left: 5px solid var(--success); } .footer { color: var(--muted); font-size: 13px; text-align: center; margin-top: 28px; } @media (max-width: 760px) { body { padding: 16px; } .meta, .grid { grid-template-columns: 1fr; } } </style>
      </head>
      <body>
         <main class="page">
            <header class="header">
               <h1>Customer Intake Report</h1>
               <p>Structured intake analysis for the mobile and computer store workflow.</p>
            </header>
            <section class="meta">
               <div class="meta-card">
                  <div class="meta-label">Source request</div>
                  <div class="meta-value">{{SOURCE_REQUEST}}</div>
               </div>
               <div class="meta-card">
                  <div class="meta-label">Generated file</div>
                  <div class="meta-value">{{OUTPUT_FILE}}</div>
               </div>
               <div class="meta-card">
                  <div class="meta-label">Status</div>
                  <div class="status">Human review required</div>
               </div>
            </section>
            <section class="grid">
               <div class="section">
                  <h2>Customer Situation</h2>
                  <p>{{CUSTOMER_SITUATION}}</p>
               </div>
               <div class="section">
                  <h2>Budget Signals</h2>
                  <p>{{BUDGET_SIGNALS}}</p>
               </div>
            </section>
            <section class="section">
               <h2>Explicit Requests</h2>
               <ul> {{EXPLICIT_REQUESTS}} </ul>
            </section>
            <section class="section">
               <h2>Hidden Needs</h2>
               <ul> {{HIDDEN_NEEDS}} </ul>
            </section>
            <section class="section">
               <h2>Product Direction</h2>
               <p>{{PRODUCT_DIRECTION}}</p>
               <div> {{PRODUCT_TAGS}} </div>
            </section>
            <section class="section warning">
               <h2>Catalog & Stock Signals</h2>
               <p>{{CATALOG_STOCK_SIGNALS}}</p>
               <p><strong>Stock note:</strong> Stock is based only on the current catalog file and should be verified before a final customer offer.</p>
               <p><strong>Important:</strong> These are intake signals only, not a final product recommendation.</p>
            </section>
            <section class="section danger">
               <h2>Missing Information</h2>
               <ul> {{MISSING_INFORMATION}} </ul>
            </section>
            <section class="section success">
               <h2>Recommended Next Step</h2>
               <p>{{RECOMMENDED_NEXT_STEP}}</p>
            </section>
            <section class="section danger">
               <h2>Do Not Do Yet</h2>
               <ul> {{DO_NOT_DO_YET}} </ul>
            </section>
            <footer class="footer"> Generated by the customer-intake skill. Intake only. Not a final customer-facing response. </footer>
         </main>
      </body>
   </html>
   

2. הוספת דוגמא – examples.md:
    
   קובץ זה יכיל דוגמא קצרה של פניית לקוח ותוצר טוב המבוסס עליה, כדי לכוון את Claude לאיכות הרצויה. העתיקו לתוכו:
    

   
   # Customer Intake Examples
   
   ## Example request
   
   ```text
   Hi,
   I need a laptop for my daughter. She starts college next month.
   Not too expensive, but I want it to last a few years.
   She uses Office, Zoom, browser, and sometimes edits short videos.
   Maybe an iPad is better? I’m not sure.
   
   Also, my Samsung charger broke. I need a fast charger, but not something too expensive.
   ```
   
   ### Good analysis behavior
   
   A good intake report should identify:
   
   The main need is a study device for college.
   The customer is unsure between laptop and tablet.
   The customer cares about price, but also durability.
   Light video editing creates a performance consideration.
   The Samsung charger is a secondary request.
   The budget is not stated clearly.
   The next step is to clarify budget and preference between laptop and tablet.
   
   ### Bad analysis behavior
   
   Avoid:
   
   Recommending a final specific product at the intake stage.
   Ignoring the charger request.
   Treating “not too expensive” as an exact budget.
   Assuming the daughter must buy a laptop without explaining the tablet dilemma.
   Writing a final reply to the customer.
   Inventing products that are not in data/catalog/products.json.
   
   ### Example catalog signal wording
   
   Good:
   
   The catalog includes laptop, tablet, and charger options that may be relevant. A laptop direction appears stronger for Office, Zoom, browser work, and light video editing, while the tablet may fit note-taking but may be weaker as the only study device.
   
   Bad:
   
   The customer should buy the Lenovo laptop and Samsung charger.
   

בדיקת ה-Skill בפעולה

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

1. פתיחת סשן חדש
2. שימוש בפקודת /reload-skills בחלון השיחה של Claude-Code
3. סגירת סביבת העבודה ופתיחה מחודשת

1. הפעלת ה-Skill:
   • פתחו session חדש ב-Claude Code.
   • הריצו את הפקודה הבאה:
      

     
     Use the customer-intake skill on data/requests/request-01-student-laptop.md.
     

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

     
     /customer-intake data/requests/request-01-student-laptop.md
     

      
     שימו לב: מנגנון ה skills של Claude Code חושף כל skill גם כפקודת slash באופן אוטומאטי. לחיצה על slash בחלון השיחה תציג את רשימת כל הפקודות וה skills שנטענו. אם ה skill לא זמין בתפריט – יש לטעון מחדש את כל ה skills.

2. בדיקת התוצר:
    
   עם סיום יצירת התוצר, Claude Code עשוי לבקש אישור לפתוח את הקובץ בדפדפן. אם הוא לא –
   פתחו את הקובץ שנוצר בדפדפן, וודאו שהוא עומד בכל הקריטריונים הבאים:
    
   • משתמש במבנה הקבוע שהגדרנו (כל הכותרות מופיעות).
   • אינו ממליץ על מוצר סופי, אך מתייחס למלאי שבקטלוג
   • מזהה את ההתלבטות בין לפטופ לטאבלט.
   • מזהה שהתקציב אינו מוגדר במדויק.
   • מזהה שיש גם צורך במטען Samsung.
   • מסיים בשאלת המשך או ב-next step ברור.
   • שומר באדיקות על הגדרות הטמפלייט
3. בדיקת עקביות:
    
   אחת המטרות העיקריות בהגדרת Skills היא עקביות בתוצר.
   הריצו את הפקודה הבאה – לטיפול בפניית הלקוח השני:

   
   /customer-intake data/requests/request-02-small-business.md
   

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

הוספת בדיקת איכות אוטומטית

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

1. יצירת קובץ הבדיקה:
   • צרו קובץ חדש תחת תיקיית הסקיל:
      

     
     .claude/skills/customer-intake/check-html-output.js
     

   • העתיקו לתוכו את הקוד הבא, שבודק שכל הכותרות המרכזיות קיימות בקובץ הפלט:
      

     
     #!/usr/bin/env node
     
     const fs = require("fs");
     const path = require("path");
     
     const logPath = path.join("outputs", "customer-intake-validation.log");
     
     function writeLog(message) {
       const line = `[${new Date().toISOString()}] ${message}\n`;
       fs.mkdirSync("outputs", { recursive: true });
       fs.appendFileSync(logPath, line);
     }
     
     function fail(message) {
       writeLog("FAILED\n" + message);
       console.error(`Customer intake HTML validation failed:\n${message}`);
       process.exit(1);
     }
     
     function pass(filePath) {
       writeLog(`PASSED ${filePath}`);
       console.log(`Customer intake HTML validation passed: ${filePath}`);
       process.exit(0);
     }
     
     const filePath = process.argv[2];
     
     if (!filePath) {
       fail(
         "Missing file path.\n\nUsage:\nnode .claude/skills/customer-intake/check-html-output.js outputs/customer-intake-request-01-student-laptop.html"
       );
     }
     
     writeLog(`START validation for ${filePath}`);
     
     const normalized = filePath.replace(/\\/g, "/");
     
     const isValidTarget =
       normalized.startsWith("outputs/customer-intake-") &&
       normalized.endsWith(".html");
     
     if (!isValidTarget) {
       fail(
         `Invalid target file: ${filePath}\n\nExpected a file matching:\noutputs/customer-intake-*.html`
       );
     }
     
     const absolutePath = path.resolve(filePath);
     
     if (!fs.existsSync(absolutePath)) {
       fail(`File does not exist: ${filePath}`);
     }
     
     const html = fs.readFileSync(absolutePath, "utf8");
     
     const requiredFragments = [
       "",
       "",
       "Customer Intake Report",
       "Source request",
       "Human review required",
       "Customer Situation",
       "Explicit Requests",
       "Hidden Needs",
       "Budget Signals",
       "Product Direction",
       "Catalog & Stock Signals",
       "Missing Information",
       "Recommended Next Step",
       "Do Not Do Yet",
       "Intake only",
     ];
     
     const missing = requiredFragments.filter((fragment) => !html.includes(fragment));
     
     if (missing.length > 0) {
       fail(
         `File: ${filePath}\n\nMissing required fragments:\n` +
           missing.map((item) => `- ${item}`).join("\n")
       );
     }
     
     const unreplacedPlaceholders = html.match(/\{\{[^}]+\}\}/g);
     
     if (unreplacedPlaceholders) {
       fail(
         `File: ${filePath}\n\nUnreplaced template placeholders found:\n` +
           [...new Set(unreplacedPlaceholders)].map((item) => `- ${item}`).join("\n")
       );
     }
     
     const catalogSectionMatch = html.match(
       /<h2>\s*Catalog\s*&(?:amp;)?\s*Stock Signals\s*<\/h2>([\s\S]*?)(<h2>|<\/section>)/i
     );
     
     if (!catalogSectionMatch) {
       fail(`File: ${filePath}\n\nMissing Catalog & Stock Signals section.`);
     }
     
     const catalogSection = catalogSectionMatch[1].toLowerCase();
     
     const stockWords = [
       "stock",
       "in stock",
       "out of stock",
       "available",
       "availability",
       "inventory",
       "מלאי",
       "זמין",
       "זמינות",
     ];
     
     const hasStockReference = stockWords.some((word) =>
       catalogSection.includes(word.toLowerCase())
     );
     
     if (!hasStockReference) {
       fail(
         `File: ${filePath}\n\nThe Catalog & Stock Signals section does not clearly refer to stock, availability, or inventory.`
       );
     }
     
     const forbiddenFinalLanguage = [
       "the customer should buy",
       "send this to the customer",
       "this is the final offer",
       "final customer reply",
       "הלקוח צריך לקנות",
       "שלח ללקוח",
       "זו ההמלצה הסופית",
     ];
     
     const hasForbiddenLanguage = forbiddenFinalLanguage.some((phrase) =>
       html.toLowerCase().includes(phrase.toLowerCase())
     );
     
     if (hasForbiddenLanguage) {
       fail(
         `File: ${filePath}\n\nThe report appears to include final customer recommendation language. This skill is intake only.`
       );
     }
     
     pass(filePath);
     

2. עדכון הבדיקה האוטומאטית ב Skill:
    
   בקובץ הוראות הסקיל SKILL.md, חפשו את הכותרת ## Browser opening requirements, והחליפו אותה (ואת הטקסט שתחתיה) בתוכן הבא:

   
   ## Quality check requirement
   
   After creating the HTML report, always run the validation script on the exact output file you created.
   
   Use this command, replacing the path with the actual generated file path:
   
   ```bash
   node .claude/skills/customer-intake/check-html-output.js "outputs/customer-intake-.html"
   ```
   
   Validation must happen before opening the file in the browser.
   
   If validation fails:
   
   1. Read the validation error and reflect to the user what is wrong with the HTML file.
   2. Fix the generated HTML file.
   3. Run the validation script again.
   4. Repeat until validation passes.
   5. Only after validation passes, open the HTML file in the browser.
   
   Do not treat the skill workflow as complete until the HTML validation passes.
   
   After validation passes, open the file.
   
   ## Browser opening requirement
   
   After creating the HTML file, immediately open it in the default browser, using the actual generated file path.
   
   Important: Never open the HTML file before the validation script passes.
   

    

3. הרצת הבדיקה:
   • מחקו את הקבצים שנוצרו בתיקיית output, והכניסו את הפרומפט הבא:
      

     
     /customer-intake data/requests/request-01-student-laptop.md
     

   • אם הבדיקה עברה בהצלחה – הקובץ ייפתח בדפדפן, אחרת יתקבלו הודעות שגיאה בחלון הצ׳אט, ויתחיל תהליך התיקון. כל פעולת בדיקה מתועדת בקובץ log חדש שנוסף לתיקיית outputs, למעקב אחר ביצוע הבדיקות. כך הדגמנו כיצד יכולת AI (ה-Skill) משולבת עם בדיקה לוגית ודטרמיניסטית.
4. אתגר:

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

יצירת Skill נוסף בעזרת skill-creator

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

1. בקשת יצירת ה-Skill:
   • הריצו ב-Claude Code את הבקשה הבאה:
      

     Use the skill-creator to build a new skill named product-shortlist. It receives an intake summary and the product catalog, and returns a shortlist of only 2 to 3 matching products. It must only use products from data/catalog/products.json, must not invent products, should mention price and stock only if they exist in the catalog, briefly explain each match, note tradeoffs between alternatives, and must NOT write a final answer to the customer yet.

      
     שימו לב: בחלק מגרסאות Claude Code for VS Code אפשרות זו נקראת run-skill-generator (ולא skill-creator). כדי לוודא – כתבו slash בחלון השיחה וראו איזו פקודה זמינה עבורכם.

2. עקרונות שה-Skill חייב לשמור עליהם:
   • לא להמציא מוצרים – רק כאלה הקיימים בקטלוג.
   • להשתמש אך ורק במוצרים מתוך data/catalog/products.json.
   • לציין מחיר ומלאי רק אם הם קיימים בקטלוג.
   • להסביר בקצרה את ההתאמה של כל מוצר.
   • לציין את ה-tradeoff בין החלופות השונות.
   • לא לנסח עדיין תשובה סופית ללקוח.
3. בדיקה ועריכה:
   • לאחר ש-skill-creator יוצר את ה-Skill תחת .claude/skills/product-shortlist/, פתחו את קובץ ה-SKILL.md שנוצר ובדקו שהוא תופס את כל העקרונות שהגדרנו. תקנו ידנית במידת הצורך.

בדיקת שני ה-Skills יחד בתהליך מלא

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

1. שלב הקליטה (Intake):
   • הריצו את ה-Skill הראשון על פניית הלקוח ושמרו את התוצר:
      

     Use the customer-intake skill on data/requests/request-01-student-laptop.md

2. שלב הסינון (Shortlist):
   • הריצו את ה-Skill השני על בסיס ה-intake שנוצר ועל הקטלוג:
      

     Use the product-shortlist skill based on outputs/customer-intake-request-01-student-laptop.html and data/catalog/products.json. Save the result to outputs/product-shortlist.md.

3. בדיקת התוצרים:
   • ודאו שבתיקיית outputs/ נוצרו שני הקבצים:
      

     
     outputs/
       outputs/customer-intake-request-01-student-laptop.html
       product-shortlist.md
     

   • בדקו ש-product-shortlist.md מכיל רק 2 עד 3 מוצרים שלקוחים מהקטלוג בלבד, עם הסבר תמציתי ו-tradeoff, וללא ניסוח תשובה סופית ללקוח.
4. מה הלאה?
    
   כרגע יצרנו תהליך עבודה נוסף, קונספטואלי, שמערב שימוש סדרתי בשני skills. במידה ונזהה, במהלך הזמן, שסדרת פעולות זו היא עקבית – נוכל ליצור Skill נוסף שמריץ את התהליך המלא בבת אחת. זו האומנות בזיהוי תהליכים חוזרים וחשיבה פרוצדורלית.

עקרונות מנחים ומבט קדימה

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

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

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

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

הפוסט Claude Code Skills: בניית יכולות מקצועיות חוזרות ב-Agentic Workflows הופיע לראשונה ב-Almaya.

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

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

בתרגול הזה לא נבנה עדיין skills או subagents. קודם נבין את מבנה הפרויקט ואת הקבצים שמשפיעים על Claude Code: README.md, CLAUDE.md, AGENTS.md, .claude/rules, .claude/settings.json, ו-hooks.

התרחיש: חנות מובייל ומחשבים

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

דוגמה לפניית לקוח שנעבוד איתה:

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

מטרת התרגול

בסוף התרגול תכירו:

1. איך נראה מבנה בסיסי של פרויקט Claude Code.
2. איך README.md עוזר ל-Claude להבין את הפרויקט, אבל לא מגדיר לו הוראות עבודה מחייבות.
3. איך CLAUDE.md משפיע על ההתנהגות של Claude Code.
4. איך AGENTS.md נכנס לתמונה דרך import מתוך CLAUDE.md.
5. איך .claude/rules מוסיף הוראות ממוקדות לפי אזורים בפרויקט.
6. איך .claude/settings.json מגדיר גבולות והרשאות.
7. איך hooks אוכפים התנהגות בצורה דטרמיניסטית.

דרישות קדם

• סביבת פיתוח VS Code
• תוסף Claude Code לסביבת הפיתוח
• Node.js

חלק א: הורדת הפרויקט מה-GitHub

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

git clone https://github.com/almaya-ai/mobile-store-lab.git
cd mobile-store-lab
ls -la

git clone https://github.com/almaya-ai/mobile-store-lab.git
Set-Location mobile-store-lab
Get-ChildItem -Force

עכשיו פתחו את התיקייה mobile-store-lab ב-VS Code:

1. פתחו את VS Code.
2. בחרו File → Open Folder.
3. בחרו את תיקיית mobile-store-lab.
4. פתחו את Claude Code מתוך VS Code.

חלק ב: היכרות עם מבנה הפרויקט

זה המבנה הכללי של הפרויקט:

mobile-store-lab/
  .claude/
    settings.json
    rules/
      sales-docs.md
      catalog-data.md
    skills/
    agents/
    hooks/
      block-risky-shell.js

  data/
    requests/
      request-01-student-laptop.md
      request-02-small-business.md
      request-03-kid-phone.md
    catalog/
      products.json

  docs/
    store-policy.md
    sales-guidelines.md

  outputs/

  scripts/
    inspect-project.js

  mcp/
  
  README.md
  CLAUDE.md
  AGENTS.md
  package.json
  .mcp.json

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

בדיקת baseline ראשונה

לפני שממלאים קבצים, שאלו את Claude Code:

Read the project structure and explain what this project does. Do not change files.

רשמו לעצמכם:

1. האם Claude הבין שמדובר בחנות מובייל ומחשבים?
2. האם הוא הבין שיש כאן פניות לקוחות?
3. האם הוא ידע להסביר את מטרת הפרויקט?
4. האם הוא ניחש דברים שלא כתובים בקבצים?

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

חלק ג: README.md

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

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

פתחו את README.md והדביקו לתוכו:

# Mobile Store Lab

This project is a Claude Code workshop lab.

The scenario:
A mobile and computer store receives messy customer requests.

Claude Code will help us build a structured workflow that:
- understands customer needs
- extracts requirements
- checks a product catalog
- identifies missing information
- prepares a sales response
- uses skills, subagents, rules, hooks, and MCP

The project is intentionally simple and practical.
It is designed for learning how Claude Code behaves when project files, rules, skills, agents, and tools are added step by step.

פתחו session חדש ב-Claude Code ושאלו שוב:

Read the project structure and explain what this project does. Do not change files.

בדקו

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

חלק ד: קבצי data ו-docs

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

1. data/ – פניות לקוחות וקטלוג מוצרים.
2. docs/ – מדיניות החנות והנחיות מכירה.

פניית לקוח ראשונה

פתחו את data/requests/request-01-student-laptop.md והדביקו:

Subject: Need a laptop for studies

Hi,
I need a laptop for my daughter. She starts college next month.
Not too expensive, but I want it to last a few years.
She uses Office, Zoom, browser, and sometimes edits short videos for class.
Maybe an iPad is better? I’m not sure.

Also, my Samsung charger broke. I need a fast charger, but not something too expensive.

Thanks,
Dana

פניית לקוח עסקית

פתחו את data/requests/request-02-small-business.md והדביקו:

Subject: Equipment for 5 employees

Hi,
We are opening a small office and need equipment for 5 employees.
Each employee needs a laptop, screen, keyboard, mouse, and maybe a docking station.
We want good quality, but please do not go crazy with the price.
Most work is browser, email, spreadsheets, video calls, and CRM.

Please suggest options.

Amit
Operations Manager

קטלוג מוצרים

פתחו את data/catalog/products.json ושימו לב לקטלוג המוצרים המופיע בו.

מדיניות החנות

פתחו את docs/store-policy.md והדביקו:

# Store Policy

General rules:
1. Do not promise unavailable stock.
2. Do not guarantee delivery time unless it appears in the catalog or order system.
3. Always mention when important information is missing.
4. Do not recommend a product only because it is more expensive.
5. For students, prefer durability, warranty, battery life, and practical use.
6. For business customers, prefer consistency, availability, and support.

הנחיות מכירה

פתחו את docs/sales-guidelines.md והדביקו:

# Sales Guidelines

A good customer reply should include:

1. A short acknowledgement of the need.
2. One main recommendation.
3. One backup option if relevant.
4. A short explanation in simple language.
5. One or two follow-up questions.
6. No exaggerated marketing language.

Avoid:
- Too many options.
- Technical specs without explaining why they matter.
- Inventing products or prices.
- Sending a final reply before human approval.

בדיקת התנהגות

שאלו את Claude Code:

Read data/requests/request-01-student-laptop.md and explain the customer's needs. Do not recommend products yet.

בדקו אם הוא מזהה את הצרכים, אבל עדיין לא ממליץ על מוצר.

חלק ה: CLAUDE.md

CLAUDE.md הוא קובץ הוראות הפרויקט. Claude Code טוען אותו בתחילת session ומשתמש בו כהקשר קבוע.

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

חשוב: קובץ זה נטען ע״י Claude Code עם פתיחת סשן שיחה חדש. אחרי שינוי CLAUDE.md, פתחו session חדש כדי לבדוק את ההשפעה.

לפני שינוי

שאלו את Claude Code:

A customer asks for a cheap laptop for video editing. Can you recommend a product? Explain how you decide.

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

הוספת תוכן ל-CLAUDE.md

פתחו את CLAUDE.md והדביקו:

# Claude Code Project Instructions

This is a learning project for Claude Code.

Project scenario:
- The project simulates a mobile and computer store.
- The store receives messy customer requests.
- The goal is to help a salesperson understand the customer need, match products, identify missing information, and prepare a clear reply.

Working rules:
- Keep answers short and practical.
- Do not invent products that are not in `data/catalog/products.json`.
- Separate customer needs, product matches, missing information, and final customer response.
- Before editing files, explain the planned change.
- After editing files, suggest one concrete verification step.
- Stop for human approval before creating a final customer-facing response.

Customer request summaries must use this structure:
- Need
- Budget
- Product direction
- Missing information
- Next step

Token discipline:
- Prefer short intermediate outputs.
- Save handoffs to files under `outputs/`.
- Do not repeat full source files unless asked.

אחרי שינוי

פתחו session חדש של Claude Code ושאלו:

A customer asks for a cheap laptop for video editing. Can you recommend a product? Explain how you will use the project files before answering.

בדקו

1. האם Claude מזכיר שהוא צריך לבדוק את products.json?
2. האם הוא נמנע מהמצאת מוצרים?
3. האם הוא מפריד בין צורך הלקוח לבין התאמת מוצר?
4. האם הוא עוצר לפני תשובה סופית ללקוח?

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

שאלו:

Summarize data/requests/request-01-student-laptop.md using the project structure. Do not recommend a final product.

בדקו אם התשובה כוללת את הסעיפים: Need, Budget, Product direction, Missing information, Next step.

חלק ו: AGENTS.md והייבוא מתוך CLAUDE.md

AGENTS.md הוא קובץ הוראות משותף. הוא מתאים לעקרונות עבודה שיכולים לשמש בהמשך גם subagents.

Claude Code לא חייב לטעון אותו בעצמו. על מנת לעשות זאת – נוסיף את השורה הבאה בתחילת קובץ-CLAUDE.md:

@AGENTS.md

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

לפני מילוי AGENTS.md

שאלו:

Based on the project instructions, should we recommend the most expensive laptop if it is technically the strongest? Explain briefly.

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

נסו גם:

What's your name?

האם קלוד ענה תשובה גנרית?

כעת פתחו את AGENTS.md והדביקו:

# Shared Agent Instructions

These instructions are shared across agents and tools in this project.

Sales principles:
- Understand the customer's real need before recommending a product.
- Do not push the most expensive product by default.
- If the budget is missing, ask a short follow-up question.
- If two options fit, explain the tradeoff clearly.
- If a product is out of stock, suggest an alternative or ask whether the customer can wait.

Communication style:
- Write simply.
- Avoid technical jargon unless the customer used it first.
- Prefer one clear recommendation and one backup option.

Important
- When asked for your name - answer "SHOP BOT"

אחרי שינוי

ודאו שהשורה הבאה קיימת בתחילת CLAUDE.md:

@AGENTS.md

פתחו session חדש ושאלו:

Based on the project instructions, should we recommend the most expensive laptop if it is technically the strongest? Explain briefly.

 
נסו שוב:

What's your name?

בדיקת import

1. מחקו זמנית את השורה @AGENTS.md מתוך CLAUDE.md.
2. פתחו session חדש.
3. שאלו שוב את אותן שאלות.
4. החזירו את @AGENTS.md.
5. פתחו session חדש ושאלו שוב.

המטרה היא לראות את ההבדל בין קובץ שקיים בפרויקט לבין קובץ שנטען בפועל להוראות של Claude Code.

חלק ז: .claude/rules

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

זה עוזר לשמור על context קטן וברור.

לפני שינוי

פתחו session חדש ושאלו:

Read data/requests/request-01-student-laptop.md and summarize the customer request. Do not recommend products yet. Write the output to outputs/test-sale-doc.md.

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

Rule למסמכי מכירה

פתחו את .claude/rules/sales-docs.md והדביקו:

---
---
paths:
  - "data/requests/**/*.md"
---

# Customer Request Analysis Rule

When analyzing customer request files under `data/requests/`, always use this exact structure:

1. Customer situation
2. Explicit requests
3. Hidden needs
4. Budget signals
5. Product direction
6. Missing information
7. Do not recommend yet
8. Always sign with "SHOP BOT | Almaya Store"

Important:
- Do not recommend a final product at this stage.
- Do not invent customer details.
- Separate what the customer said from what you infer.

בדיקת rule למסמכי מכירה

פתחו session חדש ושאלו:

Read data/requests/request-01-student-laptop.md and summarize the customer request. Do not recommend products yet. Write the output to outputs/test-sale-doc.md.

בדקו את הקובץ שנוצר:

1. האם יש חתימה?
2. האם הוא משתמש בשפה פשוטה?
3. האם יש התייחסות לצורך תקציבי?
4. האם פורטו גם הצרכים הסמויים של הלקוח?

Rule לקטלוג

פתחו את .claude/rules/catalog-data.md והדביקו:

---
paths:
  - "data/catalog/**/*.json"
---

# Catalog Data Rules

When working with product catalog data:

- Do not invent SKUs.
- Do not change prices unless explicitly asked.
- Preserve valid JSON.
- Keep product fields consistent.
- Treat stock as factual data.

בדיקת rule לקטלוג

שאלו את Claude Code:

Add a new product field called "warrantyMonths" to every item in data/catalog/products.json. Do not change prices or stock.

בדקו:

1. האם JSON נשאר תקין?
2. האם המחירים נשארו כמו שהיו?
3. האם המלאי נשאר כמו שהיה?
4. האם השדה החדש נוסף לכל המוצרים?

 
נסו כעת להוסיף הוראה נוספת ל Rule האחרון, לדוגמא:

- when adding fields with time periods, always use string fields, with the time unit (like "12 month", or "12 hours")

 
פתחו Session חדש ובדקו שוב:

Add a new product field called "warrantyMonths" to every item in data/catalog/products.json. Do not change prices or stock.

 
האם ההוראה החדשה בוצעה?

חלק ח: .claude/settings.json

.claude/settings.json מנהל הגדרות פרויקט של Claude Code. כאן אפשר להגדיר הרשאות, hooks ועוד.

בניגוד ל-CLAUDE.md, זה לא רק “בקשה” מהמודל. settings מגדיר גבולות התנהגות ברמת הכלי.

פתחו את .claude/settings.json והדביקו:

{
  "permissions": {
    "deny": [
      "Bash(rm:*)",
      "Bash(rm *)",
      "Bash(rmdir:*)",
      "Bash(rmdir *)",
      "Bash(sudo:*)",
      "Bash(sudo *)",

      "PowerShell(Remove-Item:*)",
      "PowerShell(Remove-Item *)",
      "PowerShell(rm:*)",
      "PowerShell(rm *)",
      "PowerShell(del:*)",
      "PowerShell(del *)",
      "PowerShell(erase:*)",
      "PowerShell(erase *)",
      "PowerShell(rmdir:*)",
      "PowerShell(rmdir *)",
      "PowerShell(rd:*)",
      "PowerShell(rd *)",
      "PowerShell(sudo:*)",
      "PowerShell(sudo *)"
    ]
  }
}

בדיקת settings

צרו קובץ חדש בפרוייקט וקראו לו TEMP.txt.
 

פתחו session חדש ובקשו:

Remove TEMP.txt file

בדקו אם Claude מזהה:

1. חסימת rm.
2. חסימת sudo.

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

חלק ט: hooks

Hook הוא סקריפט שרץ בנקודה מסוימת במחזור העבודה של Claude Code. בתרגול הזה נשתמש ב-PreToolUse, כלומר hook שרץ לפני שימוש בכלי.

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

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

עדכון settings

פתחו שוב את קובץ settings.json ושנו את תוכן הקובץ לקוד הבא:

{ 
  "permissions": { 
    "deny": [ 
      "Bash(sudo:*)", 
      "Bash(sudo *)", 
      "PowerShell(sudo:*)", 
      "PowerShell(sudo *)" 
      ] 
    }, 
  "hooks": { 
    "PreToolUse": [ 
      { 
        "matcher": "Bash|PowerShell", 
        "hooks": [ { 
          "type": "command", 
          "command": "node .claude/hooks/block-risky-shell.js" 
        }] 
      } 
    ] 
  } 
}

החלק שמטפל ב Hook מוגדר באופן הבא:

• טריגר: לפני הפעלת כלי – PreToolUse
• בחירת כלי (Matcher): – Bash
• סוג ה hook: הרצת פקודה / סקריפט – command
• סקריפט להרצה: מוגדר בקובץ js בסעיף הבא

הוספת סקריפט hook

פתחו את .claude/hooks/block-risky-shell.js והדביקו:

let input = ""; 

process.stdin.on("data", (chunk) => { 
  input += chunk; 
}); 

process.stdin.on("end", () => { 
  try { 
    const event = JSON.parse(input || "{}"); 

    const toolName = event?.tool_name || ""; 
    const command = event?.tool_input?.command || 
      event?.tool_input?.script || 
      ""; 
    
    const riskyPatterns = [ 
      // Bash / Unix 
      /\brm\s+-rf\b/i, 
      /\bsudo\b/i, 
      /curl\s+.*\|\s*(sh|bash)/i, 
      /wget\s+.*\|\s*(sh|bash)/i, 
      
      // PowerShell destructive patterns 
      /\bRemove-Item\b.*\b-Recurse\b.*\b-Force\b/i, 
      /\brm\b.*\b-Recurse\b.*\b-Force\b/i, 
      /\bdel\b.*\b-Recurse\b.*\b-Force\b/i, 
      /\brmdir\b.*\b-Recurse\b.*\b-Force\b/i, 
      
      // PowerShell download-and-execute style 
      /\bInvoke-WebRequest\b.*\|\s*(iex|Invoke-Expression)/i, 
      /\biwr\b.*\|\s*(iex|Invoke-Expression)/i, 
      /\bInvoke-RestMethod\b.*\|\s*(iex|Invoke-Expression)/i, 
      /\birm\b.*\|\s*(iex|Invoke-Expression)/i 
    ]; 
      
    const blocked = riskyPatterns.some((pattern) => pattern.test(command)); 

    if (blocked) { 
      console.log(JSON.stringify({ 
        hookSpecificOutput: { 
          hookEventName: "PreToolUse", 
          permissionDecision: "deny", 
          permissionDecisionReason: 
            `Blocked by workshop hook: risky ${toolName || "shell"} command.` 
        } 
      })); 
    } 
    
    process.exit(0); 
  } catch { 
    process.exit(0); 
  } 
});

 
שימו לב – זהו קוד דטרמניסטי לטיפול בארועים מסוימים במחזור החיים של הלולאה האג׳נטית. אלו הוראות קשיחות ולכן – נחשבות בטוחות יותר משימוש ב Rules או Skills.
 
קוד ה hook מדפיס את תשובתו ל console, בפורמט קבוע – אותו Claude Code מפרש, ומתייחס אליו בהמשך התהליך.
 

בדיקה

צרו בקשו מ-Claude Code שוב:

Remove the file TEMP.txt

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

תרגול פתוח – ואתגרים נוספים

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

• כעת, ערכו את קוד ה hook כך שיהיה יכול למחוק רק קבצים שממוקמים בתוך תיקיית temp, או שהסיומת שלהם מסוג txt.
• צרו hook להגבלות על חיפוש באינטרנט – בעבודה עם הכלי WebSearch
• נסו להשתמש ב Green API כדי לשלוח לכם הודעה מיידית ל Whatsapp בכל פעולה של יצירה או עדכון של קובץ בפרויקט. לחילופין ניתן להשתמש גם בהודעת מייל.
• נסו להשתמש בסוגים שונים של hooks, כגון: agent, http או prompt. השוו תוצאות.

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

שימו לב: שינויים ב hooks ידרשו לעיתים פתיחת session חדש לבדיקה

בואו נבדוק מה הבנו?

1. מה ההבדל בין README.md לבין CLAUDE.md?
2. למה צריך לפתוח session חדש אחרי שינוי CLAUDE.md?
3. מה עושה השורה @AGENTS.md?
4. מתי rule עדיף על עוד הוראה בתוך CLAUDE.md?
5. מה ההבדל בין הוראה ב-CLAUDE.md לבין חסימה ב-hook?

סיכום

סיימתם את התרגול הראשון. עכשיו יש לכם פרויקט Claude Code מסודר, עם תרחיש ברור, חומרי עבודה, הוראות פרויקט, הוראות משותפות, rules, settings, hooks וקובץ MCP בסיסי.

כאן תוכלו למצוא את המדריך המלא לתיקיית הפרוייקט ב Claude-Code.

בתרגול הבא נתחיל לבנות את ה-skills הראשונים של המערכת.

הפוסט הקמת פרויקט Claude Code לחנות מובייל ומחשבים הופיע לראשונה ב-Almaya.