# Plan Mode ב-Claude Code: מדריך שלב אחר שלב וארבעת השלבים ב-2026 > Plan Mode ב-Claude Code: מהו, איך מפעילים אותו עם Shift+Tab, ארבעת השלבים של Anthropic, תבניות הנחיה מוכנות לשימוש ופקודת /goal למשימות אוטונומיות במהלך הלילה. Source: https://ailoot.ai/blog/he/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/he/claude-code-plan-mode/ Language: he Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-de1de31099e79d40c067fa10e12d78e537a4b4cffac2d053f727a3402c648afb הנחיות נוספות מופיעות ב[תיעוד של Ailoot](https://ailoot.ai/docs/). ## מהו Plan Mode, ולמה הוא לא מספיק בפני עצמו?
נקודות מרכזיות Plan Mode ב-Claude Code הוא מצב שבו ה-AI קורא קבצים, מנתח קוד ומציע תוכנית לשינויים, אך אינו כותב דבר עד שתאשרו אותה. מפעילים אותו בלחיצה כפולה על Shift+Tab או באמצעות הדגל `--permission-mode plan`. הוא שימושי כשהגישה אינה ודאית, כשהקוד לא מוכר או כשהשינוי כרוך בסיכון משמעותי בין קבצים או בתפעול. תיקון שגיאת הקלדה ברור ובסיכון נמוך בדרך כלל אינו דורש שלב תכנון נפרד.
במצב רגיל, Claude Code כותב קוד מיד, ואם אינכם עוקבים אחריו, אתם עלולים לקבל משום מקום diff על פני קבצים רבים. Plan Mode הופך את סדר הפעולות: תחילה מחקר ותכנון, אחר כך אישור, ואז שינויים. Anthropic מתארת את Plan Mode בתיעוד הרשמי שלה כך:

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

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
זה נשמע פשוט, אבל מסתתר כאן שינוי מרכזי. Plan Mode משנה את קצב העבודה: קודם מסכימים, אחר כך פועלים. זהו שינוי במצב העבודה, לא כוונון קוסמטי. הקושי של מתכנתים בסגנון vibe coding הוא שסוכני AI נוטים למהר. אם תבקשו, “Add Google authentication,” במצב רגיל Claude יכתוב את הקוד בתוך דקה, אבל חצי מהקבצים יהיו הלא נכונים. ב-Plan Mode, אותה בקשה הופכת לתוכנית טקסט שאפשר לקרוא בתוך שתי דקות ולתקן לפני שנוגעים בקוד. הנה מלכודת שכמעט לא כותבים עליה במדריכים הבינלאומיים. Plan Mode לבדו הוא כלי חלש: התוכנית קיימת רק בשיחה הנוכחית. סגרו את החלון, והתוכנית אובדת. אי אפשר להעביר אותה לסוכן אחר. אין גרסאות או היסטוריה. אם המשימה גדולה (שכתוב של מודול בן 30 קבצים, מעבר למסד נתונים חדש), התוכנית תיתקל במהרה בתקרת חלון ההקשר ותתחיל להתדרדר. לכן Plan Mode עובד היטב לצד תיקיית `plans/` במאגר. התוכנית נשמרת כ-`plans/2026-05-21-google-oauth.md`, מחולקת לשלבים עם תיבות סימון, וכל סוכן שיבוא אחר כך יכול להמשיך ממנה. כך פועל [הנדסת הקשר](https://ailoot.ai/blog/he/context-engineering/)—ניהול ההקשר לפני ההנחיה, ולא במהלכה. ## איך מפעילים את Plan Mode ב-Claude Code?
נקודות מרכזיות יש ארבע דרכים רשמיות להפעיל את Plan Mode. במהלך הפעלה, לחצו פעמיים על Shift+Tab או הוסיפו את התחילית `/plan` לפני הנחיה. בעת ההפעלה, השתמשו בדגל `claude --permission-mode plan`. כדי להגדיר זאת כברירת מחדל, הגדירו את השדה `defaultMode` ב-`.claude/settings.json`. מחוון המצב הפעיל הוא `⏸ plan mode on` בתחתית הטרמינל.
הדרך המהירה ביותר במהלך הפעלה היא באמצעות המקלדת: ``` Shift+Tab # cycles through modes: default → acceptEdits → plan ``` אחרי שתי לחיצות, המחוון `⏸ plan mode on` יופיע בתחתית הטרמינל. לחיצה שלישית מחזירה למצב רגיל. זו השיטה הנוחה ביותר—אפשר להפעיל אותה תוך כדי עבודה כשהמשימה מתחילה לגדול. השיטה השנייה היא להוסיף תחילית לפני הנחיה יחידה: ``` /plan write a plan to migrate the database from MySQL to Postgres ``` האפשרות הזאת שימושית כשאתם במצב אישור אוטומטי ואינכם רוצים לשנות אותו למשך כל ההפעלה. בקשה אחת ב-Plan Mode, ואחר כך העבודה נמשכת כרגיל. השיטה השלישית היא בעת הפעלת הפעלה: ```bash claude --permission-mode plan ``` השתמשו בזה כשידוע לכם מראש שמשימה דורשת תכנון. למשל, לפני שכתוב משמעותי או מעבר. השיטה הרביעית היא להגדיר את ברירת המחדל ב-`.claude/settings.json` בפרויקט: ```json { "permissions": { "defaultMode": "plan" } } ``` מתי זה שימושי? כשצוות עובד על מערכת מורכבת שכל שינוי בה עלול להשפיע על מודולים סמוכים. במצב כזה, ברירת המחדל של Plan Mode מגינה על כולם מפני שינויים מקריים. טריק חמישי שלעתים קרובות מתעלמים ממנו: `Ctrl+G` פותח את התוכנית בעורך טקסט. השתמשו בו כשהתוכנית כמעט נכונה, אבל צריך לנסח מחדש 2-3 נקודות או להוסיף אילוץ. ערכו אותה ידנית, שמרו, ו-Claude ימשיך עם הגרסה שלכם. ## מהם ארבעת השלבים הקנוניים של Anthropic ב-Plan Mode: Explore, Plan, Implement, Commit?
נקודות מרכזיות בשיטות העבודה המומלצות שלה, Anthropic מציינת תהליך עבודה קנוני בן ארבעה שלבים: Explore (קריאת קבצים וחקירת ההקשר), Plan (יצירת תוכנית לשינויים בלי לערוך), Implement (מעבר למצב רגיל ומימוש התוכנית), Commit (יצירת commit עם הודעה תיאורית ו-PR). לכל שלב יש מגבלות משלו על השימוש בכלים.
מדריכים רבים מתארים שלושה שלבים (Explore-Plan-Execute) או רק שניים (Plan-Implement). אלה פישוטים. ב[מדריך הרשמי לשיטות העבודה המומלצות](https://www.anthropic.com/engineering/claude-code-best-practices), Anthropic מתארת בדיוק ארבעה שלבים. ההבדל חשוב: שלב Commit נפרד גורם לכם לתעד את התוצאה במקום להסתפק ב“עשיתי עוד כמה תיקונים, אעשה commit אחר כך”—המקור הנפוץ ביותר לאובדן עבודה. ככל שהתוכנית מדויקת יותר, כך המימוש דורש פחות איטרציות. אם תקדישו 10 דקות לתוכנית, המימוש ידרוש הנחיה אחת. אם תשרטטו את התוכנית בתוך דקה, המימוש ידרוש שעה של תיקונים. כך נראים ארבעת השלבים בהוספת Google OAuth (דוגמה מתוך Anthropic Docs): | שלב | מה Claude עושה | מה אתם עושים | מצב | |----|----|----|----| | **Explore** | קורא את `/src/auth`, ובודק כיצד מטפלים בהפעלות ובמשתני סביבה | מגדירים את היקף החקירה | Plan Mode | | **Plan** | יוצר תוכנית: אילו קבצים לשנות, אילו חדשים ליצור ומהם הסיכונים | קוראים את התוכנית, עורכים אותה באמצעות Ctrl+G ומאשרים | Plan Mode | | **Implement** | מממש לפי התוכנית, כותב קוד לזרימת OAuth, בדיקות ו-callback | עוקבים אחר כל שינוי בזמן החלתו | Default או acceptEdits | | **Commit** | יוצר commit עם תיאור ופותח Pull Request | בודקים את ההודעה וסוקרים את ה-PR | Default | גם ההנחיות שונות בכל שלב. ב-Explore: “read /src/auth and understand how we handle sessions and login”. ב-Plan: “I want to add Google OAuth. What files need to change? Create a plan”. ב-Implement: “implement the OAuth flow from your plan, write tests, run the suite and fix failures”. ב-Commit: “commit with a descriptive message and open a PR”. הסתייגות חשובה: Plan Mode אינו מונע מ-Claude להריץ פקודות לצורכי מחקר. Read, LS, Glob, Grep, web fetch ופקודות shell לחקירה מותרים. רק Edit, Write וכל פעולת מערכת קבצים שמשנה נתונים אסורים. פירוש הדבר הוא ש-Claude יכול לקרוא את מבנה הפרויקט, להריץ `git log` ולעיין בבדיקות—אבל לא יוכל לשנות דבר בטעות. ## איך קוראים את התוכנית של Claude ומחליטים אם לאשר אותה?
נקודות מרכזיות תוכנית טובה של Claude כוללת רשימה של קבצים ספציפיים והשינויים שיש לבצע, רצף צעדים מסודר, סיכונים מפורשים וקריטריונים להצלחה. תוכנית גרועה משתמשת בניסוחים כלליים כמו “אעדכן את מודול האימות” בלי פירוט. היעזרו בשבעת הסימנים שלהלן כדי להחליט אם לאשר אותה. אפשר לשפר אותה באמצעות משוב או לערוך אותה ישירות ב-Ctrl+G.
לאחר ש-Claude מסיים ליצור תוכנית, הוא מציג אפשרויות להמשך: - לאשר ולהתחיל במצב אוטומטי - לאשר ולקבל עריכות - לאשר ולבדוק כל עריכה ידנית - להמשיך לתכנן עם משוב - לשפר בעזרת Ultraplan (סקירה בדפדפן) היכולת לדעת אם לאשר תוכנית היא המיומנות המרכזית ב-Plan Mode. קל ללחוץ על “Approve” באופן אוטומטי ואז להיאלץ לבטל commits. חנפן ה-AI רוצה לספק תשובה מהירה, ואתם רוצים להגיע לקוד מהר יותר. שניכם טועים. תוכנית טובה עומדת בשבעה קריטריונים: 1. **שמות קבצים ספציפיים.** לא “אעדכן את auth”, אלא “אשנה את `src/auth/login.ts:42-58`, אצור את `src/auth/oauth-callback.ts` ואעדכן את `src/auth/session.ts:103`.” 2. **הרצף מוגדר.** התוכנית מחולקת לשלבים או לצעדים, ולא אומרת “אעשה את כל זה איכשהו”. 3. **תלויות חיצוניות מצוינות בשמן.** אם נדרשת ספרייה חדשה, היא מופיעה ברשימה. אם נדרשים משתני סביבה, גם הם מופיעים. 4. **הסיכונים מפורטים.** תוכנית טובה אומרת: “ההעברה עלולה לשבור הפעלות קיימות; צריך לבדוק את X.” תוכנית גרועה אינה מתייחסת לתופעות לוואי. 5. **יש קריטריונים להצלחה.** “בדיקות `test/auth` עוברות, ה-linter נקי ושרת הפיתוח עולה בלי שגיאות.” 6. **אין הנחות שנשלפו מהאוויר.** אם Claude אומר “אשתמש בספרייה Z”, בדקו: האם בכלל התקנתם אותה בפרויקט? אם ה-AI המציא אותה, תראו שהיא אינה מוזכרת ב-`package.json`. 7. **התוכנית נכנסת למסך.** אם תוכנית של תכונה פשוטה תופסת 200 שורות, כנראה שהמשימה גדולה מדי לתוכנית אחת. חלקו אותה. אם התוכנית לא עומדת בבדיקה, יש שלוש אפשרויות: - **להמשיך לתכנן עם משוב**—תנו ל-Claude הערה ספציפית על מה שלא מוצא חן בעיניכם, והוא ישכתב את התוכנית. - **Ctrl+G**—פתחו את התוכנית בעורך, ערכו אותה ידנית ושמרו. Claude ימשיך עם הגרסה שלכם. - **לשפר בעזרת Ultraplan**—התוכנית עוברת למצב הדפדפן של Claude Code באינטרנט, שבו אתם סוקרים חלקים ומעירים, ואז מריצים אותה מקומית או בענן. אם משהו משתבש באמצע המימוש, אל תכפו את המשך העבודה. חזרו ל-Plan Mode ושכתבו את התוכנית. זה זול פי 10 מביטול 40 commits מאוחר יותר. ## Plan Mode + תיקיית `plans/`: שילוב לעבודה עם הקשר ארוך
נקודות מרכזיות Plan Mode לבדו עובד רק בשיחה הנוכחית. סגרו את החלון, והתוכנית נעלמת. תיקיית `plans/YYYY-MM-DD-feature.md` במאגר הופכת את התוכנית לפריט עמיד: קובץ עם שלבים, תיבות סימון וסטטוסים שכל סוכן שיבוא אחר כך יכול להמשיך ממנו. זהו מעבר מ“תוכנית בזיכרון” ל“תוכנית בקוד”.
Plan Mode הוא מצב של Claude Code. תיקיית `plans/` היא מתודולוגיה שנבנתה מעליו. אם תשתמשו ב-Plan Mode בלי תיקייה, תיתקלו בתקרה אחרי שעה של עבודה. ההיגיון הוא כזה. חלון ההקשר של Claude הוא הזיכרון של ההפעלה. אפשר להכניס אליו מיליון אסימונים ב-Opus 4.7, אבל זו הכמות של כל השיחה שלכם. אם תתכננו משימה מורכבת בשיחה אחת, תבקשו אחר כך לממש אותה, תדונו בבאג ואז תעסקו במשהו נוסף, החלון “יתנפח”. Claude יתחיל לשכוח החלטות מוקדמות, לבלבל בין הקשרים ולשאול שוב שאלות שכבר נשאלו. הפתרון הוא כלל הזהב: **משימה אחת—שיחה אחת**. כך עושים זאת: 1. **שיחה 1—גיבוש התוכנית.** הפעילו Plan Mode, תארו את המשימה, ו-Claude ייצור תוכנית. שמרו אותה ב-`plans/2026-05-21-feature-name.md`. סגרו את החלון. 2. **שיחה 2—חלוקה לשלבים.** פתחו שיחה חדשה. בקשו: “take `plans/2026-05-21-feature-name.md` and divide it into phases.” שמרו את הקובץ המעודכן. 3. **שיחה 3—מימוש שלב 1.** פתחו שיחה חדשה. בקשו: “implement Phase 1 from `plans/2026-05-21-feature-name.md`, and check off items as you complete them.” סגרו את החלון. 4. **שיחה 4—מימוש שלב 2.** עשו אותו דבר. מה זה נותן לכם? חלון ההקשר של כל שיחה נשאר רענן. Claude בשלב 3 אינו יודע את הפרטים של שלב 1, אבל הוא מכיר את התוכנית כי קובץ `plans/` נמצא במאגר. כל סוכן שיבוא אחר כך (בין שהוא subagent, הפעלה חדשה או הרצה באמצעות `/goal`) יכול להמשיך מהתוכנית. השוואת הגישות: | תכונה | Plan Mode בלבד | Plan Mode + תיקיית `plans/` | |----|----|----| | עמידות | רק בצ'אט הנוכחי | במאגר לעד | | העברה לסוכן אחר | בלתי אפשרית | `cat plans/file.md` | | גרסאות והיסטוריה | אין | דרך git diff | | תמיכה ב-subagent | רק בהפעלה הנוכחית | לכל שלב → subagent משלו | | תיבות סימון וסטטוסים | טקסט בלבד | תיבת סימון Markdown `[ ]` / `[x]` | | גודל התוכנית | מוגבל על ידי החלון | כל גודל | לכל תכונה יש קובץ תוכנית משלה. כשצריך לזכור כעבור שלושה חודשים למה בחרתם בספק תשלומים אחד על פני חלופה, אפשר לפתוח את התוכנית הרלוונטית ולקרוא את היסטוריית ההחלטה: מה נדון, אילו אפשרויות נשקלו ולמה נבחר דווקא הנתיב הזה. אלה תוכניות עבודה חיות; תיעוד סטטי מתיישן בתוך חודשים ספורים. ## איך גורמים ל-Claude לעבוד בזמן שאתם ישנים בעזרת Plan Mode ו-/goal?
נקודות מרכזיות `/goal` היא הלולאה האוטונומית ש-Anthropic מדברת עליה כבר שנה. הפקודה `/goal` הופיעה ב-Claude Code v2.1.139 (11 במאי 2026). היא מגדירה תנאי להשלמה, ו-Claude עובד עליו ללא מעורבות אנושית עד שהתנאי מתקיים. מודל מעריך קטן בודק אחרי כל תור אם התנאי התקיים.
המגבלה העיקרית של הפעלות AI ארוכות אינה המודל עצמו, אלא האדם שלוחץ Enter. בכל פעם ש-Claude מגיע לסוף תור, הוא ממתין לתגובה שלכם. `/goal` מסיר את ההמתנה הזאת. התחביר פשוט: ```bash /goal all tests in test/auth pass and lint is clean, or stop after 20 turns ``` התנאי יכול להכיל עד 4000 תווים. יעד אחד לכל הפעלה. אחרי כל תור, מודל ה-Haiku הקטן מעיין בתמליל ומחליט: “התנאי התקיים—לסיים” או “לא התקיים—להמשיך לתור הבא”. המעריך אינו מפעיל כלים; הוא רק קורא. כינויים לאיפוס: `/goal stop`, `/goal off`, `/goal reset`, `/goal none`, `/goal cancel`. כך נראה השילוב עם Plan Mode: 1. הפעילו את Plan Mode (לחצו פעמיים על `Shift+Tab`). 2. בקשו: “create a plan to migrate the database from MySQL to Postgres, save it to `plans/2026-05-21-postgres-migration.md` with phases and criteria.” 3. בדקו את התוכנית, ערכו אותה ואשרו אותה. 4. צאו מ-Plan Mode (לחצו פעם נוספת על `Shift+Tab`). 5. הגדירו יעד: “complete all phases in `plans/2026-05-21-postgres-migration.md`, check off the boxes, all tests pass, or stop after 50 turns.” 6. סגרו את המחשב הנייד ולכו לישון. בבוקר, בדקו את התוצאה: או “✓ goal completed” או “◎ stopped after 50 turns”, יחד עם היסטוריה של מה שנעשה. יש שלושה כללים חיוניים לשימוש ב-`/goal`, אחרת תבזבזו אסימונים: **כלל 1: מצב סופי שאפשר למדוד.** “Make it look nice” היא הנחיה גרועה. “`npm test` מחזיר 0, `npm run lint` מחזיר 0, ונוספה רשומה ל-`CHANGELOG.md`” היא הנחיה טובה. **כלל 2: אימות מפורש.** התנאי צריך להתייחס למשהו שאפשר לאמת: פקודה, קובץ או endpoint. לא “הכול עובד”, אלא “curl localhost:3000/api/users returns 200.” **כלל 3: הגבלת מספר התורות.** הוסיפו תמיד `or stop after N turns`. Anthropic ממליצה על כך במפורש בתיעוד:

כדי להגביל את משך הריצה של יעד, הוסיפו לתנאי סעיף המגביל תורות או זמן, למשל 'or stop after 20 turns'.

— Anthropic Docs, https://code.claude.com/docs/en/goal
אם תפעילו `/goal` בלי `or stop after`, התקציב שלכם עלול להיעלם במהלך הלילה. ## איזה מחזור בן ארבעה שלבים הופך את Plan Mode לתהליך הנדסי?
נקודות מרכזיות Plan Mode פשוט, ללא מבנה, מניב תוצאות ממוצעות. תהליך עבודה חזק עוקב אחר ארבעה צעדים בחלון אחד: קביעת העובדות בלי להציע פתרון, פיתוח אפשרויות בעזרת תקדימים מהאינטרנט, יצירת תוכנית מפורטת עם סיכונים 2-3 צעדים קדימה, ודרישה לבדיקה עצמית של התוכנית לאיתור הנחות שנשלפו מהאוויר. הרצף הזה חוסם את חנפן ה-AI.
טעות נפוצה היא לשאול “איך לתקן את זה?”: Claude מספק פתרון, אתם מיישמים אותו, אבל שום דבר לא עובד או שהמצב מחמיר. זהו “חנפן ה-AI”: הוא אומן לענות במהירות, ואתם רוצים להגיע לקוד מהר יותר. מחזור בן ארבעה שלבים פותר זאת. מחזור ארבעת השלבים חוסם את הדפוס הזה. משתמשים בו ברצף במהלך הפעלת Plan Mode אחת: **שלב 1. קביעת העובדות בלי פתרון.** הנחיה: “אני חווה את הדבר הבא: \[תיאור התסמין\]. המשימה שלכם כעת היא לקבוע את העובדות. כל פתרון, רעיון או עצה אסורים. רק: מה אני רואה, אילו צעדים ניתנים לשחזור, אילו נתונים זמינים ואילו נתונים חסרים. תנאי עצירה מוחלט: אל תציעו פתרונות; תעדו רק את האבחון.” כך חוסמים את הדחף הראשון של ה-AI: “הנה הפתרון.” Claude חייב לעצור ב“מה ידוע ומה לא ידוע”. **שלב 2. פיתוח אפשרויות בעזרת תקדימים.** הנחיה: “עכשיו כשהאבחון נקבע, מצאו באינטרנט תקדימים לפתרון בעיות דומות. לפחות שלוש גישות שונות. לכל אחת: קישור למקור ראשוני, תיאור קצר ויתרונות וחסרונות עבור המצב שלנו.” כך חוסמים את הדחף השני של ה-AI: “להמציא פתרון על המקום.” אנחנו גורמים לו לצאת אל העולם ולחזור עם גישות שאפשר לבדוק. **שלב 3. תוכנית מפורטת עם סיכונים.** הנחיה: “קחו את האפשרות הטובה ביותר משלב 2 והציגו תוכנית מפורטת: באילו קבצים ספציפיים לגעת, מה להוסיף, מה להסיר, אילו בדיקות לכתוב, מה עלול להישבר ואילו סיכונים צפויים 2-3 צעדים קדימה.” זהו שלב התכנון המוכר, אך יש הבדל אחד: הוא מבוסס על האפשרויות המאומתות משלב 2, ולא על הניחושים של Claude. **שלב 4. בדיקה עצמית של התוכנית.** הנחיה: “עכשיו בצעו בדיקה עצמית מחייבת. בדקו שוב בכנות את התוכנית: האם יש בה דברים שהוצאתם מהאוויר ולא אימתתם מול הקוד, התיעוד או תקדים משלב 2? אם כן, סמנו אותם ותקנו את התוכנית.” זהו מסנן סופי. Claude חייב לבדוק את ההיגיון שלו עצמו ולהודות היכן הזיה. בדרך כלל משנים לפחות שני פריטי תוכנית בשלב הזה. אחרי ארבעת השלבים, התוכנית מוכנה לאישור. אפשר לעבור למימוש בביטחון שהמשימה הובנה, האפשרויות נשקלו והסיכונים נבדקו. המתודולוגיה הזאת מיועדת לאבחון באגים קשים ולקבלת החלטות ארכיטקטוניות—מקרים שבהם עלות הטעות גבוהה. ביישום שלה ל-Plan Mode, היא מסירה את הקושי העיקרי של מתכנתים בסגנון vibe coding: “ה-AI נתן לי פתרון, יישמתי אותו והכול נשבר.” ## אילו חמש הנחיות מוכנות לשימוש עובדות ב-Plan Mode למשימות נפוצות?
נקודות מרכזיות הנחיות מוכנות לשימוש חוסכות 10-15 דקות לכל משימה ומשפרות את איכות התוכנית. יש חמש תבניות אוניברסליות לשכתוב מודול, להעברת מסד נתונים, להוספת תכונה חדשה, לכתיבת בדיקות ולניפוי שגיאה מורכבת. כל אחת בנויה סביב מחזור ארבעת השלבים ומקושרת לתיקיית `plans/`.
**תבנית 1. שכתוב מודול.** ``` אני מפעיל/ה Plan Mode. המשימה: לשכתב את מודול {module-name}. שלב 1: בדקו את המבנה הנוכחי של המודול {module-path}. תארו: - אילו קבצים שייכים למודול - אילו תלויות חיצוניות יש לו - אילו חלקים משוכפלים - אילו פונקציות מורכבות מדי שלב 2: מצאו 2-3 דוגמאות באינטרנט לשכתוב מודולים דומים. לפחות מקור אחד חייב להיות תיעוד רשמי של Anthropic או של מסגרת העבודה הרלוונטית. שלב 3: צרו תוכנית שכתוב ב-plans/YYYY-MM-DD-refactor-{module}.md: - אילו קבצים לשנות את שמם - אילו פונקציות לחלץ למודולים נפרדים - אילו בדיקות להשאיר ואילו לשכתב - סיכונים: מה עלול להשתבש עבור המשתמשים שלב 4: בדיקה עצמית. האם יש בתוכנית הנחות שנשלפו מהאוויר? כתבו אותן מחדש או הסירו אותן. ``` **תבנית 2. העברת מסד נתונים.** ``` אני מפעיל/ה Plan Mode. המשימה: להעביר את מסד הנתונים מ-{old} ל-{new}. שלב 1: בדקו את סכמת מסד הנתונים הנוכחית באמצעות {schema-reading-command}. תארו: - אילו טבלאות קיימות ומה גודלן - אילו קשרים, אינדקסים ואילוצים קיימים - היכן נשמרות העברות - אילו נתונים קריטיים שלב 2: מצאו תקדימים להעברות {old → new} בפרויקטים בסביבת ייצור. לפחות 3 גישות שונות: pg_dump, dual-write, blue-green. לכל אחת, פרטו את היתרונות והסיכונים עבור היקף הנתונים שלנו. שלב 3: צרו תוכנית העברה ב-plans/YYYY-MM-DD-db-migration.md: - שלבים (גיבוי, העברה, אימות, מעבר) - קריטריוני הצלחה לכל שלב - תוכנית חזרה לאחור אם משהו משתבש - השבתה או ללא השבתה שלב 4: בדיקה עצמית. האם כל הנתונים מגובים בתיעוד? האם בדקתם כל שלב מחשבתית מול סביבת הפיתוח? ``` **תבנית 3. הוספת תכונה חדשה.** ``` אני מפעיל/ה Plan Mode. המשימה: להוסיף לפרויקט את התכונה {description}. שלב 1: בדקו כיצד תכונות דומות פועלות כעת בפרויקט. בדקו במיוחד את: - {file-1} - {file-2} - דפוסי הארכיטקטורה שבהם משתמשים - אילו בדיקות נכתבות לתכונות דומות שלב 2: מצאו כיצד מממשים את התכונה הזאת בפרויקטים בקוד פתוח עם ארכיטקטורה דומה. לפחות 2 גישות שונות. שלב 3: צרו תוכנית ב-plans/YYYY-MM-DD-feature-{name}.md: - רשימת קבצים חדשים - רשימת קבצים לשינוי עם שורות ספציפיות - רצף המימוש - אילו בדיקות להוסיף - מה להוסיף ל-CLAUDE.md ככלל להפעלות עתידיות שלב 4: בדיקה עצמית. האם התוכנית תואמת לארכיטקטורה של הפרויקט? האם היא מניחה שקיימות ספריות שעדיין לא הותקנו? ``` **תבנית 4. כתיבת בדיקות.** ``` אני מפעיל/ה Plan Mode. המשימה: לכסות את המודול {name} בבדיקות. שלב 1: בדקו את המודול {path}. זהו: - פונקציות ציבוריות והחתימות שלהן - פונקציות פנימיות שלא נבדוק (פרטי מימוש) - מקרי קצה: קלט ריק, שגיאות, גישה מקבילית שלב 2: מצאו דוגמאות לבדיקות עבור סוג דומה של משימות בפרויקטים פופולריים בקוד פתוח שמשתמשים באותה מסגרת עבודה. שלב 3: צרו תוכנית בדיקות ב-plans/YYYY-MM-DD-tests-{module}.md: - לכל פונקציה ציבורית, רשימת בדיקות - אילו mocks נחוצים - אילו fixtures - איזו גישת אימות (סגנון assertion) שלב 4: בדיקה עצמית. האם כל הבדיקות בודקות התנהגות ולא מימוש? האם מקרי הקצה מכוסים? ``` **תבנית 5. ניפוי שגיאה מורכבת.** ``` אני מפעיל/ה Plan Mode. המשימה: להבין את סיבת השגיאה {symptom-description}. שלב 1: קביעת העובדות. פתרונות ורעיונות אסורים. רק: - מה אני רואה (הניסוח המדויק של השגיאה) - צעדים שניתנים לשחזור - אילו נתונים זמינים (לוגים, traces, גרסאות ספריות) - אילו נתונים חסרים (מה צריך לאסוף בנוסף) שלב 2: מצאו תקדימים לשגיאה הזאת. לפחות 3 מקורות: GitHub issues, תיעוד. לכל אחד, ספקו קישור וסיכום קצר של הפתרון. שלב 3: צרו תוכנית אבחון ב-plans/YYYY-MM-DD-bug-{name}.md: - אילו השערות לבדוק (בסדר הסתברות) - אילו פקודות/scripts להריץ כדי לבדוק כל אחת - התוצאה הצפויה מכל בדיקה שלב 4: בדיקה עצמית. האם יש בתוכנית השערות שנשלפו מהאוויר? האם כל ההשערות קשורות לעובדות משלב 1? ``` העתיקו כל תבנית, החליפו את `{parameters}` בערכים שלכם והדביקו אותה ב-Claude Code במצב Plan Mode. התוצאה תהיה תוכנית עבודה ב-`plans/` שתוכלו לאשר ולהשתמש בה למימוש. ## Plan Mode מול מצב רגיל: במה כדאי לבחור?
נקודות מרכזיות השתמשו ב-Plan Mode כשהגישה אינה ודאית, כשהקוד לא מוכר, בהחלטות ארכיטקטורה, בהגירות או בשינויים עם תופעות לוואי משמעותיות. מספר הקבצים הוא תזכורת לבדוק תלויות, ולא כלל קשיח. אפשר לטפל ישירות ב-diff קטן, מובן ובסיכון נמוך; תיאור במשפט אחד לבדו אינו הופך שינוי אימות או הגירה לבטוח.
Anthropic אומרת זאת ישירות בתיעוד שלה:

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

— Anthropic Docs, https://www.anthropic.com/engineering/claude-code-best-practices
דלגו על תוכנית נפרדת רק כשה-diff בפועל קטן, מובן ובסיכון נמוך. השתמשו בתכנון כשצריך לברר את הגישה או לתאם שינויים מסוכנים בין רכיבים. ידיעת שמות הקבצים או היכולת לסכם מטרה במשפט אחד אינן מבטלות סיכוני הגירה, אימות או שלמות נתונים. טבלת החלטה: | משימה | מצב | למה | |----|----|----| | טעות הקלדה ב-README | Default | קובץ אחד, שינוי אחד, diff ברור | | שינוי שם משתנה בקובץ אחד | Default | ההיקף ברור ואפשר לבדוק הפניות; העריכו תופעות לוואי | | הוספת שורת רישום ביומן | Default | שינוי של שורה אחת שאינו משפיע על הלוגיקה | | הוספת כפתור חדש לדף | Default | אם מדובר בכפתור אחד וידוע לכם היכן למקם אותו, אין צורך בתוכנית | | שכתוב מודול | Plan Mode | 5+ קבצים, סיכון לתופעות לוואי | | העברת מסד נתונים | Plan Mode + `/goal` | תהליך רב-שלבי; דרושה תוכנית חזרה לאחור | | הוספת אימות | Plan Mode | משפיעה על 10+ קבצים; האבטחה קריטית | | כתיבת בדיקות למודול | Plan Mode | צריך לקבוע מה לבדוק | | ניפוי באג לא ברור | Plan Mode + מחזור בן ארבעה שלבים | בלי אבחון, הפתרונות יחטיאו את המטרה | | העברה מלאה של מסגרת עבודה | Plan Mode + `plans/` + `/goal` במהלך הלילה | משימה ארוכה שדורשת שלבים ולולאה אוטונומית | לפני בחירת מצב, שאלו אם הגישה, תופעות הלוואי והאימות מובנים. עבדו ישירות על שינוי קטן, מקומי ובסיכון נמוך עם בדיקה ברורה. תכננו קודם כשיש אי-ודאות, קוד לא מוכר, הגירה, אימות או תיאום בין רכיבים — גם אם אתם כבר יודעים את שמות כל 3-5 הקבצים שיושפעו. ## איך משלבים Plan Mode + CLAUDE.md + subagents לעבודה אמינה?
נקודות מרכזיות Plan Mode מתחזק פי 10 כשמשלבים אותו עם [CLAUDE.md](https://ailoot.ai/blog/he/claude-md-template/) שמוגדר כראוי ועם [subagents](https://ailoot.ai/blog/he/claude-code-subagents/). CLAUDE.md מגדיר את הכללים שבהם Claude משתמש כדי לבנות תוכנית. subagents מאפשרים לחלק את שלבי התוכנית בין סוכנים מקבילים. בלי השילוב הזה, Plan Mode נשאר כלי לשימוש חד-פעמי.
CLAUDE.md הוא קובץ ש-Claude קורא בתחילת כל הפעלה, כולל Plan Mode. אם CLAUDE.md אומר “לעולם אל תקבעו תאריכים בקוד; שלפו אותם תמיד ממסד הנתונים,” התוכנית לעולם לא תציע לקבוע תאריך בקוד. אם אין כלל כזה, התוכנית יכולה להציע כל דבר. השילוב פועל כך: **שכבה 1. CLAUDE.md מגדיר את הכללים.** הקובץ מפרט את מחסנית הטכנולוגיות של הפרויקט, עקרונות ארכיטקטוניים, איסורים (“אל תשתמשו בממשקי API שהוצאו משימוש”) ודרישות (“כל הודעות הדוא״ל עוברות דרך תבנית משותפת”). מדריך מפורט: [איך להגדיר את CLAUDE.md](https://ailoot.ai/blog/he/claude-md-template/). **שכבה 2. Plan Mode מחיל את הכללים על המשימה.** כשאתם מפעילים את Plan Mode ומבקשים “add OAuth”, Claude קורא את CLAUDE.md, רואה את הכללים (“שמרו אסימונים ב-Redis, לא במסד הנתונים”) ומביא אותם בחשבון מיד בתוכנית. התוכנית תואמת לארכיטקטורת הפרויקט. **שכבה 3. subagents מחלקים את העבודה.** אם התוכנית מחולקת לשלבים, אפשר להקצות כל שלב ל-[subagent](https://ailoot.ai/blog/he/claude-code-subagents/) נפרד. כל subagent עובד בחלון הקשר משלו בלי להעמיס על החלון הראשי. התוכנית ב-`plans/` נשארת מקור האמת המרכזי: subagents קוראים אותה, מבצעים את השלב שלהם ומעדכנים את תיבות הסימון. ## אילו שבע טעויות משבשות את Plan Mode?
נקודות מרכזיות Plan Mode משתבש לעיתים קרובות בגלל טעויות שימוש נפוצות, ולא מפני שהכלי חלש. שבע הטעויות העיקריות הן: שמירת התוכנית בזיכרון במקום בקובץ, הכנסת כל המשימות לצ'אט אחד, יצירת תוכנית בלי שלבים, דילוג על מחקר מעמיק, מתן אפשרות לחנפן ה-AI להציע פתרון בלי אבחון, דילוג על הבדיקה העצמית ושימוש בתנאים מעורפלים ב-`/goal`.
**טעות 1. התוכנית קיימת רק בצ'אט.** תסמין: כתבתם תוכנית, סגרתם את החלון ורוצים לחזור למחרת—אבל שום דבר לא שם; ההקשר נעלם. פתרון: שמרו תמיד את התוכנית ב-`plans/YYYY-MM-DD-feature-name.md` במאגר. הצ'אט הוא שולחן העבודה; הקובץ הוא הארכיון. **טעות 2. כל המשימות בצ'אט אחד.** תסמין: בהפעלה אחת אתם דנים באימות, אחר כך בהעברה, אחר כך בעיצוב ממשק משתמש ואז בבאג. חלון ההקשר “מתנפח”, ו-Claude שוכח דברים קודמים. פתרון: משימה אחת—שיחה אחת. סיימתם את התוכנית? סגרו את החלון. מתחילים במימוש? פתחו חדש. **טעות 3. תוכנית אחת בת 3000 שורות בלי שלבים.** תסמין: יש תוכנית, אבל אין בה תיבות סימון או חלוקה. אי אפשר לדעת מה הושלם ומה לא. אי אפשר להאציל. פתרון: חלקו כל תוכנית ל-3-7 שלבים. כל שלב יכלול רשימה של תיבות סימון עם פעולות ספציפיות. **טעות 4. אין מחקר מעמיק לפני התוכנית.** תסמין: Claude מציע פתרון על המקום כי לא ביקשתם ממנו לחפש תקדימים. כעבור שבוע אתם מגלים שבקוד פתוח קיימת כבר מזמן גישה טובה יותר. פתרון: שלב 2 במחזור בן ארבעת השלבים—בקשו מ-Claude למצוא 2-3 תקדימים באינטרנט לפני יצירת התוכנית. **טעות 5. חנפן ה-AI מציע פתרון בלי אבחון.** תסמין: אתם שואלים “how do I fix error X?”, Claude מציע פתרון, אתם מיישמים אותו ושום דבר לא עובד או שהמצב מחמיר. פתרון: התחילו תמיד ב“קבעו את העובדות; פתרונות אסורים”. עברו לאפשרויות רק אחרי האבחון. **טעות 6. דילוג על הבדיקה העצמית.** תסמין: התוכנית נראית הגיונית, אבל כוללת 2-3 הנחות שנשלפו מהאוויר (ספרייה מומצאת, API לא קיים או גרסה שגויה). המימוש נכשל בגללן. פתרון: שלב 4 במחזור בן ארבעת השלבים—בקשו מ-Claude לבדוק את תוכניתו בכנות ולסמן הנחות. **טעות 7. תנאים מעורפלים ב-`/goal`.** תסמין: הגדרתם `/goal make it look nice`, השארתם אותה לפעול בלילה, ובבוקר גיליתם שנוצלו $200 מהמכסה. פתרון: השתמשו רק בתנאים מדידים, עם פקודת אימות ותנאי חובה `or stop after N turns`. בלי “make it good” או “polish it up.” הטעות השמינית, שמתכנתים בסגנון vibe coding עושים לרוב, היא התעלמות מעצם הרעיון של תיקיית `plans/`. Plan Mode בלי תיקיית `plans/` אינו מתודולוגיה; הוא צעצוע. אם משתמשים ב-Plan Mode אבל לא יוצרים קבצים, מקבלים 10% מהיכולות שלו. ## מה כדאי לעשות אחרי ההתנסות הראשונה שלכם ב-Plan Mode?
נקודות מרכזיות ההתנסות הראשונה שלכם ב-Plan Mode היא נקודת התחלה. הצעדים הבאים: הגדירו את [CLAUDE.md](https://ailoot.ai/blog/he/claude-md-template/) אם עדיין אין לכם אותו (בלעדיו התוכנית תלויה באוויר), צרו תיקיית `plans/` במאגר כמתודולוגיית עבודה, ונסו את `/goal` במשימה אוטונומית אחת לפני השינה. השילוב של שלושתם—Plan Mode, CLAUDE.md ו-`plans/`—הוא מערכת עובדת.
שלושה צעדים מעשיים, לפי סדר קושי עולה: **שלב 1. הגדירו את CLAUDE.md, אם עדיין אין לכם.** בלי CLAUDE.md, Plan Mode פועל “בריק”—Claude אינו מכיר את כללי הפרויקט ומציע תוכניות ששוברות את הארכיטקטורה. המדריך המלא: [איך להגדיר את CLAUDE.md](https://ailoot.ai/blog/he/claude-md-template/). CLAUDE.md מינימלי כולל 50-80 שורות המתארות את מחסנית הטכנולוגיות, הכללים והאיסורים. האורך משני. הספציפיות היא שקובעת. **שלב 2. צרו תיקיית `plans/` במאגר.** הוסיפו תיקיית `plans/` לשורש הפרויקט. הסכימו על פורמט שמות: `YYYY-MM-DD-feature-name.md`. לכל תוכנית יהיה קובץ משלה. אחרי חודש יהיו לכם 20-30 קבצים; אחרי שישה חודשים, 100+. זוהי היסטוריה חיה של החלטות הפרויקט. **שלב 3. נסו את `/goal` במשימה אחת.** בחרו משימה שאתם מבצעים בדרך כלל ידנית במשך 30-40 דקות. הפעילו את Plan Mode, צרו תוכנית ושמרו אותה ב-`plans/`. צאו מ-Plan Mode. הגדירו `/goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns`. סגרו את המחשב הנייד למשך שעה ועשו משהו אחר. חזרו ובדקו את התוצאה. אלה שלושת הצעדים המינימליים. בונים את זה בהדרגה; אל תנסו לחבר הכול בערב אחד. התחילו ב-CLAUDE.md, הוסיפו `plans/` אחרי שבוע ונסו את `/goal` במהלך הלילה אחרי חודש.
### מקורות - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
כשתהיו מוכנים, הכירו את [Ailoot](https://ailoot.ai/). ## שאלות ותשובות: Plan Mode ב-Claude Code: מדריך שלב אחר שלב וארבעת השלבים ב-2026 ### האם אפשר לדלג על תכנון רק מפני שאני יודע אילו קבצים ישתנו? לא. שמות קבצים ידועים אינם מסירים אי-ודאות לגבי תופעות לוואי או אימות. תכננו הגירות, שינויי אימות ושינויים מתואמים בין רכיבים גם כשכבר ברור אילו קבצים יושפעו. ### מתי שלב נפרד של Plan Mode מיותר? ב-diff קטן, מובן ובסיכון נמוך עם בדיקה ברורה, כגון שגיאת הקלדה מקומית, עבודה ישירה היא סבירה. השתמשו בתכנון כשהגישה לא ברורה, הקוד לא מוכר או שצריך לברר סיכונים תפעוליים ובין קבצים. ## Ailoot · החברה ופורטפוליו הפרויקטים שלה Ailoot נשענת על ניסיון תפעולי מצטבר, בסיס לקוחות רחב, שירות יציב ובקרה שוטפת של KPI. החברה ופורטפוליו הפרויקטים שלה: מיליוני לקוחות; מכירות בהיקף של מיליארדים מדי חודש. Ailoot משתמשת בניסיון התפעולי הזה כדי לספק גישת API ליכולות AI במוצרי לקוחות, בסוכנים, באפליקציות ובאוטומציות.