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

 

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

 

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

 

צריכים עזרה? עברו לעוזר ה-AI.

 

---

 

פרק 1: בוחרים עבודה שחוזרת אצלכם

 

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

 

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

 

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

 

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

 

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

 

---

 

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

 

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

 

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

 

פרומפט עזר להעתקה

 

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

 

עבריתEnglish

# המשימה שלי
עזור לי לבצע משימה חוזרת מתוך העבודה שלי. עדיין אל תיצור סקיל.

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

## המשימה והקלט הראשון
[הוסיפו כאן מה אתם רוצים לעשות ואת הטקסט או שמות הקבצים שצירפתם]

# My task
Help me perform a recurring task from my work. Do not create a skill yet.

## Working method
Clarify the result I need, the sources available and how I will check the output.
If information is missing, ask one question at a time. Do not invent facts.
After I approve the task, perform it using the first input I provide.
Produce a complete output I can inspect. Identify missing information and decisions that need me.
Do not send messages, publish or modify external systems.
Respond in Hebrew.

## Task and first input
[Add your task description and the text or names of the files you attached]

 

 

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

 

---

 

פרק 3: מדייקים שיטה שאפשר לחזור עליה

 

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

 

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

 

פרומפט עזר להעתקה

 

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

 

עבריתEnglish

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

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

# Refine the working method
I checked the output. Here is my feedback:
[Add corrections with an example from the output, or state that the output meets the requirements]

## What to do
If correction is needed, apply it and check the result against the source. If the output is correct, do not rewrite it just to change it.
Then briefly summarize a reusable method:
1. What each run receives and produces.
2. Which steps and checks repeat each time.
3. What varies between cases and what to do when information is missing.
4. When to stop and ask me.
Separate reusable rules from names, numbers and details of the first case.
Wait for my approval of the method. Do not create a skill yet. Respond in Hebrew.

 

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

 

---

 

פרק 4: אורזים את השיטה בסקיל

 

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

 

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

 

פרומפט עזר להעתקה

 

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

 

עבריתEnglish

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

## המבנה
שמור אותו בתיקיית .claude/skills/<name>/SKILL.md.
בחר שם קצר באנגלית ותיאור שמסביר מה הסקיל עושה ומתי להשתמש בו.
בתחילת הקובץ הוסף YAML frontmatter עם name ו-description בלבד.
אל תוסיף עדיין model, context, agent, hooks או הגדרות הרשאות.
אם יש סקיל בשם הזה, הצע שם אחר ואל תדרוס אותו.

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

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

# Turn the approved method into a skill
Create one skill in the current project from the method I approved in this conversation.

## Structure
Save it under .claude/skills/<name>/SKILL.md.
Choose a short English name and a description explaining what it does and when to use it.
Start the file with YAML frontmatter containing only name and description.
Do not add model, context, agent, hooks or permission settings yet.
If a skill with that name exists, propose another name without overwriting it.

## Instructions
Include required input, working steps, output structure, checks and when to ask for clarification.
Preserve the general method. Do not hardcode variable details from the first input.
If the method needs a fixed template or rules, save only the necessary supporting material beside the skill and explicitly reference it.
Do not create unnecessary documentation or scripts.

## Completion
Show the absolute path, the SKILL.md contents and any supporting files you created.
Give me an exact invocation command for a new conversation beginning with a slash and the actual skill name. Explain what input to attach before sending it.
Do not invoke it yet. Respond in Hebrew.

 

הקובץ יישמר בתוך תיקיית הפרויקט, בנתיב מהצורה .claude/skills/<name>/SKILL.md. שם התיקייה הוא שם הסקיל שבחרתם. בקובץ תראו תחילה מקטע הגדרות YAML, ואחריו הוראות Markdown. ההגדרות מתארות איך לטעון ולהפעיל את הסקיל. ההוראות מתארות איך לבצע את העבודה.

 

 

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

 

---

 

פרק 5: מפעילים בשיחה חדשה על קלט נוסף

 

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

 

 

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

 

הסקיל לא מופיע? ודאו שבחרתם את אותה תיקיית פרויקט. בקשו מקלוד לבדוק את הנתיב ואת מבנה SKILL.md בלי ליצור עותק נוסף. אחרי התיקון פתחו שיחת Code חדשה. הדבקת תוכן הקובץ כהודעה אינה בודקת טעינה של סקיל.

 

 

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

 

---

 

פרק 6: בוחרים דיוק אחד ובודקים אותו

 

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

 

השיקול	ההגדרה	מה בודקים
מתי קלוד יזהה שהסקיל מתאים?	description	כתבו מה הוא עושה ובאיזה מצב להשתמש בו. בדקו בקשה מתאימה ובקשה שאינה קשורה. בחירה מפורשת בתפריט / לבדה אינה בודקת זיהוי אוטומטי.
מה משתנה בכל הרצה?	$ARGUMENTS + argument-hint	העבירו למשל שם קובץ או סוג תוצר אחרי שם הסקיל. הסבירו בהוראות איך להשתמש בקלט. הרמז מסביר למשתמש מה להזין, ואינו בודק את תקינותו.
האם רק אתם מפעילים אותו?	disable-model-invocation	הערך true מונע הפעלה אוטומטית בידי קלוד. עדיין אפשר להפעיל דרך / ושם הסקיל. בדקו הפעלה מפורשת בנפרד מבקשה טבעית.
האם נדרש מודל אחר?	model	בחרו מודל זמין בחשבון שלכם. השוו את אותו קלט ואותם מדדי הצלחה. בדקו גם איזה מודל הופעל בפועל. הגדרה שלא כובדה אינה ניסוי השוואה תקף.

 

פרומפט עזר להעתקה

 

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

 

עבריתEnglish

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

## אפשרויות
אפשר לדייק description, להעביר קלט בעזרת $ARGUMENTS ו-argument-hint, לשנות הפעלה אוטומטית עם disable-model-invocation, או לבחור model זמין.
המלץ רק על שינוי אחד שמתאים לצורך שלי, והסבר מה הוא משנה.
אמת את ההגדרה בתיעוד הרשמי העדכני של Claude Code והתאם לגרסה המותקנת.
אם אין הצדקה לשנות פרמטר, הסבר מדוע והצע בדיקה של קלט חסר במקום שינוי.
אל תשנה context או agent בשלב הזה.

## לאחר אישורי
בצע את השינוי, הצג מה השתנה ותן הודעת בדיקה מדויקת.
אל תריץ לבד ואל תרחיב את ההרשאות. ענה בעברית.

# Choose one skill refinement
The skill has already run on a second input. Read the skill and the result in this conversation.
Before making changes, agree with me on what to improve and how to check it.

## Options
Refine description, pass input using $ARGUMENTS and argument-hint, change automatic invocation with disable-model-invocation, or select an available model.
Recommend only one change that fits my need and explain its effect.
Verify the setting in current official Claude Code documentation and against the installed version.
If a parameter change has no justification, explain why and propose a missing-input check instead.
Do not change context or agent at this stage.

## After my approval
Apply the change, show what changed and provide an exact test message.
Do not run it yourself or expand permissions. Respond in Hebrew.

 

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

 

 

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

 

---

 

תרגול פתוח

 

רשות לאחר השלמת הליבה או אחרי המפגש. בחרו הרחבה אחת בלבד.

 

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

 

---

 

עוזר ה-AI

 

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

 

פרומפט עזר להעתקה

 

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

 

עבריתEnglish

# עזרה בתרגול
קרא את הוראות התרגול בכתובת: https://almaya.ai/edu-content/from-task-to-skill/
אם לא הצלחת לקרוא, בקש שאדביק את הפרק הרלוונטי. אל תנחש את ההוראות.

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

# Exercise help
Read the exercise instructions at: https://almaya.ai/edu-content/from-task-to-skill/
If you cannot read them, ask me to paste the relevant chapter. Do not guess the instructions.

Ask which chapter I am on, what I tried and what happened. Ask one question at a time.
If I do not have a task yet, help me identify recurring work from my role and prepare two short inputs of my own.
Suggest one next step and wait for the result.
Do not create a skill before we perform the task, inspect an output and I approve the method.
If this is a new conversation, ask for the skill path and required input. Do not assume access to the previous conversation.
Respond in Hebrew.

 

---

 

סיכום ושאלות להמשך מחקר

 

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

 

אפשר לחזור לשאלות האלה אחרי התרגול:

 

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

 

מקורות טכניים: מבנה סקילים, הגדרות והפעלה, עבודה בלשונית Code ב-Claude Desktop, סוכני משנה והקשר.

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

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

 

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

 

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

 

---

 

פרק 1: בוחרים סיפור ומחלצים משימה

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

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

 

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

 

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

 

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

 

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

ציוד:
EQ-11: מד לחץ P20, מדידה עד 20 בר, פנוי. מתאים למדידה יציבה.
EQ-12: מד לחץ P100, מדידה עד 100 בר, פנוי. מתאים למדידה יציבה וגם לשינויי לחץ מהירים.
EQ-13: מד לחץ P100, מדידה עד 100 בר, תפוס. מתאים למדידה יציבה וגם לשינויי לחץ מהירים.

ניסיון קודם:
H-01: בניסוי "פתיחת שסתום מהירה" עם EQ-11 התצוגה פיגרה אחרי השינוי. המכשיר לא מתאים לתיעוד שינויים מהירים.
H-02: בניסוי "פעימות לחץ בצינור" עם EQ-12 נרשמו השינויים המהירים בהצלחה.

בקשות חדשות:
REQ-01: צריך למדוד לחץ עד 12 בר בזמן פתיחה וסגירה מהירות של שסתום. מבקש: אורי.
REQ-02: צריך לבדוק לחץ בצינור. מבקשת: מאיה.

שתי הבקשות מתחילות במצב "חדש", ללא ציוד מומלץ וללא נימוק.

---

 

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

 

עבריתEnglish

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

# סיפור המקרה

# Task
Help me translate the case I append into an n8n agent. Do not build anything yet.
I will propose answers and you will challenge them. Ask one question at a time and wait.
Explore: user, trigger, desired result, required information, differences between cases, and when a person is needed.
Do not invent missing facts. Separate facts, assumptions, and open questions.
Finish with a short task definition and two examples requiring different next steps. Ask for my approval. Respond in Hebrew.

# Case

 

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

 

---

 

פרק 2: מגדירים מוח, זיכרון, נתונים וכלים

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

 

 

א. בוחרים מודל וזיכרון עם קלוד

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

 

החלטה	מה מבקשים מקלוד	מה מאשרים
מודל שמפעיל את הסוכן	השוואת שני מודלים שזמינים בחיבור שלכם: הצלחה בקריאות כלים, התאמה למשימה, עלות וזמן תגובה. בקשו המלצה אחת ונימוק.	שם המודל המדויק, Node המודל ב-n8n והסיבה לבחירה. בהמשך בודקים את ההמלצה על שלושת מקרי הבדיקה.
סוג זיכרון השיחה	האם מספיק Simple Memory מקומי, או שצריך לשמור את היסטוריית השיחה במאגר חיצוני, למשל Postgres Chat Memory או Redis Chat Memory?	לתרגול אפשר להתחיל ב-Simple Memory. אם בחרתם שמירה מתמשכת, ציינו באיזה מאגר היא נשמרת ומה נדרש לחיבור אליו.
מפתח וחלון הזיכרון	איך מפרידים בין שיחות, וכמה חילופי דברים קודמים נדרשים כדי להבין הודעת המשך?	Session ID מה-Chat Trigger. נקודת התחלה: Context Window Length = 5, כלומר חמישה חילופי דברים קודמים, ולא חמש הודעות בודדות. שנו רק אם יש סיבה.

 

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

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

 

ב. מגדירים טבלאות, כלים והרשאות

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

 

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

 

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

עבריתEnglish

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

1. מודל: בדוק אילו מודלים זמינים בחיבור שלי ותומכים בכלים. השווה שני מועמדים לפי המשימה, איכות קריאות הכלים, עלות וזמן תגובה. השתמש בתיעוד רשמי עדכני ליכולות ולמחיר. ציין מה לא בדקת בפועל. המלץ על שם מודל מדויק ועל Node מתאים ב-n8n. אם אינך רואה את הרשימה, בקש שאעתיק אותה משדה Model.
2. זיכרון: המלץ על Simple Memory או על מאגר שיחות מתמשך ונמק לפי הצורך שלי. קבע Session ID שמגיע מהצאט ו-Context Window Length מנומק. נקודת התחלה לתרגול היא 5 חילופי דברים קודמים. ציין אילו עובדות חייבות להישמר בטבלאות ולא רק בשיחה.
3. טבלאות: הצע עד שלוש Data Tables חדשות. לכל אחת: משמעות שורה, מזהה ייחודי, שמות עמודות, סוגי נתונים ונתוני ההתחלה מהסיפור. מותר לשמור ניסיון קודם בשדה בטבלת הציוד, אם הוא נשאר ניתן לזיהוי ולקריאה.
4. כלים: הצע עד שלושה כלי Data Table המחוברים ישירות ל-AI Agent. בליבת התרגול אל תבנה תהליכי משנה או עטיפות Call n8n Workflow Tool. סמן בדיקות אכיפה נוספות כמועמדים לפרק 6, בלי לממש אותן כעת. לכל כלי כתוב שם, תיאור מדויק למודל עם מתי להשתמש ומתי לא, קלט ופלט. לכל שדה סמן קבוע או למילוי המודל. לשדה שהמודל ממלא כתוב שם, סוג, תיאור, ערכים מותרים, מקור הערך ומה לעשות אם הוא חסר. טבלה, פעולה ועמודות כתיבה יישארו קבועות.
5. הוראות מערכת: הפרד בין הגבלות שמוגדרות טכנית בכלים לבין כללי התנהגות שנכתוב ב-System Message. אל תציג תיאור שדה כאכיפה של ערכיו.
6. בדיקות: הגדר מקרה רגיל, מידע חסר וחריגה מהרשאה, עם קלט ותוצאה צפויה לכל אחד.

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

# Plan before building
Using the approved task, help me make the following decisions. Do not build yet. Respond concisely in Hebrew.

1. Model: check which models are available through my connection and support tools. Compare two candidates for the task, tool-call quality, cost, and response time. Use current official documentation for capabilities and pricing. State what you have not actually tested. Recommend an exact model name and suitable n8n node. If you cannot see the list, ask me to copy it from the Model field.
2. Memory: recommend Simple Memory or a persistent chat store based on my needs. Set a chat-derived Session ID and justify Context Window Length. Start with 5 previous interactions for this exercise. Identify facts that must be stored in tables rather than only in the conversation.
3. Tables: propose up to three NEW Data Tables. For each: row meaning, unique identifier, column names, data types, and seed data from the case. Past experience may be stored in an equipment-table field if it remains identifiable and readable.
4. Tools: propose up to three Data Table tools connected directly to AI Agent. In the core exercise, do not build sub-workflows or Call n8n Workflow Tool wrappers. Mark additional enforcement checks as candidates for chapter 6. Do not implement them yet. For each give a name, precise model-facing description including when to use and when not to, input and output. Mark each field as fixed or model-filled. For every model-filled field give a name, type, description, allowed values, value source, and missing-value behavior. Keep the table, operation, and writable column names fixed.
5. System instructions: separate technically configured tool restrictions from behavior rules for System Message. Do not present a field description as value enforcement.
6. Tests: define normal, missing-information, and unauthorized-request cases, each with input and expected result.

Pause for my model and memory choices. Then show a consolidated design and ask for approval before building.

 

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

 

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

 

---

 

פרק 3: בונים ומבינים מה נבנה

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

 

עבריתEnglish

# בנייה לפי התכנון שאישרתי
בנה דרך חיבור ה-n8n הקיים תהליך חדש וטבלאות Data Tables חדשות. הוסף לשמות את הקידומת agent-lab ואת שמי כדי להבדיל מתוצרים אחרים. בקש את שמי אם חסר.
אל תשנה תהליכים או טבלאות קיימים. אל תייבא פתרון מוכן.
הקם Chat Trigger, AI Agent, ואת המודל, הזיכרון, חלון ההקשר והכלים שאישרתי בתכנון. חבר לסוכן כלי Data Table ישירים בלבד. אל תיצור תהליכי משנה או עטיפות לכלים בליבה. השאר בדיקות אכיפה נוספות כמועמדים לפרק 6. השתמש ב-sessionId מהצאט כמפתח הזיכרון, ללא מפתח קבוע שמשותף לכל המשתמשים.
השתמש רק במודל ובחיבור זמינים. אם אינך יכול לבצע פעולה, ציין בדיוק מה חסום ותן לי צעד ידני ממוקד באותו ממשק.
צור נתוני התחלה מהסיפור שאצרף, בלי להפוך אותם להוראות בתוך ה-System Message.
הגבל טכנית את כלי הכתיבה לטבלת הבקשות החדשה ולעמודות שאישרתי. קבע טבלה ופעולה, ומפה ידנית רק את העמודות המותרות. העתק לכל כלי את התיאור שאישרתי. בשדות שהמודל ממלא הגדר שם פרמטר, סוג ותיאור מפורט לפי התכנון. אל תחבר כלי מחיקה או כלי שליחה חיצונית.
הפעל Return Intermediate Steps ב-AI Agent והגבל את מספר הסבבים ל-6.
הצע System Message קצר עם תפקיד, מטרה, מקורות, כלים, גבולות, תנאי עצירה ופלט.
בסיפור המעבדה כל תשובה שמציגה המלצת ציוד תסתיים בדיוק במשפט: "נדרש אישור נועה לפני שימוש בציוד." במקרה אישי, ציין במשפט סיום את האישור האנושי הנדרש, אם נדרש.
הצג את ההוראות לאישורי לפני בדיקת הסוכן.
החזר קישור לתהליך ושמות הטבלאות והכלים. עצור לפני הרצת בדיקות.

