לומדים

התשובה הקצרה

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

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

ללולאה שישה חלקים:

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

מתי לבנות לולאה (ומתי לא)

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

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

הרץ בדיקת־מוכנות‑לולאה לפני שמתחיבים: האם זה חוזר? האם התוצאה ניתנת לאימות? האם ל‑Claude יש הקשר? האם יש תנאי עצירה ברור? האם יש נקודת סקירה בטוחה?

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

סולם ההרשאות — רוב הלופים הראשונים צריכים להתחיל ברמה 1 או 2:

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

הלולאה המינימלית הראויה

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

minimal-claude-loop/
├── TASK.md               # the loop's goal
├── PROGRESS.md           # state between runs
├── LOOP_INSTRUCTIONS.md  # how to behave each iteration
└── outputs/
    └── daily-review.md   # where results land

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

מצב מתמשך: PROGRESS.md

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

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

השאר אותו קצר ומובנה: מצב נוכחי, ריצה אחרונה, פריטים פתוחים, חסימות, needs-human-review, מה להרצה הבאה, החלטות שנעשו, do-not-repeat. "אם Claude צריך את זה כדי להחליט את הצעד הבא — שמור אותו ב‑PROGRESS.md. אם אדם עשוי לרצות לבדוק את זה מאוחר יותר — אחסן אותו ב־outputs/."

קובץ המצב הוא גם משטח שליטה ומנגנון בטיחות — הסעיפים Do Not Repeat ו‑Needs Human Review מונעים מהלולאה לנסות שוב פעולות שנכשלו או להמשיך בשקט אחרי שקיבלנו שיקול דעת אנושי.

אימות: הפרד את העובד מהבודק

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

השתמשו בתבנית ה‑maker‑checker: יוצר מייצר, בודק מעריך מול קריטריונים ברורים. אפילו בתוך ריצה אחת של Claude — כתבו אותם כשלבים נפרדים. המערכת שיוצרת את הפלט לא צריכה להיות האות היחיד המאשר אותו.

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

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

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

תזמון עם /loop

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

/loop 24h Run the daily project review loop for this workspace.
Follow LOOP_INSTRUCTIONS.md exactly. Read TASK.md and PROGRESS.md
first. Write the report to outputs/daily-review.md, update PROGRESS.md,
run the verification checklist, and stop if human review is required.
Do not modify any files except outputs/daily-review.md and PROGRESS.md.

בדקו עם מרווח קצר (/loop 15m) תוך צפייה, ואז עברו לקצב האמיתי.

/loop לעומת /goal — הן פותרות בעיות שונות:

• /loop מונעת על‑ידי זמן: הריצה הבאה קורה כי חלף זמן (בדוק פריסה, סקור תיקיה כל בוקר).
• /goal מונעת על‑ידי תנאי: Claude ממשיך לעבוד כי תנאי סיום לא התקיים (המשך עד שהבדיקות עוברות).

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

מסקנה

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

בנו את הלולאה קודם, ועשו אותה אוטונומית שנית. התחילו עם משימה אחת, קובץ מצב אחד, פלט אחד ורשימת אימות אחת; הריצו ידנית; ורק אז תזמנו. הארכיטקטורה — טריגר → הקשר → פעולה → אימות → מצב → סקירה — נשארת זהה בין אם הלולאה מקומית או מחוברת ל‑GitHub, Slack או CI.

---

Primary sources: Claude Code docs on scheduled tasks / /loop and /goal. Compound mechanics (PROGRESS.md, maker-checker, permission ladder) are practitioner-synthesized from the source guide; /loop and /goal behavior verified against official docs on 2026-08-07.