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

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

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

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

השינוי קרה בערך 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.

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

בואו נעשה סדר: שתי משמעויות שונות למילה אחת

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

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

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

משמעות ב: תודעה כחוויה סובייקטיבית

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

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

מה קודם למה? תודעה או חומר?

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

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

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

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

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

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

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

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

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

וזה מחזיר אותנו ישירות לבינה מלאכותית.

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

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

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

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

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

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

השאלה שכולם שואלים על AI, ולמה היא כנראה לא נכונה

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

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

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

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

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

האדם שמולי כ"כלי" לתודעה, וה-AI כ"כלי" אחר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השאלה המוסרית: אם אני לא בטוח, איך עליי להתנהג?

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

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

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

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

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

מה זה אומר הלכה למעשה?

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

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

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

שלוש שכבות של שאלה אחת

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

אחרית דבר

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

השאלה שכן שווה לשאול היא: מה עושה ממני האופן שבו אני מתייחס לביטוי שמולי?

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

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

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

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

מה זה בכלל "מוח שני"? ולמה דווקא Fable 5?

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

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

המושגים שחובה להכיר לפני שמתחילים

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

• Markdown: פורמט כתיבה פשוט המבוסס על טקסט נקי. הסיבה שאני משתמש בו – סוכני AI קוראים וכותבים Markdown בקלות ובדיוק, בניגוד ל-PDF או Word שדורשים פרסור מורכב.

 

• YAML / Frontmatter: בלוק של מטא-דאטה (כמו תאריך, תגיות, קטגוריה) שמופיע בראש קובץ Markdown. מעין ״תקציר״ של מה שהולך להופיע בהמשך הקובץ. זה מה שמאפשר לסוכן לקטלג ולחפש מידע בצורה מובנית – כמו כרטיסיית ספרייה דיגיטלית.

 

• MCP (Model Context Protocol): תקן פתוח של Anthropic שמאפשר ל-Claude להתחבר ישירות לקבצים ולכלים חיצוניים במחשב שלכם. בפועל – זה מה שנותן ל-Fable 5 "ידיים" לגעת בתיקיות, לקרוא קבצים ולערוך אותם.

 

• RAG (Retrieval-Augmented Generation): שיטה שבה ה-AI שולף מידע מדויק מתוך הקבצים האישיים שלכם כדי לענות על שאלות, במקום להסתמך רק על הידע הכללי שלו. זה ההבדל בין "Claude שיודע הכל באופן כללי" לבין "Claude שיודע מה כתבתם בסיכום הפגישה של יום שלישי".

שלב 1: ארכיטקטורת ה-LLM Wiki – שלוש השכבות

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

1. שכבת המקורות (Sources)
   • תיקייה שמכילה חומרי גלם גולמיים – תמלולים, מאמרים, קבצי PDF, הערות מפגישות, קטעי פודקאסט מתומללים.
   • חוק ברזל: ה-AI קורא מכאן, אך לעולם לא עורך את הקבצים הללו. אלו המקורות המקוריים, ה"אמת היחידה" (Single Source of Truth) שהמערכת מתבססת עליה.

 

2. שכבת הוויקי (Wiki)
   • כאן קורה הקסם. ה-AI כותב ומעדכן דפי מושגים, ישויות ופרויקטים על בסיס המקורות. אלו "אבני בניין של ידע" – כל דף מתאר מושג, אדם, פרויקט או רעיון אחד, עם קישורים פנימיים לדפים אחרים.
   • הדפים כתובים ב-Markdown עם Frontmatter של YAML – כך ש-Fable 5 יכול לחפש, לסנן ולעדכן אותם באופן אוטומטי. הם מסודרים, קריאים ומקושרים ביניהם בצורה מופלאה.

 

3. שכבת הסכימה (Schema)
   • קובץ בשם CLAUDE.md בשורש התיקייה, שמשמש כ"נתב" (Router) של המערכת כולה.
   • הוא מסביר ל-Fable 5 מי אתם, מה המבנה של התיקיות, מהם חוקי העבודה, ואילו פעולות מותרות ואסורות. בפועל – זה ה-System Prompt שמנהל את כל שאר ההתנהגות.

שלב 2: יישום מודל ה-4C – הפיכת המוח השני למערכת הפעלה

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

1. Context – הקשר

זו ההגדרה של קובץ ה-CLAUDE.md שלכם. ספקו למודל נתיבים מדויקים לתיקיות ה-Wiki וה-Sources, הסבירו את המבנה ההיררכי, והגדירו את "זהותו" ביחס למערכת. Fable 5 זקוק להקשר ברור כדי לא "ללכת לאיבוד" במאגר הידע שלכם. ככל שה-CLAUDE.md מפורט ומדויק יותר, כך ההתנהגות עקבית ואמינה יותר.

2. Connections – חיבורים

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

3. Capabilities – יכולות ומיומנויות