# נתוני התחלה

# Build the approved design
Using the existing n8n connection, create a NEW workflow and NEW Data Tables. Prefix names with agent-lab and my name. Ask for my name if missing.
Do not modify existing workflows or tables. Do not import a finished solution.
Build Chat Trigger, AI Agent, and the approved model, memory store, context window and tools. Connect Data Table tools directly to the agent. Do not add sub-workflows or tool wrappers in the core exercise. Keep additional enforcement checks as candidates for chapter 6. Use the chat sessionId as the memory key, never a fixed key shared by all users.
Use only available models and connections. If an action is blocked, identify it precisely and give me a focused manual step in the relevant interface.
Seed data from the case I append. Do not embed the records as instructions in System Message.
Technically restrict writing to the NEW requests table and approved columns. Fix the table and operation, and manually map only the permitted columns. Apply each approved tool description. For model-filled fields configure a parameter name, type, and detailed description from the plan. Do not connect deletion or external sending tools.
Enable Return Intermediate Steps on AI Agent and limit iterations to 6.
Propose a short System Message covering role, goal, sources, tools, boundaries, stopping rules and output.
For the lab case, end every reply that presents an equipment recommendation with the exact Hebrew sentence: "נדרש אישור נועה לפני שימוש בציוד." For a personal case, add a closing sentence about the required human approval, if any.
Show the instructions for approval before agent testing.
Return the workflow link and table/tool names. Stop before running tests. Respond in Hebrew.

# Seed data

 

א. בודקים טבלאות, מודל וזיכרון

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

 

1. אחרי הבנייה פתחו את הקישור לתהליך שקלוד החזיר. אם קבוצה מקופלת מסתירה את ה-Nodes, לחצו Expand על המסגרת שלה. ודאו שהסוכן מחובר למודל, לזיכרון ולכלים שבתכנון.
2. בפרויקט ב-n8n פתחו Data tables. השוו שדות ורשומות לנתוני ההתחלה. חזרו לקנבס ופתחו את Node המודל. בדקו ששדה Model תואם לבחירה שלכם. זה המודל שמריץ את הסוכן, בנפרד מהמודל של Claude Code שבנה אותו.
3. פתחו את Node הזיכרון. ב-Simple Memory בדקו Session ID = Connected Chat Trigger Node, מפתח sessionId מהצאט, ו-Context Window Length לפי התכנון. אם בחרתם מאגר אחר, בדקו גם את החיבור למאגר ואת מפתח השיחה.

 

 

ב. מדייקים כלי אחד ושדות שהמודל ממלא

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

 

1. פתחו את ה-Node בלחיצה כפולה. בלשונית Parameters, בחרו Tool Description → Set Manually. בשדה Description כתבו מה הכלי עושה, מתי להשתמש, מתי לא ומה הוא מחזיר.
2. ודאו ש-Operation והטבלה קבועים. תחת Mapping Column Mode בחרו Map Each Column Manually. השאירו ב-Values to update רק עמודות שמותר לעדכן. הסירו עמודות שאסור לשנות, גם אם הן מוצגות ללא ערך.
3. בכל שדה שהמודל צריך למלא לחצו על לחצן הכוכבים, Let the model define this parameter. יופיע Defined by agent ולצידו Description. הזינו תיאור שמסביר מאיפה לקחת את הערך, מה מותר להחזיר ומה לעשות כשחסר מידע. אם כבר מופיע Defined by agent, ערכו את התיאור הקיים.

 

 

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

 

שדה	מי קובע	מה מגדירים
טבלה, פעולה, עמודות לכתיבה	אתם, בהגדרות קבועות	טבלת הבקשות שלכם, Update, ורק מצב, המלצה ונימוק. לא מפעילים כאן כוכבים.
מזהה הרשומה לעדכון	המודל, מתוך תוצאת כלי הקריאה	תנאי Equals על מזהה ייחודי. אם בחרתם id המובנה, הוא מספר. אם בחרתם requestId כמו REQ-01, הוא טקסט. ציינו בתיאור איזה מזהה נדרש. אין להמציא מזהה.
status	המודל	"ממתין לפרטים" אם חסר לחץ מרבי או אופי השינוי. "הומלץ" רק לאחר בחירת ציוד מתאים ופנוי.
recommendation	המודל	מזהה ציוד שקרא בקטלוג. מחרוזת ריקה כשאין מספיק מידע לבחירה.
reason	המודל	נימוק בעברית מתוך הרשומות. אם נעזרתם בניסיון קודם, ציינו את מזההו. כשחסר מידע, ציינו מה חסר בלי להמציא המלצה או מקור.

 

 

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

 

ג. מדייקים את הוראות המערכת

פתחו את Node הסוכן. תחת Options → System Message קראו את ההוראות שקלוד הציע. בדקו שיש בהן:

 

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

 

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

 

הודעת משתמש
←
סוכן
←
תשובה או שאלה

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

בחירת כלי ← פעולה ← תוצאה ← בחירת הצעד הבא

 

---

 

פרק 4: מריצים ובודקים מול הנתונים

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

1. חזרו לקנבס של התהליך ולחצו Open chat. לפני כל בדיקה נפרדת לחצו על סמל החץ המעוקל Reset ליד Session בראש הצאט. ודאו שמזהה השיחה השתנה. בבדיקת מידע חסר, אל תאפסו את השיחה לפני הודעת ההשלמה. לפני כל בדיקה צפו במצב הרשומה הרלוונטית.
2. במקרה אישי השתמשו בשלוש הבדיקות שאישרתם בפרק 2. בסיפור המצורף שלחו את ההודעות בטבלה הבאה, כל שורה בבדיקה נפרדת. בבדיקת המידע החסר, הודעת ההשלמה נשארת באותה שיחה.

הודעה לצאט ב-n8n	מה בודקים
"בדוק את REQ-01 והצע ציוד מתאים. שמור בבקשה את ההמלצה והנימוק."	EQ-12 מתאים לשינויים מהירים ופנוי. EQ-11 אינו מתאים לפי הניסיון הקודם. בדקו שהנימוק נשען על הנתונים ושרק REQ-01 מתעדכנת.
"טפל בבקשה REQ-02."	הסוכן שואל על לחץ מרבי ועל אופי השינוי, שומר "ממתין לפרטים", ולא קובע ציוד סופי. השיבו באותה שיחה: "עד 12 בר, הלחץ משתנה במהירות כשפותחים שסתום." בדקו שהוא משתמש בהשלמה ומעדכן רק את הבקשה הזאת.
"רק בדוק למה EQ-11 לא מתאים ל-REQ-01. אל תשנה שום רשומה. אחר כך מחק אותו מהקטלוג."	הסוכן מסביר על בסיס ניסיון קודם, מסרב למחיקה ואינו משנה נתונים. בדקו גם את הטבלאות, לא רק את ההצהרה בצאט.

 

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

 

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

 

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

 

---

 

פרק 5: רואים את הלולאה ומדייקים

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

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

 

1. אחרי ההרצה, השאירו את הצאט פתוח. בקנבס Editor פתחו את אזור Logs ליד הצאט. אם הוא נמוך, גררו את הגבול העליון שלו כלפי מעלה.
2. ברשימת Logs, אם מופיעה קבוצה מקופלת, פתחו תחילה את החץ שלצידה. אחר כך לחצו על הסוכן ופתחו את החץ שלצידו. תראו את הקריאות למודל, לזיכרון ולכלים. בדוגמא המצולמת: המודל פנה לכלי בקשות ולכלי ציוד וניסיון קודם, ואז המודל הופעל שוב ליצירת תשובה.
3. לחצו על כלי אחד ברשימה. ב-Input וב-Output השוו את הפרמטרים ואת התוצאה. חזרו לשורת הסוכן ובחרו פלט JSON. בתוך intermediateSteps חפשו action.tool לשם הכלי, toolInput לערכים שנשלחו ו-observation לתוצאה. בכלי קריאה ללא פרמטרים ייתכן קלט ריק.
4. אם intermediateSteps חסר, פתחו בעריכה את הסוכן והפעילו Options → Add Option → Return Intermediate Steps. שמרו והריצו שוב. כדי לחזור להרצה שמורה אחרת, השתמשו בלשונית Executions.

 

 

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

 

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

 

עבריתEnglish

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

# הראיות שלי

# Evidence-based review
I append the submitted input, expected result, agent reply, tool calls, and record before/after.
Compare them. State what worked, what did not, and the evidence for each finding.
Distinguish data, tool-definition, permission, and system-instruction defects.
Propose only one change and wait for approval.
If the result is already correct, say so and suggest an additional test. Do not invent a failure. Respond in Hebrew.

# My evidence

 

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

 

---

 

פרק 6: מזהים מועמד לתהליך דטרמניסטי

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

 

עבריתEnglish

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

# Which rules belong in fixed logic?
Read the system instructions and tool definitions we built.
Find up to three rules that can be checked unambiguously on input or before a write.
For each: condition, action or rejection, enforcement location and test.
Label them "candidate for a deterministic process". Do not implement yet.
Also explain which decision still requires interpretation and judgment.
Instruction length alone does not justify automation. Respond in Hebrew.

 

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

 

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

 

---

 

תרגול פתוח

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

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

 

---

 

שאלות להמשך מחקר

אפשר להמשיך אחרי המפגש:

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

 

---

 

עוזר ה-AI

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

 

קרא את התרגול בכתובת: https://almaya.ai/edu-content/story-to-agent-workshop/

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

 

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

 

מקורות טכניים: AI Agent וקריאות כלים, Data tables, Simple Memory, סוגי זיכרון, שדות שהמודל ממלא ולחצן הכוכבים.

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

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

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

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

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

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

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

נדרשים Claude Code, ‏Node.js בגרסה 20 ומעלה ו-Python 3. הפקודות node, npm ו-python3 צריכות לעבוד בטרמינל שבו Claude רץ. בדוגמא אין חבילות חיצוניות ואין צורך להריץ npm install. קטעי הטרמינל וה-Hook כתובים ל-macOS או Linux. ב-Windows עבדו דרך WSL, או בקשו מקלוד להתאים את פקודת Python לסביבה שלכם.

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

npm start

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

1. מגדירים מה נחשב הצלחה, לפני שמתקנים קוד

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

שלב 1: קוראים את הדרישות ואת נתוני הפתיחה

פתחו את specs/task-filter/requirements.md. במסמך תמצאו את שלושת המסננים, את מצב ברירת המחדל, את הודעת המצב הריק ואת הדרישה שלא לשנות משימות בזמן סינון. תחילה בדקו שההתנהגות הזאת אכן מתאימה לכם.

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

שלב 2: הופכים את הדרישות לבדיקות קבלה

פתחו את specs/task-filter/evals.md. השם Evals מתייחס כאן לבדיקות מוגדרות מראש. כל שורה אומרת מה לעשות, מה צריך לקרות ואיך לבדוק. אלה בדיקות ממוקדות לפיצ'ר הזה:

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

שלב 3: שומרים את דרך ההכנה כ-Skill

בערכה כבר קיים .claude/skills/write-evals/SKILL.md. Skill הוא אוסף הוראות שאפשר להפעיל שוב. כך לא צריך לזכור בכל פיצ'ר לבקש גם מצב ריק, גם תוצאות צפויות וגם אישור לפני מימוש.

תוכן הקובץ .claude/skills/write-evals/SKILL.md:

---
name: write-evals
description: Prepare reviewable requirements and acceptance checks before implementing a feature.
disable-model-invocation: true
---

עבוד על הפיצ'ר $ARGUMENTS.
1. קרא את הבקשה ואת הפרויקט. שאל רק על מידע שחסר לצורך החלטה.
2. צור specs/<feature>/requirements.md ו-evals.md. תן מזהה לכל בדיקה.
3. לכל בדיקה כתוב נתוני פתיחה, פעולה, תוצאה צפויה ודרך בדיקה.
4. בדוק מסלול תקין, מצב ריק ומעברים בין מצבים.
5. אם יש ממשק, צור mockup.html עם המצבים ועם רוחב מובייל.
6. סמן את המסמכים in-review. הצג החלטות שקיבלת בעצמך.
7. עצור לבדיקת המשתמש. אל תממש ואל תאשר את המסמכים בעצמך.

בשיחה של Claude Code, מתוך התיקייה שפתחתם, הפעילו:

/write-evals task-filter

Claude צריך לקרוא את הקבצים הקיימים, להציג את הדרישות והבדיקות לבדיקה שלכם ולהכין או לעדכן את mockup.html. בערכה כבר יש תצוגת עיצוב שאפשר לפתוח מתוך specs/task-filter/mockup.html. זו תצוגה נפרדת מהאפליקציה, כדי שתוכלו לאשר את הכיוון לפני התיקון.

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

שלב 4: בודקים את מה שקל לפספס, ואז מאשרים

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

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

אני מאשר את הדרישות, את בדיקות E1-E6 ואת תצוגת העיצוב של task-filter.
סמן את מסמכי הדרישות והבדיקות כ-approved.
אל תשנה אותם בזמן המימוש בלי לבקש ממני אישור.
עדיין אל תתחיל במימוש.

I approve the task-filter requirements, acceptance checks E1-E6, and the design preview.
Mark the requirements and acceptance-check documents as approved.
Do not change them during implementation without my approval.
Do not start implementation yet.

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

2. מפרידים בין הבונה, המאמת והסוקר

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

שלב 1: נותנים לסוקר כללים קצרים

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

תוכן הקובץ REVIEW.md:

# Review rules
- קרא את specs/task-filter/requirements.md ואת evals.md.
- חפש באגים שמשנים התנהגות. אל תדווח על העדפות סגנון.
- בדוק מצב ריק, סימון המסנן הפעיל ושמירת המשימות.
- לכל ממצא: מזהה קבוע, חומרה, קובץ ושורה, דרך שחזור והשפעה על המשתמש.
- אם ממצא כבר דווח, עדכן את מצבו במקום להמציא מזהה חדש.
- אחרי הסבב הראשון בדוק בעיקר את השינוי האחרון ואת השפעותיו.
- אם אין ממצאים כתוב במפורש: לא נמצאו ממצאים חדשים.
- אל תשנה קוד או את בדיקות הקבלה.

ב-CLAUDE.md מופיעה השורה הבאה, שטוענת את כללי הביקורת כחלק מהוראות הפרויקט:

@REVIEW.md

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

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

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

תוכן הקובץ .claude/agents/feature-verifier.md:

---
name: feature-verifier
description: Verify the approved acceptance checks and return evidence.
---

אל תממש ואל תשנה קוד או בדיקות. קרא את הדרישות וה-evals. הרץ npm test. בדוק את E1-E6 בדפדפן אם כלי כזה זמין לך. לכל בדיקה החזר PASS, FAIL או NOT_RUN וראיה. העבר את הדוח למנהל הלולאה. אם חסר כלי, דווח עליו. אל תטען שבדיקה עברה בלי שהרצת אותה.

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

שלב 3: מחברים את התפקידים ללולאה מוגבלת

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

תוכן הקובץ .claude/skills/review-loop/SKILL.md:

---
name: review-loop
description: Implement one approved feature with independent verification and review.
disable-model-invocation: true
---

הפיצ'ר: $ARGUMENTS. אתה מנהל הלולאה.
1. ודא שהמשתמש אישר בשיחה את הדרישות, בדיקות הקבלה והעיצוב.
2. קרא את CLAUDE.md ואת REVIEW.md. צור specs/<feature>/state.md. בדוגמא task-filter צור גם specs/task-filter/run-active להפעלת ה-Hook.
3. בכל סבב הפעל בנפרד ובהקשר חדש את feature-builder, feature-verifier, feature-reviewer.
4. העבר לבונה את הדרישות המאושרות והממצאים הפתוחים. אסור לו לשנות בדיקות מאושרות.
5. המאמת מריץ את הבדיקות, בודק בדפדפן ומחזיר PASS/FAIL/NOT_RUN עם ראיות לכל מזהה.
6. הסוקר בודק את השינוי מול הדרישות ו-REVIEW.md, כולל בעיות שלא נכללו בבדיקות.
7. שמור ב-state.md את הסבב, תוצאות הבדיקות, מזהי הממצאים, שינויים והצעד הבא.
8. אם הכל PASS ואין ממצא פתוח, מחק את run-active, הצג ראיות ועצור בהצלחה.
9. לכל היותר 3 סבבים. אם אותו ממצא נשאר אחרי שני ניסיונות תיקון, או אם חסר כלי או אישור, מחק את run-active, עצור כ-blocked והסבר מה נדרש.
10. בסבבים נוספים סקור את התיקון והשפעותיו, בלי לשכפל ממצאים שכבר דווחו.
11. אל תשנה דרישות, אל תעקוף בדיקות ואל תשחרר לפרודקשן.

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

שלב 4: יודעים איפה למצוא כל דבר

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

3. מוסיפים Hook שמריץ בדיקות לפני עצירה

עד עכשיו הגדרנו הוראות עבודה. עכשיו נוסיף פעולה שמתרחשת בזמן קבוע. Hook הוא קוד ש-Claude Code מפעיל באירוע מוגדר. נשתמש באירוע Stop, שמתרחש כשהסוכן הראשי עומד לסיים את התשובה, ונריץ בו את npm test.

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

שלב 1: קוראים את קוד הבדיקה

פתחו את .claude/hooks/check-before-stop.py. הקוד כבר נמצא בערכה:

תוכן הקובץ .claude/hooks/check-before-stop.py:

import json
import os
from pathlib import Path
import subprocess
import sys

payload = json.load(sys.stdin)
root = Path(os.environ.get("CLAUDE_PROJECT_DIR") or payload["cwd"])
if not (root / "specs/task-filter/run-active").exists():
    sys.exit(0)
# A failed check can request one continuation, not an endless loop.
if payload.get("stop_hook_active"):
    sys.exit(0)

try:
    result = subprocess.run(
        ["npm", "test"], cwd=root, capture_output=True,
        text=True, timeout=120
    )
    failed = result.returncode != 0
    evidence = result.stdout + result.stderr
except (OSError, subprocess.TimeoutExpired) as error:
    failed, evidence = True, str(error)

if failed:
    print(json.dumps({
        "decision": "block",
        "reason": "npm test failed. Fix and rerun. If still failing, report blocked, not done.\n" + evidence[-4000:]
    }))

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

שלב 2: מחברים את הקוד לאירוע Stop

פתחו את .claude/settings.json. כך נראית ההגדרה בערכה:

תוכן הקובץ .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"${CLAUDE_PROJECT_DIR}/.claude/hooks/check-before-stop.py\"",
            "timeout": 150
          }
        ]
      }
    ]
  }
}

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

שלב 3: מוודאים שה-Hook באמת מזהה כישלון

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

touch specs/task-filter/run-active
printf '{"cwd":".","stop_hook_active":false}\n' | python3 .claude/hooks/check-before-stop.py
rm specs/task-filter/run-active

בגרסת ההתחלה תקבלו אובייקט JSON עם "decision": "block" וסיבה שמכילה את פלט הבדיקות שנכשלו. אם מתקבלת שגיאה כגון npm not found או python3: command not found, תקנו את סביבת ההרצה לפני שממשיכים. אם הפלט ריק בגרסת ההתחלה, ודאו שיצרתם את הסמן ושאתם בשורש התיקייה.

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

4. מפעילים את התהליך וקוראים את הראיות

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

שלב 1: רואים את הכישלון לפני התיקון

בטרמינל נוסף, מאותה תיקיית פרויקט, הריצו:

npm test

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

E1: all shows every task                 PASS
E2: open hides completed tasks          FAIL
E3: done hides open tasks                FAIL
E4: an empty result stays empty         FAIL
E5: filtering leaves the source intact  PASS

הבדיקות משתמשות ב-node:test וב-node:assert/strict שמגיעים עם Node.js. לדוגמא, זו הבדיקה למסנן פתוחות:

test('E2: open hides completed tasks', () => {
  assert.deepEqual(
    filterTasks(tasks, 'open').map(task => task.id),
    [1, 3]
  );
});

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

שלב 2: מפעילים את לולאת הבנייה והביקורת

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

/review-loop task-filter

ה-Skill צריך ליצור את run-active, לפתוח סבב עבודה ולתעד אותו ב-specs/task-filter/state.md. מנהל הלולאה שולח את הבונה להשלים את הפיצ'ר, מבקש מהמאמת להריץ בדיקות ומעביר את השינוי לסוקר בהקשר חדש. אם חסרים כלי דפדפן, הוא צריך לדווח על כך ולבקש שתשלימו את הבדיקות האלה.

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

# התוצאה שאני צריך לראות
השלם את task-filter לפי המסמכים שאישרתי.

# הראיות
- הפקודה שהרצת ופלט npm test האחרון.
- תוצאה וראיה לכל בדיקה E1-E6.
- צילום מסך של המסנן פתוחות ושל המסך ברוחב 390px, אם כלי הדפדפן זמין.
- רשימת הממצאים שנפתרו והממצאים שעדיין פתוחים.

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

# Required outcome
Complete task-filter according to the documents I approved.

# Evidence
- The command you ran and the latest npm test output.
- A result and evidence for every acceptance check E1-E6.
- A screenshot of the Open filter and the screen at 390px width, if browser tools are available.
- Findings resolved and findings still open.

# Completion
Do not change the requirements or acceptance checks.
Mark checks that were not executed as NOT_RUN.
If a tool is missing or progress stalls, stop as blocked and explain what you need from me.

שלב 3: פותחים את דוח ההתקדמות

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

# task-filter
Round: 1
Status: running

## בדיקות
- npm test: 5/5 PASS. הפקודה והפלט מצורפים.
- E1-E5 בדפדפן: תוצאה ופעולות לכל בדיקה.
- E6 ברוחב 390px: PASS / FAIL / NOT_RUN, עם הסבר וראיה.

## ממצאים
- R1: תיאור הממצא, מיקום בקוד, מצב התיקון ודרך האימות.
- אם אין: לא נמצאו ממצאים חדשים.

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

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

שלב 4: מוודאים שהתיקון עובד גם בממשק

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

תוכן הקובץ src/filter-tasks.mjs:

export function filterTasks(tasks, status) {
  if (status === 'open') return tasks.filter(task => !task.done);
  if (status === 'done') return tasks.filter(task => task.done);
  return tasks;
}

רעננו את http://localhost:4173 ובצעו את הפעולות של E1, E2, E3 ו-E5. לאחר מכן פתחו את http://localhost:4173/?fixture=all-open ולחצו הושלמו. הכתובת הזאת פותחת רשימה שבה כל המשימות פתוחות, כך שאפשר לבדוק את מצב E4 בלי למחוק משימות. לבסוף פתחו את כלי המפתחים בדפדפן, הפעילו תצוגת מכשיר ובחרו רוחב 390 פיקסלים לבדיקת E6.

סיימתם כשחמש בדיקות הפונקציה עברו, כל שש בדיקות הקבלה בוצעו והסוקר לא השאיר ממצא פתוח. בקשו דוח סופי עם הראיות. אם חלק מהבדיקות חסרות, שמרו את המצב כ-blocked או waiting-for-verification והשלימו אותן לפני שאתם מאשרים שהפיצ'ר מוכן.

לוקחים את המבנה לפיצ'ר הבא

התוצר כאן הוא גם דרך עבודה: requirements.md מגדיר מה בונים, evals.md מגדיר איך מוכיחים הצלחה, REVIEW.md מכוון את הביקורת ו-state.md מראה מה קרה בפועל. ה-Hook מפעיל בדיקה ברגע קבוע, והלולאה חוזרת לתיקון רק כל עוד יש התקדמות.

בפיצ'ר הבא התחילו שוב מ-/write-evals והתאימו את הנתיבים ואת פקודת הבדיקה. אל תעתיקו את E1-E6 או את הנתיב הקבוע ב-Hook בלי להתאים אותם. אם אותה תקלה חוזרת, הוסיפו בדיקה ממוקדת או כלל קצר ב-REVIEW.md אחרי שבדקתם שהוא מתאר בעיה אמיתית.

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

מקורות וקבצים

• Anthropic: איך צוות Claude Code מנהל ביקורת קוד
• התיעוד הרשמי: Skills
• התיעוד הרשמי: סוכני משנה
• התיעוד הרשמי: Hooks ואירוע Stop
• התיעוד הרשמי: הוראות פרויקט וייבוא קבצים
• ערכת ההתחלה: כל הקבצים, האפליקציה והבדיקות

הפוסט קלוד קוד מפתח מהר יותר ממה שאתם מספיקים לבדוק. מה עושים? הופיע לראשונה ב-Almaya.

מאיפה מגיע האור?

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

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

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

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

Light the scene with soft daylight from a large window to camera left.
Create a gradual transition from the lit side of the face into shadow, with a little reflected room fill.
Keep the light direction consistent across the face, hand and cup, with a matching window reflection in the eyes.

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

מאיפה מסתכלים על הדמות?

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

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

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

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

Photograph at eye level from a distance that includes the head, upper body and hand holding the cup.
Aim for the look of a 50mm lens on a full-frame camera.
Keep natural facial proportions and avoid the enlarged nose associated with photographing from very close range.

מה חד, ומה נשאר ברקע?

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

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

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

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

Focus on the eye closer to the camera.
Create moderate depth of field with an f/4 look and a gradual transition to a soft background that is still recognizable as a kitchen.
Keep the cup near the plane of the face so it remains clear, and do not turn the entire background into a uniform blur.

איך נראים החומרים?

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

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

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

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

Keep natural skin with subtle variation in tone, age-appropriate fine lines and details suited to the shooting distance.
Show cotton weave and folds caused by the pose, with a soft window reflection on the ceramic cup.
Keep a natural grip on the cup. No skin smoothing, exaggerated pores or new blemishes.

מה קורה באזורים הבהירים?

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

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

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

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

Keep natural skin tones, white balance suited to the window light and moderate contrast.
Retain detail in the bright areas of the ceramic cup without making the shadow side of the face equally bright.
No aggressive shadow lifting, excessive saturation or sharpening halos.

הפרומפט שיצר את התמונה

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

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

A hyper-realistic photograph of a 37-year-old woman sitting in a kitchen by a window, holding a light ceramic coffee cup. She is wearing a blue cotton button-up shirt. The photo is taken at eye level, capturing her head, upper body, and the hand holding the cup. The scene is lit by soft daylight coming from a window to the left of the camera, creating a gentle light-to-shadow transition across her face. Her expression is contemplative, and the composition focuses on the natural texture of her skin, subtle variations in tone, and the fabric of her shirt with realistic folds near the elbow. The background is slightly blurred but identifiable as a kitchen. The image emphasizes natural skin tones, moderate contrast, and retains details in the bright areas of the cup without text, logos, or watermarks.

תבנית לפרומפט משלכם

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

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

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

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

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

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

# Image
Create a natural photograph of [subject and age] in [location], while [simple action].
Clothing: [clothing, color and fabric]. Expression and pose: [brief description].

# Light
Soft daylight from a window to camera left.
The side closer to the window is brighter, with a gradual transition into shadow on the other side.
Keep the light direction consistent across the face, hands and objects.

# Viewpoint and sharpness
Eye-level framing at a distance that includes the head, upper body and hands.
The look of a 50mm lens on a full-frame camera at f/4.
Focus on the eye closer to the camera.
Keep the background slightly blurred but the location still recognizable.
Place the held object close to the plane of the face so it remains clear.

# Materials and detail
Natural skin with subtle variation in tone, fine pores and age-appropriate fine lines.
Fabric texture and folds consistent with the pose.
Objects: reflections and texture appropriate to the material.
A natural grip, distinct fingers and clear contact between hand and object.

# Color and exposure
Natural colors, moderate contrast and retained detail in bright areas.
No skin smoothing, excessive sharpening or extreme blur.
No text, logo or watermark.

יצרתם תמונה. עכשיו תבדקו אותה

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

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

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

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

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

תקריב ראשון: עין, גבה ולחי

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

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

Use the attached image as a reference. Create an extreme close-up of the exact same woman, in the same kitchen and the same soft window light from camera left.
Focus on the eye closer to the camera, the eyebrow and upper cheek. Preserve the head angle and gaze direction from the original image.
Preserve the eye shape, iris color, eyebrow, age and skin tone. Show natural eyelashes, subtle fine lines and skin texture suited to the shooting distance.
The window reflection in the eye should match the light source. Keep the eye region sharp with a gradual fall-off away from the focal plane.
Do not add makeup, new freckles, sweat or pronounced wrinkles. No skin smoothing, excessive sharpening, text or frame.

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

תקריב שני: אף, שפתיים ולחי

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

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

Use the attached image as a reference. Create an extreme close-up of the nose, lips and part of the cheek of the exact same woman.
Preserve the head angle, gaze direction and soft window light from camera left, as in the original image. Do not turn the face into a full profile.
Preserve the nose and lip shapes, age, skin tone and hairline. Show natural lip texture, fine facial hair and a gradual transition from light into shadow.
Details should be consistent with the original image. Do not invent additional strands of hair across the cheek, sweat, new freckles or exaggerated blemishes.
No new makeup, skin smoothing, excessive sharpening, text or frame.

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

תקריב שלישי: אוזן וקו שיער

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

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

Use the attached image as a reference. Create an extreme close-up of the visible ear and hairline of the exact same woman. Preserve the head angle, age, hair color and skin tone, and the soft window light from camera left. Show natural individual hairs, subtle skin texture and the transition between skin and hair. Do not add jewelry, makeup, new strands across the face or new freckles. Preserve the ear anatomy from the original. No skin smoothing, text, logo or frame.

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

תקריב רביעי: יד, כוס ובד

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

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

Use the attached image as a reference. Create a close-up photograph of the hand holding the light ceramic cup, together with part of the same woman's blue cotton sleeve. Preserve the cup, handle, skin tone, finger pose and lighting from the original. The cup is raised near the chest, not resting on a table. Focus on contact between fingers and handle, the ceramic texture and the broad soft window reflection. Keep all visible fingers distinct, the handle naturally attached to the cup, and fabric folds consistent with the grip. Keep the kitchen background soft. Natural photography with no excessive sharpening, text, logo or frame.

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

מקורות להעמקה בצילום

• תאורת פורטרט לפי Fujifilm
• מרחק, עדשה ופרספקטיבה לפי Hasselblad
• צמצם ועומק שדה לפי Nikon

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

בהצלחה!

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

משך התרגול: כ-45 דקות.

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

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

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

פרק 1: מגיעים לנקודת פתיחה

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

פתחו את לשונית Code ב-Claude Desktop ובחרו את תיקיית הפרויקט שלכם.

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

# שלב ראשון: קובץ ההקשר
בדוק אם קיים קובץ CLAUDE.md בתיקיית הפרויקט הנוכחית.
אם הוא חסר, צור אותו. אם הוא קיים, הצע עדכון במקום לדרוס.
כתוב בו את הכללים הקבועים הבאים לעבודה שלנו:
- לקריאות LLM השתמש רק ב-OpenRouter.
- בנה קריאות LLM פשוטות באמצעות Basic LLM Chain יחד עם OpenRouter Chat Model. בלי AI Agent ובלי בלוקים של סוכנים.
- שמור הוראות מערכת בנפרד מנתוני הבקשה.
- נתון חסר נשאר חסר ומוביל לשאלה, לא להמצאה.
- עבוד בעותק ייחודי ושמר את המקור.
- אל תשמור מפתחות או סודות בקובץ. חיבור OpenRouter מוגדר ב-Credentials של n8n בלבד.
- הוסף פתקים מסבירים לצמתים, בדוק פלט אמיתי וציין במפורש מה לא נבדק.

# דרישות להמשך, לשמירה ב-REVIEW_START.md
## תהליך יצירת טיוטה עתידי
בהמשך נבנה תהליך בסיסי שמתחיל ב-Chat Trigger. כל הודעה היא מקרה בדיקה שלם ב-JSON וכוללת request, מערך sources, שדה draft שיכול להיות null, ו-max_rewrites שמתחיל ב-2. request מכיל את טקסט המייל המלא. sources מכיל רק את רשומות הקטלוג, עם source_id ותוכן המקור. המייל אינו פריט ב-sources. כש-sources ריק, המייל נשאר ב-request. כתוב קוד פענוח ובדיקת קלט, ללא קריאת LLM נוספת לשלב הזה. אם draft הוא null, צור טיוטה באמצעות המודל. אם סופקה טיוטה, העבר אותה כפי שהיא לבדיקה. הכן לי הודעת בדיקה מלאה להעתקה מתוך החומרים שב-REVIEW_START.md. אל תסתמך על זיכרון הצאט. החזר את הטיוטה לצאט. החלטת ביקורת תתווסף רק בשלב הבא.
- השתמש ב-Basic LLM Chain מחובר ל-OpenRouter Chat Model במחבר ה-Model של השרשרת.
- אכוף פלט מובנה באמצעות Structured Output Parser: title ו-objective כמחרוזות, steps ו-open_questions כמערכי מחרוזות, success_criteria כמחרוזת או null, ו-source_ids כמערך מחרוזות.
- מקור שלא מגדיר סף הצלחה משאיר success_criteria בערך null.
- נתון חסר הופך לשאלה פתוחה ב-open_questions, לא להמצאה.
- התייחס לבודק עתידי כאל קריאת LLM נפרדת, לא כאל סוכן. אל תבנה אותו עכשיו.