צרו תיקייה בשם .claude/skills ובה קבצי הוראות לפעולות חוזרות. בפועל, אלו "פקודות" שמפעילות רצף עבודה מוגדר:

• /capture – פקודה לקליטת מקור חדש. Fable 5 קורא את החומר הגולמי, מנקה רעשים, מוציא את עיקרי הנקודות, ומתייג אוטומטית עם Frontmatter מתאים.

 

• /sync – עדכון דפי ה-Wiki הקיימים על בסיס מידע חדש שנוסף ל-Sources. המודל סורק את המקורות האחרונים, מזהה מה רלוונטי לדפים קיימים, ומעדכן אותם.

 

• /lint – בדיקת תקינות שבועית. Fable 5 עובר על כל דפי הוויקי, מאתר סתירות לוגיות, קישורים שבורים, מידע מיושן, ומציע תיקונים.

4. Context Discipline – משמעת הקשר

זה אולי הטיפ הכי חשוב: אל תערבבו משימות. עבדו ב"פעימות" (Phases) – סשן למחקר, סשן לטיוטה, סשן לליטוש. Fable 5 מציג ביצועים טובים משמעותית כשהוא ממוקד בשלב עבודה ספציפי, במקום לקפוץ בין מחקר לכתיבה לעריכה באותה שיחה. חשבו על זה כמו ניהול ישיבות – כל ישיבה עם אג'נדה ברורה.

שלב 3: טיפים פרקטיים מהבדיקות שלי עם Fable 5

אחרי שבועות של עבודה עם מודלים אחרים, ושעות רבות על Fable 5, הנה מה שלמדתי – הדברים שעושים את ההבדל בין שימוש "סביר" לבין מערכת שבאמת מביאה ערך משמעותי:

1. השתמשו במיומנות "Grill Me" ("תפור אותי")
   • הנחו את Fable 5 לראיין אתכם – 15 עד 30 שאלות ממוקדות – כדי לחלץ ידע סמוי מהראש שלכם. הרבה מהמידע הכי חשוב שלנו נמצא ב"ראש" אבל מעולם לא תועד. סשן כזה מייצר חומר גלם עשיר שנכנס ישירות ל-Sources ומשם מתומצת לדפי Wiki. זו פרקטיקה מספיק חשובה בשביל ״לארוז״ אותה לתוך Skill.

 

2. דרשו אימות עצמי (Self-Verification)
   • תמיד בקשו מהמודל לבדוק את העבודה שלו בסוף התהליך ולהראות את המקור המדויק עליו הוא מתבסס. Fable 5 מצטיין בביקורת עצמית – הוא יכול לזהות מקרים שבהם הוא "המציא" מידע או שלף אותו ממקור לא רלוונטי. תרגול עקבי של אימות עצמי מעלה את אמינות המערכת כולה.

 

3. נהלו תקציב אסימונים בחוכמה
   • Fable 5 יקר, וזה לא סתם. אל תבזבזו אותו על משימות כתיבה פשוטות או ניסוחים חוזרים. השתמשו בו לתכנון, אסטרטגיה וארגון ידע מורכב – ואת המשימות הפשוטות יותר (כתיבת טיוטות, סיכומים בסיסיים) העבירו למודלים זולים יותר כמו Sonnet, דרך מנגנון Sub-agents. ככה תשמרו על איכות גבוהה בלי לפוצץ את התקציב.

דוגמה מעשית: מבנה תיקיות מומלץ

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

my-second-brain/
├── CLAUDE.md                  # Schema - the router file
├── .claude/
│   └── skills/
│       ├── capture.md         # /capture skill instructions
│       ├── sync.md            # /sync skill instructions
│       └── lint.md            # /lint skill instructions
├── sources/
│   ├── transcripts/
│   ├── articles/
│   ├── meeting-notes/
│   └── raw-ideas/
└── wiki/
    ├── concepts/
    ├── people/
    ├── projects/
    └── decisions/

קובץ ה-CLAUDE.md בשורש הוא הלב של הכל. הוא צריך להכיל את הזהות שלכם (מה אתם עושים, מה חשוב לכם), את מפת התיקיות, ואת החוקים – למשל: "לעולם אל תערוך קבצים בתיקיית sources", "כל דף wiki חייב לכלול Frontmatter עם תאריך יצירה ותגיות", "בסוף כל עדכון, ספק רשימה של הקבצים שנערכו".

למה דווקא Fable 5 ולא מודל אחר?

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

כמה דברים שבלטו בבדיקות:

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

 

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

 

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

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

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

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

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

ההמלצה שלי: התחילו קטן. תיקיית Sources עם 10-20 מסמכים, תיקיית Wiki ריקה, וקובץ CLAUDE.md בסיסי. תנו ל-Fable 5 לעבוד – ותתפלאו כמה מהר המערכת מתחילה להפתיע אתכם.

בהצלחה!

הפוסט איך בניתי ״מוח שני״ עם Fable 5? ואיך גם אתם יכולים? הופיע לראשונה ב-Almaya.