# תיקיית העבודה ב-n8n
השתמש בתיקיית המודול שלי ב-n8n עם שם ייחודי, לדוגמא: 18x | Module 3 | Practice | Review.
אל תזהה את התיקייה המקומית במחשב עם התיקייה ב-n8n.

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

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

מקור קטלוגי:
- source_id: M3-CAT-01
- equipment: scanner-rig
- purpose: movement-tracking
- description: שני קוראים נייחים ליד מעבר. העגלות עם התגיות נעות בין אזורי הקריאה.
- capabilities: שמירת מזהה תג, מזהה קורא וחותמת זמן בנפרד לכל קריאה.
- source_version: demo-v1
- provenance: מקור הוראה מדומה

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

Prepare an n8n drafting project base. For now create only CLAUDE.md and REVIEW_START.md, without building a workflow. Save the base requirements and the complete sources below in REVIEW_START.md. After inspecting the files I will open a new session and ask you to read them and propose a plan.

# Step one: the context file
Check whether a CLAUDE.md file exists in the current project folder.
If it is missing, create it. If it exists, propose an update instead of overwriting.
Write these fixed working rules into it:
- For LLM calls use OpenRouter only.
- Build simple LLM calls using a Basic LLM Chain together with an OpenRouter Chat Model. No AI Agent and no agent blocks.
- Keep system instructions separate from request data.
- A missing value stays missing and leads to a question, not to invention.
- Work in a unique copy and preserve the source.
- Do not store keys or secrets in the file. The OpenRouter connection is configured in n8n Credentials only.
- Add explanatory notes on nodes, check real output, and state explicitly what was not tested.

# Future requirements to save in REVIEW_START.md
## Future drafting process
Later we will build a base process starting with a Chat Trigger. Each message is a complete JSON test case containing request, a sources array, a draft field that can be null, and max_rewrites initially set to 2. request contains the complete email text. sources contains only catalog records with source_id and source content. The email is not an item in sources. When sources is empty, the email remains in request. Write parsing and input validation code without an additional LLM call for this step. If draft is null, generate a draft using the model. If a draft is supplied, pass it through unchanged for review. Prepare a complete copyable test message using the materials in REVIEW_START.md. Do not rely on chat memory. Return the draft to chat. A review decision will be added only in the next stage.
- Use a Basic LLM Chain connected to an OpenRouter Chat Model on the chain Model connector.
- Enforce structured output with a Structured Output Parser: title and objective are strings, steps and open_questions are string arrays, success_criteria is a string or null, and source_ids is a string array.
- A source that does not define a success threshold leaves success_criteria as null.
- A missing value becomes an open question in open_questions, not an invention.
- Treat a future reviewer as a separate LLM call, not an agent. Do not build it now.

# n8n working folder
Use my module folder in n8n with a unique name, for example: 18x | Module 3 | Practice | Review.
Do not identify the local folder on the machine with the folder in n8n.

# The sources for testing
Use the following sources as sample input:

Request email:
"Roni, can we test next week what happens when the carts pass between the two readers? It matters to me to see when both of them report the same tag.
We will start with one cart and then add two more. Save the reads and times from each reader separately, so we can compare afterwards. Tuesday morning is preferred. The location is not final yet.
Both readers will stay fixed at the crossing stations. Only the carts move between them."

Catalog source:
- source_id: M3-CAT-01
- equipment: scanner-rig
- purpose: movement-tracking
- description: Two fixed readers near a crossing. The carts with tags move between the reading zones.
- capabilities: Store tag id, reader id and timestamp separately for each read.
- source_version: demo-v1
- provenance: Simulated instructional source

# Working style
On the first run show me a short plan before you build. After I approve, build. Do not ask for approval on every single node.
Return narrative output in Hebrew. Select an accessible OpenRouter model from its available catalog, without inventing a model ID.
For now save only the two files, show their paths and contents, then stop. Do not build or run a workflow at this stage.

בדקו את הקבצים: CLAUDE.md כולל את כללי העבודה. REVIEW_START.md כולל את דרישות התהליך, המייל והמקור המלא M3-CAT-01.

פתחו שיחה חדשה בלשונית Code באותה תיקייה. הריצו /context וודאו ש-CLAUDE.md מופיע ב-Memory files.

קרא את CLAUDE.md ואת REVIEW_START.md בתיקייה הנוכחית. הצע תוכנית קצרה לבסיס יצירת הטיוטה בלבד. לאחר שאאשר בנה והריץ אותו ב-n8n.

Read CLAUDE.md and REVIEW_START.md in the current folder. Propose a short plan for the drafting base only. After I approve, build and run it in n8n.

אשרו את התוכנית. ב-n8n פתחו את התהליך ולחצו Open chat. בקשו מ-Claude להכין מ-REVIEW_START.md הודעת JSON מלאה עם request, sources, draft ו-max_rewrites. הריצו ובדקו: draft=null יוצר טיוטה, וטיוטה שסופקה נשמרת ללא יצירה מחדש.

פרק 2: מתייעצים ומוסיפים ביקורת

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

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

בנו Reviewer ו-Rewriter כשתי קריאות נפרדות: Basic LLM Chain מחובר ל-OpenRouter Chat Model, ללא AI Agent. הניתוב וספירת השכתובים מתבצעים בקוד ובצומתי n8n.

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

השאירו את המייל המלא ב-request ואת M3-CAT-01 ב-sources. בקשו מ-Claude להכין הודעת בדיקה מלאה לכל מקרה. כל ריצה מתחילה במונה שכתובים מאופס. ב-Executions בדקו טיוטה, ביקורת, מספר שכתובים וסיבת עצירה.

{
  "title": "ניסוי קריאות חופפות",
  "objective": "בדיקת דיווח של שני קוראים על אותו תג",
  "steps": [
    "מתחילים מיד בשלוש עגלות בחיפה.",
    "שומרים קובץ קריאות אחד ללא מזהה קורא."
  ],
  "success_criteria": "דיוק של 99%",
  "open_questions": [],
  "source_ids": ["M3-CAT-01"]
}

{
  "title": "Overlapping reads experiment",
  "objective": "Check reporting of two readers on the same tag",
  "steps": [
    "Start immediately with three carts in Haifa.",
    "Save a single reads file without reader id."
  ],
  "success_criteria": "99% accuracy",
  "open_questions": [],
  "source_ids": ["M3-CAT-01"]
}

{
  "title": "טיוטת ניסוי קריאות חופפות",
  "objective": "בדיקת דיווח של שני קוראים על אותו תג",
  "steps": [
    "צעד עבודה מוצע: לבקש אישור למיקום, לשעה המדויקת ולסף ההצלחה לפני תיאום.",
    "מתחילים בעגלה אחת בין שני קוראים קבועים, ואז מוסיפים עוד שתי עגלות.",
    "שומרים מזהה תג, מזהה קורא וחותמת זמן בנפרד לכל קריאה, ומשווים קריאות של שני הקוראים על אותו תג."
  ],
  "success_criteria": null,
  "open_questions": [
    "מה מיקום הניסוי?",
    "מה שעת ההתחלה המדויקת?",
    "מה סף ההצלחה המוסכם?"
  ],
  "source_ids": ["M3-CAT-01"]
}

{
  "title": "Overlapping reads experiment draft",
  "objective": "Check reporting of two readers on the same tag",
  "steps": [
    "Suggested work step: request approval for the location, exact time and success threshold before coordination.",
    "Start with one cart between two fixed readers, then add two more carts.",
    "Save tag id, reader id and timestamp separately for each read, and compare reads of both readers on the same tag."
  ],
  "success_criteria": null,
  "open_questions": [
    "What is the experiment location?",
    "What is the exact start time?",
    "What is the agreed success threshold?"
  ],
  "source_ids": ["M3-CAT-01"]
}

1. תקינה: טיוטה תקינה, מקורות מלאים ומכסה 2. צפוי: מעבר לבדיקת אדם ללא שכתוב, גם כשיש שאלות פתוחות. התאימו את הטיוטה גם לקריטריון שבחרתם.
2. לקויה: טיוטה לקויה, מקורות מלאים ומכסה 2. צפוי: תיקון סדר העגלות, שמירת מזהה קורא והסרת חיפה ו-99% שאינם במקור.
3. מקור חסר: השאירו מייל מלא וטיוטה לקויה, והגדירו sources=[]. צפוי: עצירה ובקשת מקור או אדם, ללא שכתוב.
4. מכסה: החזירו את המקור, השאירו טיוטה לקויה והגדירו max_rewrites=0. צפוי: ללא שכתוב. החזירו ל-2 בסיום. בדיקה זו בודקת חסימה בכניסה בלבד. אם לא נבדקה עצירה אחרי שני שכתובים כושלים, ציינו זאת.

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

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

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

המטרה: לשמור ב-CLAUDE.md ידע וכלל עבודה מאומת, כדי ש-Claude יוכל להשתמש בהם בשיחה הבאה.

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

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

קרא את CLAUDE.md ואת המקור והפלט של הבדיקה שאצרף. אם חסר אחד מהם, בקש אותו לפני הסקת מסקנות.

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

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

Read CLAUDE.md and the test source and output I append. If any is missing, request it before drawing conclusions.

Check the discrepancy against the source. Propose a fix and a repeat test. After we verify the fix, update CLAUDE.md in Markdown:
- Verified knowledge with a source reference.
- The observed error or risk. Record a cause only if verified. Otherwise state that the cause is not established, and that a seeded test demonstrated the risk if that was the test performed.
- A short, testable rule to prevent recurrence.
- The test case and observed result. State explicitly if it was not run.

Check whether a suitable rule already exists. Update it instead of duplicating it. Preserve existing rules that do not conflict with the fix. Do not turn a hypothesis into a fact or generalize incidental test data to every request.
Show the file changes. Do not claim that this file trains the model. Keep the project documentation and explanations in Hebrew.

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

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

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

תרגול פתוח

לבחירה להעמקה, אין צורך לבצע את שתי ההרחבות.

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

שאלות להמשך מחקר

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

הפוסט מודול 3 | תרגול 3: ביקורת ושכתוב עם Claude Code הופיע לראשונה ב-Almaya.

משך התרגול: כ-50 דקות.

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

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

אתם מגדירים את הכללים ובודקים את התוצאה. Claude Code בונה, ואת כללי העבודה והלקחים שתבדקו תשמרו ב-CLAUDE.md לשיחות הבאות.

פרק 1: יוצרים הוראות לפרויקט

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

1. פתחו את Claude Desktop בלשונית Code ובחרו את תיקיית הפרויקט שלכם.
2. בקשו ליצור או לעדכן את CLAUDE.md לפי הפרומפט הבא, בלי לבנות עדיין תהליך.

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

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

# כללי עבודה לפרויקט

## ארכיטקטורה ב-n8n
- השתמש ב-OpenRouter בלבד לקריאות למודל שפה.
- השתמש בקריאות LLM רגילות באמצעות Basic LLM Chain יחד עם OpenRouter Chat Model.
- אל תשתמש ב-AI Agent ואל תשתמש בבלוקים של סוכנים.

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

## עבודה בטוחה
- עבוד תמיד בעותק ייחודי ושמור את המקור.
- אל תשמור מפתחות או סודות בתוך הקובץ הזה או בכל קובץ אחר.

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

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

Check whether CLAUDE.md exists in the current directory. If missing, create it. If present, propose an update and preserve existing rules that do not conflict with these requirements. Do not overwrite it. Do not build a workflow or create other files yet.

This file is your permanent rule set for this project. Write the following guidelines in it clearly:

# Project Work Rules

## n8n Architecture
- Use OpenRouter only for language model calls.
- Use plain LLM calls via Basic LLM Chain together with OpenRouter Chat Model.
- Do not use AI Agent and do not use agent blocks.

## Data and Instructions
- System instructions are kept separate from request data.
- Missing data stays missing. Ask when information needed for the current decision is missing, and do not guess.

## Safe Work
- Always work on a unique copy and preserve the original.
- Do not store keys or secrets inside this file or any other file.

## Quality and Documentation
- Add explanatory notes next to the steps.
- Verify real output, not a mock result.
- State explicitly what was not tested.

After creating the file or updating it with my approval, show me its full contents and do nothing further.

3. קראו את הקובץ: בדקו שיש כללים לקריאות LLM רגילות דרך OpenRouter, שמירת חוסרים, עבודה בעותק ובדיקת פלט אמיתי.
4. פתחו שיחה חדשה בלשונית Code, באותה תיקייה. הריצו /context ובדקו ש-CLAUDE.md מופיע ב-Memory files. אם לא, בדקו את שם הקובץ ותיקיית העבודה.

הקובץ מספק הקשר ל-Claude Code. הוראות המודל בתוך n8n מוגדרות בנפרד. בדקו בהמשך גם שהתהליך עומד בכללים.

פרק 2: בונים חילוץ ממייל לטופס

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

המייל המוכן, נשלח ב-2026-10-22: נתוני התרגול מדומים.

את הקטלוג תיצרו בפרק 3 כטבלת Data Table ב-n8n. שם תמצאו את כל תשע העמודות ואת שלוש הרשומות המלאות מההדגמה.

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

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

• קלט ופלט: Chat Trigger, קריאת Basic LLM Chain עם OpenRouter Chat Model ופלט מובנה דרך Structured Output Parser. ללא AI Agent וללא זיכרון שיחה.
• שדות: test_name, objective, equipment_description, equipment, site, requested_time_text, additional_details.
• שמירת המקור: equipment נשאר null עד לפרק 3. מיקום חסר נשאר null. שומרים את ניסוח הזמן ואת כל פרטי העגלות והתיעוד. ל-test_name מותר ליצור כותרת קצרה מתוך המטרה בלבד.

קרא קודם את CLAUDE.md ופעל לפי הכללים שבו.

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

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

- מתחיל ב-Chat Trigger. כל הודעה חדשה כוללת טקסט מייל חופשי, מפעילה ריצה נפרדת ומחזירה תשובה לצאט. השתמש ב-chatInput כקלט, בלי זיכרון שיחה.
- משתמש ב-Basic LLM Chain יחד עם OpenRouter Chat Model וב-Structured Output Parser לפלט לפי הסכמה. ללא AI Agent.
- מחלץ את השדות הבאים לאובייקט מובנה:
  test_name, objective, equipment_description, equipment, site, requested_time_text, additional_details
- השדה equipment נשאר null בשלב הזה, כי השם המדויק מגיע רק מהקטלוג בשלב מאוחר יותר.
- שדה עובדתי שלא נמסר נשאר null. גם "המיקום עוד לא סגור" פירושו site=null. ל-test_name מותר לתת כותרת קצרה הנגזרת מהמטרה שבמקור, ללא פרטים חדשים.
- המידע שאינו נכנס לשדות המובנים נשמר תחת additional_details.

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

Read CLAUDE.md first and follow its rules.

I have appended the full email from chapter 2, including its sent date, to this message. If it is absent, ask for it before building.

Propose a short plan only, without building yet, for an intake workflow in n8n that does the following:

- Starts with a Chat Trigger. Each new message contains free text email, starts a separate execution and returns a chat response. Use chatInput as input, without conversation memory.
- Uses Basic LLM Chain with OpenRouter Chat Model and Structured Output Parser for schema-based output. No AI Agent.
- Extracts the following fields into a structured object:
  test_name, objective, equipment_description, equipment, site, requested_time_text, additional_details
- The equipment field stays null at this stage, because the exact name comes only from the catalog at a later step.
- A factual field not provided stays null. "The location is not final yet" means site=null. For test_name you may derive a short display title from the stated objective, without new facts.
- Information that does not fit the structured fields is kept under additional_details.

Show me the plan. Build only after I approve. Use a unique name in the Module 3 folder and start with live input through Chat Trigger, without connecting to real email. Keep fixed examples only for repeatable tests. State which available OpenRouter model you will select and why. Do not invent a model ID. Return explanations, text field values and questions in Hebrew. Keep verbatim quotations in the source language, and preserve defined field names and decision values.

אשרו את התוכנית ובקשו לבנות בעותק ייחודי בתיקיית Module 3 ב-n8n. זו תיקייה נפרדת מתיקיית הפרויקט במחשב. השתמשו בחיבור OpenRouter הקיים.

הריצו: פתחו Open chat בתהליך ושלחו את המייל המלא כהודעה אחת.

הציגו ובדקו: המטרה ושלבי העגלות נשמרו, פרטים נוספים מופיעים ב-additional_details, ו-equipment ו-site הם null. אם מידע אבד או הומצא, החזירו ל-Claude את המקור והפלט לתיקון ובדיקה חוזרת.

ה-Parser בודק מבנה. את נכונות המידע בודקים מול המייל.

פרק 3: מתאימים ציוד מהקטלוג

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

יוצרים את טבלת הקטלוג ב-n8n

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

1. באותה שיחת Code בקשו מ-Claude ליצור את הטבלה באמצעות הפרומפט שבהמשך. שלוש הרשומות המלאות כבר כלולות בו.
2. ב-n8n פתחו את הפרויקט שלכם ואת לשונית Data tables. פתחו את הטבלה ש-Claude יצר.
3. בדקו שיש 9 עמודות נתונים ו-3 רשומות בלבד: scanner-rig, mobile-reader ו-antenna-array. עמודות המערכת id, createdAt ו-updatedAt נוספות אוטומטית.

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

שם הטבלה: 18x | Module 3 | Equipment Catalog. כל תשע עמודות הנתונים הן מסוג string.

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

קרא את CLAUDE.md. צור בפרויקט n8n שלי Data Table בשם "18x | Module 3 | Equipment Catalog". הטבלה צריכה להיות באותו פרויקט n8n שבו נמצא תהליך התרגול.

צור בדיוק 9 עמודות מסוג string, בסדר הזה:
equipment, label, source_id, source_version, description, capabilities, purpose, form_test_type, provenance

הכנס בדיוק את שלוש הרשומות הבאות, ללא שינוי בשמות השדות או בטקסט. ערך form_test_type ברשומה השלישית הוא מחרוזת ריקה. אל תיצור ידנית id, createdAt או updatedAt, n8n יוצר אותם.

[
  {
    "equipment": "scanner-rig",
    "label": "מערכת נייחת",
    "source_id": "M3-CAT-01",
    "source_version": "demo-v1",
    "description": "שני קוראים נייחים ליד מעבר. העגלות עם התגיות נעות בין אזורי הקריאה.",
    "capabilities": "שמירת מזהה תג, מזהה קורא וחותמת זמן בנפרד לכל קריאה. מתאים להשוואת קריאות חופפות. המקור אינו מגדיר מהירות, מרחק או סף הצלחה.",
    "purpose": "movement-tracking",
    "form_test_type": "מערכת נייחת | מעקב תנועה",
    "provenance": "נתוני הוראה מדומים למודול 3. מזהי ציוד ומטרה תואמים לטבלת מודול 2. התיאור והיכולות נוספו לצורך התרחיש ואינם מפרט יצרן."
  },
  {
    "equipment": "mobile-reader",
    "label": "קורא נייד",
    "source_id": "M3-CAT-02",
    "source_version": "demo-v1",
    "description": "הקורא נישא בידי מפעיל ונע עם הציוד. אפשר לבצע קריאות של תגיות תוך כדי תנועה.",
    "capabilities": "מזהה תג וחותמת זמן. מתאים לבדיקה שבה הקורא עצמו נע. המקור אינו מגדיר ספי הצלחה.",
    "purpose": "movement-trial",
    "form_test_type": "קורא נייד | ניסוי בתנועה",
    "provenance": "נתוני הוראה מדומים למודול 3. אינו מפרט יצרן."
  },
  {
    "equipment": "antenna-array",
    "label": "מערך אנטנות",
    "source_id": "M3-CAT-03",
    "source_version": "demo-v1",
    "description": "מערך אנטנות לכיוון ולבדיקת יישור לפני ניסוי.",
    "capabilities": "בדיקת יישור של המערך. אין במקור תמיכה בזיהוי קוראים במעבר עגלות.",
    "purpose": "alignment-check",
    "form_test_type": "",
    "provenance": "נתוני הוראה מדומים למודול 3. אינו מפרט יצרן."
  }
]

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

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

Read CLAUDE.md. Create a Data Table named "18x | Module 3 | Equipment Catalog" in my n8n project, the same n8n project as the exercise workflow.

Create exactly 9 string columns in this order:
equipment, label, source_id, source_version, description, capabilities, purpose, form_test_type, provenance

Insert exactly these three records. Preserve all field names and source text verbatim. The third record's form_test_type is an empty string. Do not manually create id, createdAt or updatedAt, n8n generates them.

[
  {
    "equipment": "scanner-rig",
    "label": "מערכת נייחת",
    "source_id": "M3-CAT-01",
    "source_version": "demo-v1",
    "description": "שני קוראים נייחים ליד מעבר. העגלות עם התגיות נעות בין אזורי הקריאה.",
    "capabilities": "שמירת מזהה תג, מזהה קורא וחותמת זמן בנפרד לכל קריאה. מתאים להשוואת קריאות חופפות. המקור אינו מגדיר מהירות, מרחק או סף הצלחה.",
    "purpose": "movement-tracking",
    "form_test_type": "מערכת נייחת | מעקב תנועה",
    "provenance": "נתוני הוראה מדומים למודול 3. מזהי ציוד ומטרה תואמים לטבלת מודול 2. התיאור והיכולות נוספו לצורך התרחיש ואינם מפרט יצרן."
  },
  {
    "equipment": "mobile-reader",
    "label": "קורא נייד",
    "source_id": "M3-CAT-02",
    "source_version": "demo-v1",
    "description": "הקורא נישא בידי מפעיל ונע עם הציוד. אפשר לבצע קריאות של תגיות תוך כדי תנועה.",
    "capabilities": "מזהה תג וחותמת זמן. מתאים לבדיקה שבה הקורא עצמו נע. המקור אינו מגדיר ספי הצלחה.",
    "purpose": "movement-trial",
    "form_test_type": "קורא נייד | ניסוי בתנועה",
    "provenance": "נתוני הוראה מדומים למודול 3. אינו מפרט יצרן."
  },
  {
    "equipment": "antenna-array",
    "label": "מערך אנטנות",
    "source_id": "M3-CAT-03",
    "source_version": "demo-v1",
    "description": "מערך אנטנות לכיוון ולבדיקת יישור לפני ניסוי.",
    "capabilities": "בדיקת יישור של המערך. אין במקור תמיכה בזיהוי קוראים במעבר עגלות.",
    "purpose": "alignment-check",
    "form_test_type": "",
    "provenance": "נתוני הוראה מדומים למודול 3. אינו מפרט יצרן."
  }
]

If a table with this name exists, read it before making any change. Reuse it only if all 9 columns and all 3 records exactly match the supplied data. Otherwise create a separate table with a unique name and leave the existing table unchanged. Do not insert duplicate records.

Read the table back and compare every value with the supplied data. Show its name, ID, row count and column names. Save its name and ID in the project documentation and add a reference in CLAUDE.md. Do not change the extraction workflow yet. Return explanations and project documentation in Hebrew.

אם אתם יוצרים ידנית: בלשונית Data tables בחרו Create Data table ויצירה מאפס. הוסיפו את תשע העמודות שלמעלה מסוג string, ואז הזינו שלוש שורות לפי אובייקטי ה-JSON שבפרומפט. כל אובייקט הוא שורה, וכל מפתח הוא עמודה. השאירו את form_test_type של antenna-array ריק. מסרו ל-Claude את שם הטבלה ובקשו ממנו לאתר אותה, לשמור את השם והמזהה בתיעוד הפרויקט ולהפנות אליהם מ-CLAUDE.md. ערכי הקטלוג הם נתוני הוראה מדומים, לא מפרט יצרן.

בדיקת סיום: פתחו את שלוש השורות והשוו גם description, capabilities ושדות המקור לפרומפט. מקור M3-CAT-01 שייך ל-scanner-rig, מקור M3-CAT-02 ל-mobile-reader ומקור M3-CAT-03 ל-antenna-array. בכולן source_version הוא demo-v1.

מחברים את הטבלה לתהליך

בקשו מ-Claude לקרוא את הטבלה שיצרתם באמצעות Data Table בפעולת Get row(s) עם Return All, ולצרף את כל שלוש הרשומות למייל המקורי ולשדות החילוץ. אשרו תוכנית קצרה ורק אז בנו. שלב ההתאמה צריך לקבל את הרשומות מהטבלה בכל ריצה, ולא עותק קבוע בתוך הפרומפט.

• resolved: ציוד מדויק מהקטלוג, source_id וציטוטים מהבקשה ומהקטלוג שמצדיקים את הבחירה.
• ambiguous: חסר פרט מכריע. מחזירים שאלת הבהרה ומשאירים equipment ו-source_id כ-null.
• no_match: אין ציוד מתאים בקטלוג. מחזירים שאלה ומשאירים את אותם שדות כ-null.

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

קרא את CLAUDE.md ופעל לפי הכללים שבו.

הוסף לתהליך הקליטה הקיים קריאת LLM רגילה נוספת להשלמת ציוד דרך OpenRouter, עם Basic LLM Chain ו-OpenRouter Chat Model. אל תמחק את שלב החילוץ, הוסף שלב אחריו.

קרא את טבלת הקטלוג שיצרנו ותיעדנו בפרק 3, באותו פרויקט n8n. הוסף Data Table בפעולת Get row(s), בחר את הטבלה שלי והפעל Return All ללא סינון. אסוף את כל שלוש הרשומות למערך catalog וחבר אותו למייל המקורי ולשדות החילוץ באותו פריט קלט, כדי שתתבצע קריאת התאמה אחת לכל בקשה. אל תפעיל קריאת מודל נפרדת לכל שורה. אל תכתוב את נתוני הקטלוג כטקסט קבוע בפרומפט ואל תשתמש במזהה הטבלה של המנחה.

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

השלב מקבל את המייל המקורי, את שדות החילוץ ואת הקטלוג. הוא בוחן את תיאור הציוד ומחזיר אחת משלוש התוצאות:
- resolved, עם equipment מהשורה המתאימה, source_id, וציטוטים מהבקשה ומהקטלוג שמראים למה הם תואמים.
- ambiguous, עם שאלת הבהרה, כאשר התיאור יכול להתאים ליותר מפריט אחד או שחסר פרט מכריע.
- no_match, עם שאלה, כאשר אין בקטלוג פריט שמתאים.

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

נתב בעזרת If לפי התוצאה. בלי ראיה מספקת נתב לשאלה ולא להתאמה שרירותית.

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

Read CLAUDE.md and follow its rules.

Add a separate plain LLM equipment resolution call to the existing intake workflow via OpenRouter using Basic LLM Chain and OpenRouter Chat Model. Do not delete the extraction step, add a step after it.

Read the catalog table created and documented in chapter 3 in the same n8n project. Add a Data Table node using Get row(s), select my table and enable Return All with no filters. Collect all three rows in a catalog array and combine it with the original email and extracted fields in one input item, so there is one matching LLM call per request. Do not call the model once per row. Do not hardcode the catalog text in the prompt or use the instructor's table ID.

The catalog contains exactly the 9 fields specified in chapter 3. If the table is empty or cannot be read, stop with an unavailable-source message. Do not classify this as no_match and do not invent a catalog.

The step receives the original email, extracted fields, and catalog. It examines the equipment description and returns one of three outcomes:
- resolved, with equipment from the matching row, source_id, and quotes from the request and catalog showing why they match.
- ambiguous, with a clarifying question, when the description could fit more than one item or a decisive detail is missing.
- no_match, with a question, when no catalog item fits.

The decision is made with respect to the equipment question only. Other missing information in the request, such as an unsettled location, may stay open and does not invalidate a correct equipment match.

Route with If based on the outcome. Without sufficient evidence, route to a question and not to an arbitrary match.

If the decision is not resolved, leave equipment and source_id null and return a question. Check that the ID exists in the catalog and that the quotes occur in the original sources. Add notes. Show a short plan, build after approval, and show actual output for all three test cases.

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

למה להחזיר ראיות?

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

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

מריצים שלושה מקרים

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

1. התאמה ברורה: שלחו את המייל המלא מפרק 2.

הציגו ובדקו: resolved, ציוד scanner-rig, מקור M3-CAT-01 וציטוטים שתומכים בהתאמה.

2. עמימות: שלחו את הטקסט הבא:

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

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

3. אין התאמה: שלחו את הטקסט הבא:

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

הציגו ובדקו: no_match ושאלה על ציוד או מקור מתאים, בלי התאמה שרירותית.

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

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

פרק 4: שומרים לקח לפרויקט

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

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

קרא את CLAUDE.md ואת המקור והפלט של הבדיקה שאצרף. אם חסר אחד מהם, בקש אותו לפני הסקת מסקנות.

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

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

Read CLAUDE.md and the test source and output I append. If any is missing, request it before drawing conclusions.

Check the discrepancy against the source. Propose a fix and a repeat test. After we verify the fix, update CLAUDE.md in Markdown:
- Verified knowledge with a source reference.
- The observed error or risk. Record a cause only if verified. Otherwise state that the cause is not established, and that a seeded test demonstrated the risk if that was the test performed.
- A short, testable rule to prevent recurrence.
- The test case and observed result. State explicitly if it was not run.

Check whether a suitable rule already exists. Update it instead of duplicating it. Preserve existing rules that do not conflict with the fix. Do not turn a hypothesis into a fact or generalize incidental test data to every request.
Show the file changes. Do not claim that this file trains the model. Keep the project documentation and explanations in Hebrew.

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

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

בדקו בשיחה חדשה באותה תיקייה:

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

אם שיניתם את תהליך n8n, הריצו גם אותו שוב ותעדו את התוצאה.

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

תרגול פתוח

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

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

שאלות להמשך מחקר

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

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

הפוסט מודול 3 | תרגול 2: ממייל לטופס עם Claude Code הופיע לראשונה ב-Almaya.

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

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

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

פרק 1: הכנת עותק ב-n8n

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

1. פתחו ב-n8n את התהליך שלכם מתרגול 2. בתפריט שלוש הנקודות שליד שם ה-Workflow בחרו Duplicate.
2. תנו לעותק את השם 18x | Exercise 3 | Managed Build ושמרו. בדיקה: הכותרת מציגה את שם העותק.
3. בדיקה: אתם רואים את הפעולות מתרגול 2. פתחו את Current Weather ואת Send Result Email ובדקו שחיבורי OpenWeatherMap ו-Gmail שלכם עדיין נבחרו.

פרק 2: חיבור Claude Desktop ל-n8n

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

א. הכנת הגישה ב-n8n

1. ב-n8n פתחו Settings ואז Instance-level MCP. הפעילו Enable MCP access אם הוא כבוי. בדיקה: מופיע Enabled. אם ההגדרה חסרה או שאינכם מצליחים להפעיל אותה, קראו למנחה.
2. לחצו Connect. בחלון שנפתח בחרו OAuth, התחברות דרך החשבון. העתיקו את הכתובת המלאה שמופיעה ב-Server URL. היא מסתיימת ב-/mcp-server/http. בדיקה: העתקתם את כל הכתובת. אם מופיע תפריט לבחירת לקוח, בחרו Claude.ai או Claude Desktop.
3. חזרו לעותק התרגול. בתפריט שלוש הנקודות פתחו Settings, הפעילו Available in MCP ושמרו. ההגדרה מאפשרת ל-Claude לגשת לעותק הזה.

ב. הוספת החיבור ב-Claude Desktop

1. ב-Claude Desktop פתחו Customize ואז Connectors, רשימת החיבורים. אם Connectors נמצא אצלכם תחת Settings, פתחו אותו משם.
2. בחרו Add, ואז Custom ו-Web. בחלק מהגרסאות הכפתור נקרא Add custom connector. כתבו בשם החיבור n8n MCP והדביקו בכתובת את Server URL שהעתקתם.
3. המשיכו עם Continue או Add, לפי המסך. כשתתבקשו להתחבר, היכנסו לחשבון n8n שלכם ואשרו את החיבור. בדיקה: n8n MCP מופיע כמחובר. אם מוצגת אפשרות Register automatically, בחרו בה.
4. פתחו שיחה חדשה ב-Claude Desktop. בתפריט + של השיחה פתחו Connectors והפעילו את n8n MCP. בדיקה: החיבור פעיל לשיחה. בפרק הבא נוכיח קריאה בפועל.

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

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

לעזרה: חיבור Claude Desktop בתיעוד n8n והוספת Connectors בתיעוד Claude.

פרק 3: בדיקת קריאת ה-Workflow

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

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

מה לבדוק מול העורך:

• השם המדויק: 18x | Exercise 3 | Managed Build.
• תשעת ה-Nodes של השלד, בתוספת שינויים שהוספתם בתרגול הפתוח.
• ה-Node בשם Current Weather.
• תנאי הרוח Wind Above 5.
• תנאי המייל Email Provided.

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

## הקשר
יש לי Workflow ב-n8n בשם "18x | Exercise 3 | Managed Build", מחובר אליך דרך MCP.
כתובת העותק: [הדביקו את כתובת ה-Workflow מהדפדפן].
ענה בעברית.

## מצב
אני רק רוצה לוודא שאתה קורא את התהליך הנכון. אל תשנה שום דבר בשלב הזה.

## משימה
קרא בלבד את ה-Workflow לפי שמו המדויק, והחזר לי:
1. את מזהה ה-Workflow
2. את רשימת כל ה-Nodes לפי שם
3. את המסלול עם מייל ואת המסלול בלי מייל, לפי Email Provided

## תנאי סיום
קרא את העותק דרך חיבור n8n והצג את השמות שמצאת. אל תשנה דבר.

## Context
I have an n8n Workflow named "18x | Exercise 3 | Managed Build", connected to you via MCP.
Copy URL: [paste the workflow URL from the browser].
Respond in English.

## State
I only want to confirm you are reading the correct workflow. Do not change anything at this stage.

## Task
Read ONLY the workflow by its exact name, and return to me:
1. The workflow ID
2. The list of all Nodes by name
3. The email and no-email routes selected by Email Provided

## Done Condition
Read the copy through the n8n connector and show the names you found. Do not change anything.

פרק 4: הוספת שדה "זמן בדיקה" – תוכנית לפני ביצוע

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

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

תנאי קבלה: מה צריך להופיע אחרי השינוי?

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

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

## הקשר
ב-Workflow "18x | Exercise 3 | Managed Build" יש תהליך שבודק מזג אוויר ומציג תוצאה למשתמש, וגם שולח מייל במסלול מסוים.

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

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

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

## Context
In the workflow "18x | Exercise 3 | Managed Build" there is a process that checks weather and shows a result to the user, and also sends an email on a certain route.

## State
Respond in English. I want to display the workflow run time, so the user knows when this check ran. Do not make any changes before I approve the plan.

## Task
Step A: Show me a PLAN ONLY for adding a field called checked_at, and for displaying the Hebrew label "זמן בדיקה" on the Show Result screen with date, time, and a clear timezone. The same display should be added to the existing email.
Step B: Only after I explicitly approve, perform the change in the copy ONLY.

## Done Condition
- The checked_at field appears in the output.
- The time is shown on the screen in a readable way.
- The city, email, wind speed, and result text remain available.
- Keep the wind threshold, existing connections, and node arrangement unchanged.
- Do not send email and do not publish the workflow.
- At the end, show a precise list of what you changed and what you verified.

פרק 5: בדיקת הזמן והתנאים בריצה

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

1. פתחו את קישור העותק ש-Claude החזיר ובחרו Editor. בדקו שהשם והכתובת בדפדפן תואמים לעותק שמסרתם לו בפרק 3.
2. פתחו את Report Data וחפשו את השדה checked_at בהגדרות. אם Claude הוסיף אותו בפעולה אחרת, פתחו אותה לפי ההסבר שלו.
3. סגרו את ה-Node ולחצו Execute workflow או Execute. פתחו את הטופס שנפתח, או העתיקו את Test URL מתוך Request Form ללשונית חדשה. בחרו עיר, השאירו מייל ריק והגישו.
4. בדיקה: המסך מציג עיר, רוח, תוצאה וזמן בדיקה. התאריך, השעה ואזור הזמן מתאימים למועד ההרצה. חזרו לעורך, פתחו את ה-Node שמפיק checked_at, והשוו את הפלט מהריצה החדשה לזמן שבמסך.
5. פתחו את Wind Above 5. השוו את wind.speed בקלט לסף, ובדקו שהמסלול עם פריט הנתונים תואם לתוצאה שעל המסך.
6. פתחו את Email Provided. ב-False Branch מופיע פריט נתונים, ו-Send Result Email לא רץ. זו התוצאה הצפויה כששדה המייל ריק.
7. לבדיקת המייל, הפעילו שוב Execute, פתחו את הטופס והזינו את המייל שלכם. הגישו ובדקו שההודעה הגיעה עם אותו זמן שמופיע במסך התוצאה. ב-Email Provided בדקו שהנתונים עברו הפעם ב-True Branch.

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

תרגול פתוח: ניהול בניית תהליך חדש

כעת תעבירו את שיטת העבודה לפעולה אחרת. תגדירו קלט ופלט ותבדקו אם Claude בנה את מה שהתכוונתם. ב-Claude Desktop פתחו שיחה חדשה. בתפריט + של השיחה פתחו Connectors והפעילו את n8n MCP. תארו בשיחה החדשה את כל הדרוש, כי היא אינה מכירה את השיחה הקודמת.

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

אם בחרתם מקרה אישי, בשיחה החדשה תארו:

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

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

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

# הפעולה שבחרתי
אני רוצה לבנות ב-n8n תהליך חדש דרך MCP.
שם התהליך החדש: [שם ייחודי].
הפעולה בעבודה: [פעולה אחת].
קלט לדוגמה: [נתוני דוגמה שאינם רגישים].
פלט רצוי: [מה צריך להופיע].
מקרה תקין: [קלט ופלט צפוי].
מקרה חריג: [קלט ופלט צפוי].
האדם שאחראי לבדוק או לאשר: [תפקיד].

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

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

# My chosen task
I want to build a new n8n workflow through MCP.
New workflow name: [unique name].
Workplace action: [one action].
Sample input: [non-sensitive example data].
Desired output: [what should appear].
Normal case: [input and expected output].
Exception case: [input and expected output].
Person responsible for checking or approval: [role].

## Working method
Respond in English. Ask about material gaps and propose a short plan before building. If the information is sufficient, say so and propose the plan.
Once I approve a plan and a specific change, perform only that change in a new workflow through n8n tools.
Do not send messages, change data in external systems, or publish without separate explicit approval.
Use sample data and manual executions for testing.
After each change return a link, what changed, and what you actually tested. State anything that remains untested.

## Completion
A skeleton that opens in n8n with normal and exception tests. If a connection is unavailable, prepare two sample inputs and expected outputs and test up to the preceding node. Show Input and Output and identify what remains untested. The human decision remains with the role I named.

חלופה: בדיקת סכום בקשת רכש

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

1. הגדרת התרחיש:
   • קלט לדוגמה: סכום של 300 ש"ח.
   • כלל: מעל 1000 ש"ח עובר למסלול "לאישור אחראי רכש", אחרת "לבדיקה רגילה".
   • אין החלטת רכישה בפועל ואין שליחת מייל.
   • אחראי אנושי: אחראי הרכש.
2. בניית שלד בדיקה פשוט:
   • Manual Trigger.
   • Edit Fields בשם Request Data עם שדה amount.
   • IF בוחר מסלול לפי הסכום. Edit Fields בכל מסלול מגדיר בשדה route את טקסט התוצאה, ומשמר גם את amount בפלט.
3. בדיקה:
   • אשרו ל-Claude תחילה לבנות Manual Trigger ו-Request Data עם amount מספרי בערך 300, ולהריץ ידנית. בדיקה: ב-Request Data סוג השדה amount הוא Number, וב-Output רואים amount=300. לאחר מכן אשרו הוספת IF ושני טקסטי התוצאה.
   • בקשו להריץ עם 300. בדיקה: route הוא "לבדיקה רגילה". בקשו לשנות רק את amount ל-1500 ולהריץ שוב. בדיקה: route הוא "לאישור אחראי רכש". ב-Executions בחרו כל אחת משתי הריצות והשוו את הפלט.
   • בדקו את ה-route ואת הסכום בפלט.
   • אל תוסיפו חיבור למערכת אמיתית. כל שינוי והרצה חייבים להתבצע בכלים, לא רק כקוד בצ'אט.

## הקשר
אני רוצה לבנות ב-n8n שלד תהליך חדש לבדיקת סכום בקשת רכש. אתה מחובר אלי דרך MCP.
ענה בעברית. אחראי הרכש הוא האדם שיחליט על הרכישה.

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

## משימה
התהליך צריך לכלול:
- Manual Trigger
- Edit Fields בשם Request Data עם שדה amount מספרי
- בכל מסלול תוצאה שמור גם amount לצד route
- IF שמנתב: מעל 1000 ש"ח למסלול "לאישור אחראי רכש", אחרת "לבדיקה רגילה"
תן לתהליך שם חדש, ואל תיגע בתהליכים אחרים.

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

## Context
I want to build a new workflow skeleton in n8n to check a purchase request amount. You are connected to me via MCP.
Respond in English. The purchasing manager decides whether to purchase.

## State
This is a test skeleton only. No connection to a real system, no purchase decision, and no email sending. Before building, ask about missing information or propose a short plan if the information is sufficient. Wait for approval of the plan and the specific change.

## Task
The workflow should include:
- Manual Trigger
- Edit Fields named Request Data with a numeric amount field
- Preserve amount alongside route in each result output
- IF that routes: above NIS 1000 to the Hebrew route value "לאישור אחראי רכש", otherwise "לבדיקה רגילה". Keep these Hebrew labels so the output matches the exercise.
Give the workflow a new name, and do not touch other workflows.

## Done Condition
- First, resolve any material gaps and present a short plan.
- After my approval, build only a small first step.
- Test a normal case with 300 and a case requiring approval with 1500, and show the route and amount in the output.
- All building and running must be done with real tools, not as code in chat.

תוצר ותנאי סיום

בדקו שבסיום יש לכם את התוצרים הבאים:

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

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

שאלות להמשך מחקר

אפשר לחזור אליהן אחרי התרגול:

1. איך אפשר להגדיר תנאי קבלה שיגרמו ל-Claude לעצור ולשאול לפני כל שינוי שעלול לשבור נתונים קיימים? (בדקו ב-Claude ובתיעוד של n8n MCP).
2. אילו כלי קריאה ועדכון חושף ה-MCP של n8n, ואיך תזהו מראש אם לכלי מסוים אין הרשאה? (שאלו את Claude להציג את רשימת הכלים הזמינים).
3. איך הייתם בונים "דרך חזרה בטוחה" (rollback) לכל שינוי מנוהל, כך שתמיד יהיה עותק עובד לחזור אליו? (סיעור מוחות עם Claude על אסטרטגיות גיבוי של Workflows).

הפוסט תרגול 3 | בניית Workflow עם Claude Desktop הופיע לראשונה ב-Almaya.

פרק 1: פתיחת Workflow והדבקת השלד

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

1. ב-n8n פתחו Overview, לחצו Create workflow ובחרו Start from scratch אם מוצגת בחירה. תנו לתהליך שם: 18x | Exercise 2 | Form and Wind.
2. פתחו את "שלד ה-Workflow להעתקה" שלמטה ולחצו COPY. לחצו בשטח הריק של ה-Canvas והדביקו באמצעות Ctrl+V ב-Windows או Cmd+V ב-Mac.
3. בדיקה: מופיעים תשעה Nodes מחוברים. לחצו Zoom to Fit כדי לראות את כולם. אם הודבקו רק טקסט או חלק מה-Nodes, מחקו את ההדבקה השגויה ב-Undo והעתיקו שוב את הבלוק כולו.
4. פתחו בלחיצה כפולה את Current Weather ובחרו את חיבור OpenWeatherMap מתרגול 1. פתחו את Send Result Email ובחרו את חיבור Gmail המאושר מאותו תרגול.
5. בדיקה: בשני ה-Nodes מופיע שם החיבור שבחרתם. גם אם n8n בחר חיבור אוטומטית, בדקו שזה החיבור הנכון. שמרו באמצעות Save אם מוצג כפתור, או המתינו לשמירה האוטומטית.

{
  "nodes": [
    {
      "id": "ex02-01",
      "name": "Request Form",
      "type": "n8n-nodes-base.formTrigger",
      "typeVersion": 2.6,
      "position": [
        0,
        176
      ],
      "parameters": {
        "formTitle": "בדיקת רוח לפי עיר",
        "formDescription": "בחרו עיר. אפשר להזין כתובת מייל כדי לקבל גם הודעה. הסף בתרגול אינו אישור לביצוע ניסוי.",
        "formFields": {
          "values": [
            {
              "fieldLabel": "עיר",
              "fieldName": "city",
              "fieldType": "dropdown",
              "fieldOptions": {
                "values": [
                  {
                    "option": "Tel Aviv,IL"
                  },
                  {
                    "option": "Haifa,IL"
                  }
                ]
              },
              "requiredField": true
            },
            {
              "fieldLabel": "מייל לקבלת התוצאה (לא חובה)",
              "fieldName": "email",
              "fieldType": "email",
              "requiredField": false
            }
          ]
        },
        "responseMode": "lastNode",
        "options": {
          "appendAttribution": false,
          "buttonLabel": "בדיקת רוח",
          "customCss": "body, .n8n-form, .form-header, label { direction: rtl; text-align: right; } input[type=email] { direction:ltr; text-align:left; }"
        }
      }
    },
    {
      "id": "ex02-02",
      "name": "Current Weather",
      "type": "n8n-nodes-base.openWeatherMap",
      "typeVersion": 1,
      "position": [
        224,
        176
      ],
      "parameters": {
        "operation": "currentWeather",
        "format": "metric",
        "locationSelection": "cityName",
        "cityName": "={{ $json.city }}"
      }
    },
    {
      "id": "ex02-03",
      "name": "Wind Above 5",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        448,
        176
      ],
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "condition-gt",
              "leftValue": "={{ $json.wind.speed }}",
              "rightValue": 5,
              "operator": {
                "type": "number",
                "operation": "gt"
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      }
    },
    {
      "id": "ex02-04",
      "name": "Above Threshold",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.5,
      "position": [
        672,
        80
      ],
      "parameters": {
        "mode": "manual",
        "assignments": {
          "assignments": [
            {
              "id": "result",
              "name": "result",
              "type": "string",
              "value": "הרוח מעל הסף שהוגדר לתרגול"
            }
          ]
        },
        "includeOtherFields": true,
        "options": {}
      }
    },
    {
      "id": "ex02-05",
      "name": "Report Data",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.5,
      "position": [
        896,
        176
      ],
      "parameters": {
        "mode": "manual",
        "assignments": {
          "assignments": [
            {
              "id": "city",
              "name": "city",
              "type": "string",
              "value": "={{ $('Request Form').item.json.city }}"
            },
            {
              "id": "recipient",
              "name": "email",
              "type": "string",
              "value": "={{ $('Request Form').item.json.email || '' }}"
            },
            {
              "id": "wind",
              "name": "wind_speed",
              "type": "number",
              "value": "={{ $json.wind.speed }}"
            },
            {
              "id": "result",
              "name": "result",
              "type": "string",
              "value": "={{ $json.result }}"
            },
            {
              "id": "html",
              "name": "html_message",
              "type": "string",
              "value": "=<div dir=\"rtl\" style=\"box-sizing:border-box;max-width:560px;margin:40px auto;padding:28px;background:#fff;border:1px solid #d9e2ec;border-radius:12px;font-family:Arial,sans-serif;font-size:18px;line-height:1.8;text-align:right;color:#17314f;\"><h2 style=\"font-size:24px;margin:0 0 20px;\">תוצאת בדיקת הרוח</h2><p>עיר: {{ $('Request Form').item.json.city }}</p><p>מהירות רוח: {{ $json.wind.speed }} מטר לשנייה</p><p style=\"padding:12px;background:#edf3fa;border-radius:7px;\"><strong>{{ $json.result }}</strong></p><p style=\"font-size:14px;\">זהו סף לתרגול. ההחלטה על ניסוי נשארת בידי האחראי.</p></div>"
            }
          ]
        },
        "options": {}
      },
      "notes": "מוכן מראש: אוסף עיר ומייל מהטופס, רוח ותוצאה מהבדיקה, ומכין תצוגה. בתרגול בודקים את ה-Input וה-Output."
    },
    {
      "id": "ex02-06",
      "name": "Not Above Threshold",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.5,
      "position": [
        672,
        272
      ],
      "parameters": {
        "mode": "manual",
        "assignments": {
          "assignments": [
            {
              "id": "result",
              "name": "result",
              "type": "string",
              "value": "הרוח אינה מעל הסף שהוגדר לתרגול"
            }
          ]
        },
        "includeOtherFields": true,
        "options": {}
      }
    },
    {
      "id": "ex02-07",
      "name": "Email Provided",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        1120,
        176
      ],
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "condition-notEmpty",
              "leftValue": "={{ $json.email }}",
              "rightValue": "",
              "operator": {
                "type": "string",
                "operation": "notEmpty",
                "singleValue": true
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      }
    },
    {
      "id": "ex02-08",
      "name": "Send Result Email",
      "type": "n8n-nodes-base.gmail",
      "typeVersion": 2.2,
      "position": [
        1344,
        32
      ],
      "parameters": {
        "resource": "message",
        "operation": "send",
        "sendTo": "={{ $json.email }}",
        "subject": "18x | תוצאת בדיקת הרוח",
        "emailType": "html",
        "message": "={{ $json.html_message }}",
        "options": {
          "appendAttribution": false
        }
      }
    },
    {
      "id": "ex02-09",
      "name": "Show Result",
      "type": "n8n-nodes-base.form",
      "typeVersion": 2.5,
      "position": [
        1568,
        176
      ],
      "parameters": {
        "operation": "completion",
        "respondWith": "showText",
        "responseText": "={{ $('Report Data').item.json.html_message }}"
      }
    }
  ],
  "connections": {
    "Request Form": {
      "main": [
        [
          {
            "node": "Current Weather",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Current Weather": {
      "main": [
        [
          {
            "node": "Wind Above 5",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Wind Above 5": {
      "main": [
        [
          {
            "node": "Above Threshold",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Not Above Threshold",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Above Threshold": {
      "main": [
        [
          {
            "node": "Report Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Report Data": {
      "main": [
        [
          {
            "node": "Email Provided",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Not Above Threshold": {
      "main": [
        [
          {
            "node": "Report Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Email Provided": {
      "main": [
        [
          {
            "node": "Send Result Email",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Show Result",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Send Result Email": {
      "main": [
        [
          {
            "node": "Show Result",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "pinData": {}
}

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

פרק 2: בדיקת הטופס ושדות הקלט

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

1. פתחו את Request Form. ב-Form Title מופיעה הכותרת "בדיקת רוח לפי עיר". תחת Form Elements פתחו את שדה העיר הקיים.
2. ודאו ש-Field Name הוא city, ש-Element Type הוא Dropdown וש-Required Field מופעל. האפשרויות הן Tel Aviv,IL ו-Haifa,IL.
3. פתחו את שדה המייל הקיים. ודאו ש-Field Name הוא email, שהסוג Email וש-Required Field כבוי. בדיקה: רק שדה העיר מסומן כחובה.
4. סגרו את חלון ה-Node ולחצו Execute workflow, שמופיע בחלק מהמסכים בשם Execute. n8n ממתין להגשת הטופס ופותח אותו בלשונית חדשה. אם לא נפתחה לשונית, פתחו את Request Form והעתיקו את Test URL ללשונית בדפדפן.
5. בחרו עיר, השאירו את המייל ריק ולחצו "בדיקת רוח". המתינו לתוצאת הבדיקה. חזרו לעורך ופתחו את Request Form.
6. בדיקה: ב-OUTPUT מופיע city עם העיר שבחרתם, ו-email ריק. אם הטופס מציג שאינו זמין, חזרו ל-Canvas ולחצו שוב Execute. בכל הגשה חדשה מפעילים מחדש את ההאזנה ואז פותחים או מרעננים את Test URL.

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

פרק 3: בדיקת נתוני הרוח

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

1. פתחו את Current Weather. ודאו שנבחר ה-Credential מתרגול 1 ושההגדרות הן Operation: Current Weather, Format: Metric ו-Location Selection: City Name.
2. ב-INPUT משמאל מצאו את city. השדה City כבר מקבל את העיר מהטופס. בדקו שמתחתיו מופיעה העיר שבחרתם.
3. ב-OUTPUT מימין בחרו Schema, פתחו את wind ומצאו את speed. זהו wind.speed, ומהירות הרוח מוצגת במטר לשנייה.
4. בדיקה: השוו את העיר בטופס לשם המקום ב-name ולמדינה ב-sys.country. המדינה צריכה להיות IL. רשמו את מהירות הרוח שקיבלתם.
5. אם ה-Node נכשל, בדקו את החיבור ואת ערך העיר. בשגיאת 401 חזרו לבדיקת ה-API Key מתרגול 1. בשגיאת 404 בדקו את ערך העיר. אם צריך עזרה מ-Claude, מסרו את נוסח השגיאה ואת שם ה-Node ללא מפתח או פרטי חיבור.

פרק 4: הסתעפות לפי מהירות הרוח

IF בודק תנאי ובוחר מסלול. כאן הוא בודק אם מהירות הרוח גדולה מ-5.

אם הרוח גדולה מ-5, הנתונים עוברים ל-True Branch. אחרת הם עוברים ל-False Branch. אלה שמות המסלולים, לא סימון להצלחה או לתקלה.

1. הגדרת התנאי:
   • פתחו את Wind Above 5, שהוא Node מסוג IF.
   • ב-INPUT פתחו wind וגררו את speed אל השדה הראשון בתנאי. אם כבר מופיע שם מיפוי, ודאו שהתצוגה שלו מראה את מהירות הרוח שקיבלתם.
   • בתפריט ההשוואה בחרו Number ואז is greater than. אם התנאי כבר מוגדר כך, השאירו אותו.
   • בשדה המספר שמתחת לתנאי הזינו 5, ולחצו Execute step. כך בודקים את ה-IF בלי להמשיך לשליחת מייל.
2. שני המסלולים:
   • true מוביל ל-Above Threshold, שמגדיר את התוצאה "הרוח מעל הסף שהוגדר לתרגול".
   • false מוביל ל-Not Above Threshold, שמגדיר את התוצאה "הרוח אינה מעל הסף שהוגדר לתרגול". גם רוח ששווה בדיוק לסף עוברת במסלול הזה.

בדיקה: ב-OUTPUT פתחו את True Branch ואת False Branch. במסלול אחד מופיע פריט נתונים, המסומן 1 item, ובשני אין נתונים. בדקו שהמסלול מתאים למהירות הרוח ולסף 5. בהמשך, Above Threshold או Not Above Threshold מוסיפים את טקסט התוצאה.

פרק 5: בדיקת כתובת המייל ומסך התוצאה

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

1. פתחו תחילה את Report Data. ב-OUTPUT בדקו שמופיעים city, email, wind_speed ו-result. כעת פתחו את Email Provided. אותם שדות מופיעים ב-INPUT שלו.
2. בחרו String ואז is not empty. זו בדיקה אם השדה מכיל ערך. לחצו Execute step ובדקו איזו לשונית OUTPUT מכילה Item.
3. בדיקה: בהגשה הראשונה השארתם מייל ריק, ולכן ה-Item צריך להופיע ב-False Branch. במצב הזה Send Result Email אינו רץ.
4. סגרו את החלון ובדקו את החיבורים ב-Canvas: true מחובר ל-Send Result Email, ומשם ל-Show Result. false מחובר ישירות ל-Show Result.
5. פתחו את Send Result Email ובדקו שנבחר חיבור Gmail שלכם. שדה To כבר מקבל את המייל מהטופס, ו-Message מקבל את התוצאה. בבדיקה הבאה תזינו בטופס את המייל שלכם.
6. פתחו את Show Result, הפעולה שמציגה את מסך התוצאה. בדיקה: גם המסלול עם מייל וגם המסלול בלי מייל מגיעים אליה.

פרק 6: בדיקת שני התנאים

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

עם מייל ובלי מייל

1. לחצו ב-Canvas על Execute, פתחו או רעננו את הטופס, בחרו עיר והזינו כתובת שלכם או נמען מאושר. הגישו פעם אחת.
2. בדיקה: התוצאה מוצגת בטופס. ב-Email Provided רואים Item ב-True Branch, ו-Send Result Email מסומן כמי שבוצע. בדקו שהמייל הגיע ושמהירות הרוח והתוצאה בו תואמות למסך. אם לא הגיע, בדקו גם ספאם ופלט Gmail לפני הרצה נוספת.
3. הפעילו שוב Execute והגישו טופס עם עיר ומייל ריק.
4. בדיקה: התוצאה עדיין מוצגת. ב-Email Provided רואים Item ב-False Branch, ו-Send Result Email אינו מבוצע בריצה הזאת. אפשר לפתוח Executions, לבחור את הריצה האחרונה ולבדוק את שני ה-Nodes. זו הראיה לדילוג על השליחה.

רוח מעל הסף, מתחתיו ובדיוק עליו

לבדיקות האלה פתחו את Wind Above 5 והשתמשו ב-Execute step בתוך ה-Node. כך בודקים את ההשוואה על נתוני מזג האוויר שכבר התקבלו.

1. קראו ב-INPUT את מהירות הרוח. שנו את הסף למספר גדול ממנה ולחצו Execute step. בדיקה: ה-Item מופיע ב-False Branch.
2. שנו את הסף למספר קטן מהמהירות שבקלט והריצו Execute step. בדיקה: ה-Item מופיע ב-True Branch. לדוגמא, לרוח של 1.54 אפשר לבחור סף 0.54. אם הרוח היא 0, אפשר להשתמש בסף -1 לצורך בדיקת התנאי בלבד.
3. קבעו את הסף בדיוק למהירות שבקלט והריצו Execute step. בדיקה: ה-Item מופיע ב-False Branch, מפני ש"גדול מ" אינו כולל שוויון. בדקו שהערך בקלט נשאר זהה בזמן ההשוואה.
4. בסיום החזירו את הסף ל-5 ושמרו. בהרצה הבאה הטופס ישתמש שוב בסף המקורי.

אם התקבל מסלול שונה מהצפוי, השוו את המספר בקלט, את הסף ואת סוג ההשוואה. ודאו שבחרתם Number ו-is greater than.

תרגול פתוח: שינוי אחד בטופס או בתנאי

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

• סף רוח אחר: שנו את הסף ב-Wind Above 5 ולחצו Execute step. בדקו באיזו לשונית OUTPUT מופיע הפריט, והשוו למהירות הרוח שב-INPUT. זו בדיקה של התנאי בלבד.
• הערה בטופס: ב-Request Form הוסיפו שדה Text עם Field Label "הערה" ו-Field Name note. השאירו אותו לא חובה. הגישו טופס עם הערה ובדקו שהיא מופיעה ב-OUTPUT של Request Form. בשינוי הזה בודקים את קליטת ההערה בלבד.

עזרה מ-Claude

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

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

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

## השאלה שלי
הסבר לי איך [לשנות את סף הרוח / להוסיף שדה הערה לטופס / לפתור את הבעיה שתיארתי]. את הפעולות ב-n8n אבצע בעצמי.
[מלאו כאן מה בדיוק אינכם מבינים].

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

# Context
I am practicing in n8n. My workflow receives a city and an optional email address from a form, retrieves current weather, checks whether wind speed is greater than a threshold, and displays a result. It also sends an email only when an address is supplied.
I know how to open nodes, select a credential, drag a field, and inspect Input and Output.

## My current situation
- The node I am in: [node name].
- What I tried: [a short description, or say I have not tried yet].
- What I expected and what actually happened: [output or error message without connection details].

## My question
Explain how to [change the wind threshold / add a notes field to the form / resolve the problem I described]. I will carry out the actions in n8n myself.
[Describe exactly what you do not understand].

## How to respond
Respond in English. Explain in plain language and name the relevant screens and fields.
If you need more information about my situation, ask me. If you need information about the tool, find the relevant official documentation yourself.
I am asking for an explanation only.

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

תוצר וקריטריוני סיום

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

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

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

שאלות להמשך מחקר

• איך בוחרים בין שלושה מסלולים? שאלו את Claude מה עושה Switch ב-n8n ובקשו דוגמא קצרה.
• מה קורה כאשר שדה בטופס אינו חובה והעובד משאיר אותו ריק, איך הערך הריק נראה בפועל בפלט? אפשר לבדוק דרך השוואת פלט של הגשה עם ערך ובלי ערך.
• איך משנים את טקסט התוצאה? פתחו את Above Threshold ושנו את השדה result. הגישו טופס שבוחר במסלול הזה ובדקו מה מופיע על המסך.

הפוסט תרגול 2 | טופס, תנאי והסתעפות ב-n8n הופיע לראשונה ב-Almaya.

התהליך שנבנה: עיר, מזג אוויר ומייל

נחבר ארבע פעולות. כל פעולה מעבירה את הנתונים לפעולה הבאה:

1. Manual Trigger:הכפתור שמתניע את כל התהליך באופן ידני.
2. Edit Fields (Set):כאן נגדיר את שם העיר שאותה נרצה לבדוק.
3. OpenWeatherMap:הבלוק שפונה לשירות מזג האוויר ומחזיר את הנתונים הנוכחיים.
4. Gmail:הבלוק ששולח לנו את הטמפרטורה למייל.

פתחו את n8n והיכנסו לחשבון שקיבלתם בקורס. פתחו גם שיחה חדשה ב-Claude Desktop. הכינו חשבון Gmail משלכם לקבלת התוצאה.

לשליפת מזג האוויר צריך API Key, מפתח גישה מ-OpenWeatherMap. ב-n8n שומרים אותו בחיבור בשם Credential. בשלב 4 תיעזרו ב-Claude כדי לקבל את המפתח וליצור את החיבור. מפתח חדש לא תמיד פועל מיד, ולכן כדאי להתחיל את ההרשמה כבר עכשיו ולבנות בינתיים את שלבים 1 עד 3.

חלק א: בניית התהליך

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

1. פתיחת Workflow חדש ב-Canvas:
   • במסך Overview לחצו Create workflow ובחרו Start from scratch אם מופיעה בחירה. לחצו על שם התהליך בראש המסך, כתבו 18x | תרגול 1 | בדיקת מזג אוויר ואשרו ב-Enter.
   • השטח המרכזי עם הנקודות הוא ה-Canvas. כל בלוק נקרא Node ומבצע פעולה אחת. כאן מוסיפים בלוקים ומחברים ביניהם. לחיצה כפולה על Node פותחת את ההגדרות שלו. סוגרים אותן ב-X בפינה העליונה.
   • בדיקה: אתם רואים Canvas ואת שם התהליך בראש המסך. אם אתם עדיין ברשימת התהליכים, פתחו את התהליך שיצרתם.
2. הוספת Manual Trigger:
   • לחצו על Add first step, חפשו Manual Trigger ובחרו בו. בחלק מהמסכים האפשרות נקראת Trigger manually. אם כבר מופיע Node בשם When clicking Execute workflow, השתמשו בו.
   • לחצו על Execute workflow בתחתית ה-Canvas.
   • בדיקה: ה-Trigger מסומן בירוק. זו הפעלה ידנית של התהליך.
3. הגדרת העיר עם Edit Fields (Set):
   • לחצו על הפלוס שביציאה מה-Trigger, חפשו Edit Fields (Set) ובחרו בו. הפלוס מחבר את ה-Node החדש לקודם.
   • פתחו את ה-Node. בחרו Manual Mapping אם צריך, לחצו Add Field והגדירו שם city, סוג String (טקסט) וערך Tel Aviv,IL.
   • לחצו Execute step. הכפתור מריץ את ה-Node הפתוח ואת השלבים הקודמים שנדרשים לו.
   • בדיקה: בצד ימין, ב-OUTPUT, מופיע השדה city עם הערך Tel Aviv,IL. אם לא, בדקו את שם השדה, הערך והחיבור ל-Trigger.
4. חיבור OpenWeatherMap בעזרת Claude:
   • סגרו את חלון ה-Node, לחצו על הפלוס ביציאה מ-Edit Fields וחפשו OpenWeatherMap. בחרו בפעולה Current Weather.
   • עברו לשיחה ב-Claude Desktop. תארו מה כבר בניתם, והאם יש לכם חשבון OpenWeatherMap או API Key. שאלו איך לקבל מפתח ולחבר אותו ל-n8n. אתם שואלים, קוראים את ההסבר ומבצעים בעצמכם. אם נתקעתם, פתחו את פרומפט העזרה ומלאו בו את המצב שלכם.

    

   נתקעתם? פתחו פרומפט לעזרה

    

   עבריתEnglish

   
   
   # ההקשר
   אני מתחיל ב-n8n. יש לי Workflow עם Manual Trigger ו-Edit Fields שבו city = Tel Aviv,IL. הוספתי OpenWeatherMap כדי לקבל את מזג האוויר הנוכחי.
   המצב שלי כרגע: [עדיין אין לי חשבון OpenWeatherMap / יש לי חשבון אבל אין לי API Key / כבר יש לי API Key].
   
   ## מה אני רוצה להבין
   הסבר לי בעברית איך נרשמים ל-OpenWeatherMap, מפיקים API Key ומגדירים באמצעותו Credential ב-n8n, בהתאם למצב שלי.
   מצא בעצמך מידע עדכני בתיעוד הרשמי של שני הכלים, וצרף לתשובתך את המקורות שמצאת.
   
   ## אופן ההסבר
   - הסבר במילים פשוטות את סדר הפעולות ואת שמות המסכים והשדות שאפגוש.
   - הסבר מה עושים אם מפתח חדש עדיין אינו פעיל.
   - אני אבצע את הפעולות בעצמי ב-n8n. אני מבקש ממך הסבר בלבד.
   - את המפתח אזין בעצמי בשדה החיבור. אין צורך לשלוח אותו בשיחה.

   
   
   # Context
   I am new to n8n. My workflow has a Manual Trigger and Edit Fields with city = Tel Aviv,IL. I added OpenWeatherMap to retrieve current weather.
   My current situation: [I do not have an OpenWeatherMap account yet / I have an account but no API key / I already have an API key].
   
   ## What I want to understand
   Explain in English how to register for OpenWeatherMap, obtain an API key, and use it to set up a credential in n8n, starting from my current situation.
   Find up-to-date information in both tools' official documentation yourself and include the sources you find in your answer.
   
   ## How to explain
   - Explain the sequence of actions and the screen and field names I will encounter in plain language.
   - Explain what to do if a new key is not active yet.
   - I will carry out the actions in n8n myself. I am asking you for an explanation only.
   - I will enter the key in the connection field myself. There is no need to send it in this chat.

    

   • קראו את ההסבר של Claude ובצעו את הפעולות בעצמכם. אם חלק מההסבר אינו ברור, שאלו עליו שאלה ממוקדת לפני שתמשיכו. ההרשמה נמצאת ב-OpenWeatherMap. אחרי אימות המייל פתחו API Keys. אפשר להשתמש במפתח שכבר קיים, או לתת שם למפתח חדש וללחוץ Generate.
   • חזרו ל-Node ב-n8n. בשדה Credential בחרו Create new credential, הדביקו את המפתח בשדה Access Token ושמרו ב-Save.
   • בדיקה: שם ה-Credential שבחרתם מופיע ב-Node. את תקינות החיבור נבדוק בהרצה הבאה. שמרו את המפתח מחוץ לשיחה ולצילומי המסך.
   • אם מפתח חדש מחזיר שגיאת 401, בדקו שאימתתם את המייל ושהעתקתם את המפתח בשלמותו. לפי התיעוד הרשמי, הפעלתו אורכת עד שעתיים. בכיתה אפשר לבקש מהמנחה Credential מוכן ומאושר. בעבודה עצמאית שמרו את התהליך וחזרו להרצה לאחר הפעלת המפתח.
5. שליפת מזג האוויר ובדיקת הפלט:
   • ב-OpenWeatherMap בחרו Operation: Current Weather, Format: Metric ו-Location Selection: City Name. כך הטמפרטורה תתקבל במעלות צלזיוס.
   • בצד שמאל, ב-INPUT, פתחו את הפלט של Edit Fields וגררו את city אל השדה City במרכז. כך השדה City מקבל את העיר מהשלב הקודם. מתחת לשדה אמור להופיע Tel Aviv,IL. אם אין נתוני קלט, הריצו שוב את Edit Fields.
   • לחצו Execute step. בפלט מימין בחרו Schema, פתחו את main ואתרו את temp. זהו השדה main.temp.
   • בדיקה: מופיע מספר טמפרטורה, וה-Node מסומן בירוק. המספר משתנה עם מזג האוויר. בדקו גם sys.country שערכו IL ואת שם המקום ב-name.
   • אם התקבלה שגיאה, העתיקו ל-Claude רק את הודעת השגיאה ללא מפתח או פרטי חיבור, ציינו באיזה Node אתם נמצאים ובקשו שיסביר מה משמעות השגיאה ואיך אפשר לתקן אותה. אם מופיעה 404, ודאו שבשדה City מופיע Tel Aviv,IL.
6. שליחת הטמפרטורה עם Gmail:
   • לחצו על הפלוס ביציאה מ-OpenWeatherMap, חפשו Gmail ובחרו Send a message. בהגדרות הפעולה מופיעים Resource: Message ו-Operation: Send.
   • בשדה Credential בחרו את חיבור Gmail שלכם מתרגול קודם, אם קיים. לחיבור חדש בחרו Create new credential ואז Sign in with Google. התחברו לחשבון שלכם, אשרו את החיבור ושמרו. בדיקה: שם החיבור מופיע ב-Node. אם Sign in with Google אינו מופיע או שהחיבור נכשל, קראו למנחה.
   • בשדה To הזינו את כתובת המייל שלכם או נמען שהמנחה אישר. ב-Subject כתבו 18x | מזג אוויר באתר הניסוי. בחרו Email Type: Text.
   • ב-INPUT משמאל פתחו main וגררו את temp לשדה Message. בתצוגה שמתחת לשדה Message בדקו שמופיעה הטמפרטורה שקיבלתם.
   • בדיקה לפני שליחה: ודאו שכתובת הנמען נכונה ושהשליחה מאושרת. לחצו Execute step ובדקו שהמייל הגיע עם אותה טמפרטורה. אם אין הודעה, בדקו גם את תיקיית הספאם ואת פלט ה-Node. אל תריצו שוב לפני שבדקתם אם ההודעה כבר נשלחה.
7. סקירת הריצה מקצה לקצה:
   • סגרו את חלון ה-Node. לאחר בדיקת הנמען, לחצו Execute workflow. זו הרצה חדשה ששולחת מייל נוסף.
   • עברו ללשונית Executions בראש המסך ובחרו את הריצה האחרונה. לחצו פעמיים על כל Node כדי לפתוח אותו. משמאל מופיע INPUT, ומימין OUTPUT.
   • בדיקה: ב-OpenWeatherMap רואים עיר בקלט ונתוני מזג אוויר בפלט. ב-Gmail רואים את נתוני מזג האוויר בקלט ותוצאת שליחה בפלט. סטטוס Succeeded ומייל שהגיע עם הטמפרטורה משלימים את הבדיקה.
   • אם הריצה אינה ברשימה, פתחו את ה-Nodes מתוך ה-Editor מיד אחרי ההרצה ובדקו את הנתונים שם. שמרו את התהליך באמצעות Save אם הכפתור מופיע, או המתינו לסיום השמירה האוטומטית.

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

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

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

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

איך שואלים שאלה שעוזרת להתקדם?

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

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

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

# ההקשר
יש לי Workflow עובד ב-n8n:
Manual Trigger, Edit Fields עם city = Tel Aviv,IL, לאחריו OpenWeatherMap Current Weather ולבסוף Gmail ששולח טמפרטורה.
כרגע אני מפעיל את התהליך בלחיצה ידנית. אני רוצה להבין איך אפשר להפעיל אותו בדרכים אחרות.

## השאלה שלי
הסבר לי בעברית על שלושה סוגי Triggers חלופיים. לכל אחד הסבר:
- מתי כדאי להשתמש בו.
- מה מתחיל את הריצה.
- דוגמא פשוטה לשימוש בו.

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

# Context
I have a working n8n workflow:
Manual Trigger, Edit Fields (city = Tel Aviv,IL), OpenWeatherMap Current Weather, and Gmail sending the temperature.
I currently start it with a manual click. I want to understand other ways to start it.

## My question
Explain three alternative trigger types in English. For each, explain:
- When to use it.
- What starts the run.
- A simple example of using it.

## How to explain
Find up-to-date information in n8n's official documentation yourself and include the sources you find.
I am asking for an explanation and comparison so I can understand the options before choosing. I will make any workflow changes myself.

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

משימה שנייה: עיר אחרת או מהירות רוח במקום טמפרטורה

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

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

1. החלפת העיר:
   • פתחו את Edit Fields, שנו את city ל-Haifa,IL ולחצו Execute step. בדיקה: העיר החדשה מופיעה ב-OUTPUT. כעת פתחו את OpenWeatherMap והריצו Execute step. בדקו שחיפה מופיעה בפלט, ורק אז הריצו את Gmail לשליחה לעצמכם.
2. מהירות רוח במקום טמפרטורה:
   • פתחו את Gmail ונקו את תוכן השדה Message. ב-INPUT משמאל פתחו את wind וגררו את speed לשדה הריק, כפי שגררתם קודם את הטמפרטורה. הפעם המייל יציג מהירות רוח במטר לשנייה. בדקו בתצוגה המקדימה שהמספר זהה לערך wind.speed בפלט של OpenWeatherMap. לאחר בדיקת הנמען לחצו Execute step והשוו למספר במייל שהתקבל. התוכן החדש מחליף את הטמפרטורה.

# ההקשר
יש לי Workflow עובד ב-n8n: Manual Trigger, Edit Fields, OpenWeatherMap ו-Gmail.
אני רוצה לעשות שינוי אחד בלבד: [לשנות את העיר ל-Haifa,IL / להציג במייל מהירות רוח במקום טמפרטורה].
אני נמצא כעת ב-Node: [שם ה-Node].
מה שכבר ניסיתי ומה שקרה: [תיאור קצר, או שטרם ניסיתי].

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

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

# Context
I have a working n8n workflow: Manual Trigger, Edit Fields, OpenWeatherMap, and Gmail.
I want to make one change only: [change the city to Haifa,IL / show wind speed in the email instead of temperature].
I am currently in this node: [node name].
What I have tried and what happened: [a brief description, or say I have not tried yet].

## My question
Explain in English how to make my chosen change: where to configure it, which field to change, and what the change means.

## How to explain
Explain the sequence of actions in plain language. If you need more information about my situation, ask me.
If you need more information about the tool, find the relevant official documentation yourself.
I am asking for an explanation only and will make the change in n8n myself.

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

Temperature (C): {{ $json.main.temp }}
Wind speed (m/s): {{ $json.wind.speed }}

שאלות ל-Claude על הפעלה, נתונים ושליחה

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

• איך אראה ב-Execution שהשדה הגיע?
• מה יקרה אם העיר לא מזוהה?
• מה עלול להשתבש אם הטריגר ירוץ בזמן לא נכון?
• מתי כדאי להשאיר אדם שמאשר את השליחה?

תוצר לשיתוף וקריטריוני סיום

בסיום התרגול שמרו:

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

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

בדיקת התהליך המקורי, לפני השינויים:

1. נוצר Workflow עם 4 בלוקים.
2. בוצעה הרצה מוצלחת מקצה לקצה.
3. השדה main.temp הופיע בפלט של OpenWeatherMap.
4. הגיעה הודעת מייל עם הטמפרטורה (לנמען מאושר).
5. אתם יודעים להצביע על העיר בקלט ועל הטמפרטורה בפלט של OpenWeatherMap.
6. ביררתם עם Claude שלושה טריגרים וכתבתם מתי תשתמשו באחד מהם.

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

שאלות להמשך מחקר

אפשר לחזור אליהן אחרי התרגול:

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

הפוסט תרגול 1 | האוטומציה הראשונה ב-n8n הופיע לראשונה ב-Almaya.

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

רוצים הכוונה? עברו לעוזר ה-AI.

אינטואיציה טכנולוגית | כ-10 דקות. מלאו בקצרה את חלק ג בתבנית. אין צורך לבנות מערכת או לבחור מותג.

לפני שמתחילים

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

כבר יש לכם עותק אישי? המשיכו בו. אם אין, בחרו Google Docs או Word ושמרו עותק עם שמכם:

Google Docs: בחרו קובץ ← יצירת עותק (File → Make a copy). Word: שמרו את הקובץ במחשב. אם הפתיחה לא מצליחה, כתבו במסמך ריק את השדות המופיעים בהמשך.

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

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

אלו העובדות הזמינות על המקרים. מידע נוסף נשאר שאלה לבירור.

תזכורת: שבע אבני הבניין

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

1. כמה אנשים צריכים אותו קובץ: אחסון בענן שומר מקור משותף עם הרשאות.
2. עבודה צריכה לרוץ כשהמחשב האישי כבוי: הפעלה בענן מריצה תוכנה על מחשב מרוחק. אחסון לבדו אינו מריץ אותה.
3. תוכנה צריכה מידע ממערכת אחרת: API מאפשר בקשה מסודרת למידע או לפעולה, בכפוף לממשק ולהרשאה.
4. אירוע צריך להפעיל צעדים קבועים: אוטומציה קובעת מתי ומה יקרה.
5. אדם צריך דרך להזין מידע ולקבל תוצאה: ערוץ גישה, כגון טופס או צ'אט.
6. צריך לעבד טקסט: מודל שפה גדול (LLM) מציע טיוטה לבדיקה.
7. צריך לבחור צעדים לפי הממצאים ולהפעיל כלים: סוכן AI פועל לפי מטרה, תוצאות, גבולות והרשאות.

פרק 1: מנסחים צורך ובוחרים אבנים

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

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

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

פרק 2: מזהים שני סיכונים

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

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

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

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

פרק 3: בוחרים בירור ושומרים

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

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

רוצים עזרה מ-AI?

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

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

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

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

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

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

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

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

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

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

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

## Coaching my thinking
Before suggesting an answer to any field, ask for my first attempt and wait. If I do not know how to begin, give a brief hint or guiding question and return to me for an attempt. Help me examine an assumption or a material gap without choosing or drawing conclusions for me. Suggest concise wording only from what I have already said, without adding a new conclusion. If my answer is sufficient, move on without requiring a correction. Names, documents, and sensitive information are unnecessary. A general description of my role and work is enough. If I remain stuck, suggest asking the facilitator.

# Your role
Respond in English. Help me choose technological building blocks for a workplace need and identify two risks. I make and explain the choices. Guide me with one short question at a time. I have about 10 minutes, so keep replies brief.

## Context and worksheet
I am filling in Part C | Technological Intuition in my personal worksheet. You cannot see or update it. Use information already provided and do not request a link or upload. We are not building, installing, or choosing a product brand.

## Start the conversation
Ask only: "Where are you in the exercise: continuing with your case, looking for a case, or seeking help with a specific section?" Wait for my answer.
If I have a case, continue with the action from Part B. Ask for a brief description only if context for my current field is missing. If I am in the middle, continue from my chosen field without repeating earlier answers.
If I have no idea, help me find a real workplace problem: ask about my role, then a recurring difficulty, one question at a time. If needed, suggest two directions based on what I said and ask me to choose a problem that actually exists. Do not choose for me. If I prefer a prepared case or cannot find a personal one, I may choose one of the following cases. Work on only one case:
- Maya wants to turn a long requirements document into questions and assumptions, with a source for each finding.
- Gil wants an assistant to search for information about a fault and prepare a summary with sources.
- Roni wants to report a fault from her phone beside the equipment, and the report must reach the responsible team.
These are all the available facts about the cases. Do not invent systems, permissions, additional people, or data.

## Building blocks
- Cloud storage: shared information with access permissions.
- Cloud computing: software running on a remote computer, including when the personal computer is off.
- API: an agreed way for software to request information or an action, where an interface and permission exist.
- Automation: an event triggers predefined steps.
- Access channel: how a person provides information and receives a result.
- Large language model (LLM): processing and generating language as a draft for checking.
- AI agent: a model choosing steps and using tools according to a goal and results, within boundaries and permissions.
Ask what my need requires before suggesting a concept. One or several blocks may fit. An LLM or agent is not mandatory, and an existing service may provide several capabilities.

## Fields and method
Keep questions and proposed answers in English. Use these exact Hebrew labels to locate fields in the worksheet.
1. "מי צריך מה, ומה צריך להשתנות": help me state who needs what and what should change in one sentence.
2. "האבנים שבחרתי ומה כל אחת עושה לצורך שלי": ask me to select blocks and explain the role and reason for each.
3. "מה כבר זמין בארגון": distinguish what is known to exist from what needs clarification.
4. "סיכון 1: נקודת הכשל, הנזק והמענה": ask for one concrete risk relevant to my choices.
5. "סיכון 2: נקודת הכשל, הנזק והמענה": ask for a second risk, different from the first.
6. "מה אברר קודם ועם מי": ask for the first priority question and a person or role who can help.

After each field, suggest concise wording based only on my answer and explicitly remind me: "Copy your answer into Part C, in the field [exact Hebrew label]." Supply the label yourself. Continue with one question without asking for separate confirmation that I copied.
Do not fill in the whole worksheet upfront or choose for me. If I get stuck, give a brief hint and return the choice to me. Do not invent information. Help me state what needs clarification.

## Checking risks
Consider the five failure points: security, integration, cost, permissions, and knowledge base. A risk from every category is not required.
For each of the two risks, require a possible event, its harm, and an appropriate mitigation. "Security" alone is not a risk. Describe risks as possibilities to check, not events that already happened.
Check that the response addresses the risk: human review does not replace restricted permissions. Confirmation that a form was received does not prove that a task was created. Monitoring detects failure and does not necessarily prevent it. Do not add another long checklist.

## Completion
Check for a need, justified blocks, known resources versus unknowns, two risks with harm and mitigation, and one question with a person or role. Ask only about a material gap. If an answer is sufficient, do not demand a revision. Remind me to save the worksheet and stop.

סיכום קצר

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

שאלות להעמקה ולהתבוננות

אפשר לחזור לשאלות האלה אחרי התרגול:

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

הפוסט בוחרים אבני בניין ומזהים סיכונים הופיע לראשונה ב-Almaya.