Advanced Prompting and Context Mastery — הנדסת פרומפטים מתקדמת

מה יהיה לך בסוף הפרק הזה

שליטה מלאה ב-Plan Mode — כולל Multi-Session Planning וביקורת עצמית של תוכניות
אסטרטגיית /compact מותאמת אישית עם compactInstructions ב-CLAUDE.md
הבנה טכנית של חלון ההקשר — מה צורך טוקנים, כמה, ואיך לחסוך
שליטה ברמות Effort — מתי Low, מתי Medium, מתי High, ומתי "ultrathink"
5 דפוסי שיחה מתקדמים: Funnel, Iteration, Expert Panel, Checkpoint, Breadcrumb
מערכת שרשור סשנים עם קובץ TASK-STATE.md
ספריית תבניות פרומפט אישית — לפחות 5 תבניות מוכנות לשימוש כ-Skills
טכניקות מומחה לניהול הקשר: Pre-loading, Partitioning, Selective Context

יעדי למידה — מה תדע לעשות

תוכל/י להפעיל Plan Mode עם ביקורת עצמית (Plan Review) ולחסוך 25-45% מצריכת ההקשר
תוכל/י להגדיר compactInstructions מותאמים ב-CLAUDE.md ולנהל דחיסה יזומה בזמן הנכון (חוק ה-60%)
תוכל/י לבחור רמת Effort מתאימה לכל משימה ולהגדיר Effort קבוע ב-Skills
תוכל/י ליישם לפחות 3 מתוך 5 דפוסי שיחה מתקדמים (Funnel, Iteration, Expert Panel, Checkpoint, Breadcrumb)
תוכל/י לנהל פרויקט רב-יומי עם שרשור סשנים וקובץ TASK-STATE.md

דרישות קדם

פרקים קודמים: פרקים 1-8 של הקורס (Hooks, Agents, MCP, Skills, Plugins, Worktrees, Memory, Security) — הפרק הזה מתבסס על כל הרכיבים שנלמדו
כלים נדרשים: Claude Code מותקן ומוגדר, חשבון Pro/Max/Team/Enterprise פעיל, CLAUDE.md קיים בפרויקט
זמן משוער: 3-4 שעות (כולל תרגילים)

🔗 הפרויקט שלך

בפרק הקודם (פרק 8: Security) למדת לאבטח את סביבת העבודה שלך — Sandbox, הרשאות, מדיניות ארגונית, ותגובה לאירועים. עכשיו שהסביבה מאובטחת, בפרק הזה תלמד לעבוד בתוכה בצורה הכי יעילה שאפשר — פרומפטים חכמים יותר, ניהול הקשר מדויק, ובקרת עלויות. בפרק הבא (פרק 10: Personal Toolkit) תחבר את הכל יחד — Hooks, Agents, MCP, Skills, Plugins, אבטחה ופרומפטים — למערכת עבודה אישית שלמה.

מילון מונחים — פרק 9

מונח באנגלית	הסבר בעברית
Plan Mode	מצב תכנון — Claude מנתח ומציע תוכנית פעולה לפני שמבצע. מופעל עם Shift+Tab פעמיים או `/plan`
Context Window	חלון הקשר — כמות הטקסט (בטוקנים) ש-Claude יכול "לראות" בו-זמנית. 200K ברירת מחדל, עד 1M ב-Max/Team/Enterprise
/compact	פקודת דחיסה — מכווצת את השיחה תוך שמירה על עובדות מפתח. מקבלת הוראות מותאמות
Token	טוקן — יחידת מדידה בסיסית. בערך 4 תווים באנגלית, 1-2 תווים בעברית. כל מילה = 1-3 טוקנים
Effort Level	רמת מאמץ — Low (מהיר וזול), Medium (ברירת מחדל), High (מעמיק ויקר). נשלט עם `/effort`
Extended Thinking	חשיבה מורחבת — "דף טיוטה" פנימי ש-Claude משתמש בו לנמק לפני שעונה. גלוי לך אבל עולה יותר
Ultrathink	מילת מפתח שמכריחה חשיבה מעמיקה (High Effort) לבקשה ספציפית, ללא קשר להגדרת ה-/effort
Auto-Compaction	דחיסה אוטומטית — Claude מכווץ את השיחה אוטומטית כשההקשר מגיע ל-80%. עשויה למחוק פרטים חשובים
Session Chaining	שרשור סשנים — עבודה על פרויקט ארוך במספר סשנים, עם קובץ מצב שמעביר מידע ביניהם
Prompt Template	תבנית פרומפט — מבנה מוכן מראש לבקשה נפוצה, עם חורים למילוי. נשמר כ-Skill לשימוש חוזר
Voice Mode	מצב קולי — Push-to-Talk עם לחיצה ממושכת על Spacebar. 20 שפות כולל עברית. הופעל עם `/voice`
/fork	מעתיק את השיחה הנוכחית לענף נפרד. השיחה המקורית לא מושפעת — מאפשר ניסויים בטוחים
/loop	מריץ פרומפט במרווחי זמן קבועים (למשל כל 5 דקות) — cron קל בתוך הסשן

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

מתחילים 5 דקות חינם תיאוריה

בקורס הבסיסי למדת לכתוב פרומפטים ברורים וספציפיים. זה מספיק כדי להתחיל, אבל זה רק ההתחלה. הנדסת פרומפטים מתקדמת (Advanced Prompt Engineering) זה לא רק "מה לשאול" אלא "איך לשאול" — כדי לקבל תוצאות טובות יותר, מהר יותר, ובפחות עלות.

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

חיסכון בעלויות. פרומפט מתקדם שעובד עם Plan Mode, Effort נכון, וניהול הקשר מדויק — מייצר את אותה תוצאה ב-30% מהעלות של פרומפט נאיבי.

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

"The Prompting Triangle" — משולש הפרומפט: Quality (כמה טובה התוצאה), Cost (כמה טוקנים צורך), Speed (כמה מהר Claude מגיב). הנדסת פרומפטים מתקדמת ממטבת את שלושתם בו-זמנית.

בפרקים הקודמים למדת לבנות כלים: Hooks (אוטומציה), Agents (סוכנים), MCP (חיבורים חיצוניים), Skills (פקודות מותאמות), Plugins (חבילות), Worktrees (עבודה מקבילית), Memory (זיכרון), ו-Security (אבטחה). בפרק הזה תלמד את האומנות של התקשורת עם Claude עצמו — איך לנצל כל אחד מהכלים האלה בצורה המושלמת, ואיך לנהל את המשאב הכי יקר: חלון ההקשר.

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

הנה דוגמה מהחיים שממחישה את ההבדל. סטארטאפ ישראלי עם 6 מפתחים רצה לרפקטר את מודול התשלומים שלהם. מפתח א' פתח סשן וכתב: "Refactor the payment module." Claude התחיל לקרוא קבצים, ניסה שינוי, גילה שגיאה, חזר אחורה, קרא עוד קבצים. אחרי 40 דקות — הקשר מלא, תוצאה חלקית, $4.50 הוצאו. מפתח ב' התחיל עם /plan refactor the payment module — focus on separating Stripe logic from business logic. תוך 3 דקות הייתה תוכנית מפורטת. הוא עשה Plan Review, תיקן שלב אחד, ואז הפעיל. תוך 15 דקות — תוצאה מלאה ומדויקה, $1.30.

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

מה תלמד בפרק הזה — מפת הדרכים

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

סעיף	מה תלמד	ההשפעה
9.2 Plan Mode	תכנון לפני ביצוע, ביקורת עצמית, Multi-Session Planning	חיסכון 25-45% בהקשר, פחות שגיאות
9.3 /compact	דחיסה חכמה עם הוראות מותאמות, תזמון נכון	שליטה במה שנשמר ומה נמחק
9.4 Context Window	מה צורך טוקנים, כמה, ואיך לחסוך	סשנים ארוכים יותר באיכות גבוהה
9.5-9.6 Effort & Thinking	שליטה בעומק החשיבה ובעלות	התאמת עלות לערך המשימה
9.7-9.8 Conversations & Sessions	דפוסי שיחה, שרשור סשנים	עבודה רב-יומית ללא אובדן מידע
9.9-9.11 Hebrew, Templates, Mastery	דפוסי עברית, ספריית תבניות, טכניקות מומחה	פרודוקטיביות מקסימלית

⚡ עשה עכשיו 2 דקות

פתח סשן חדש של Claude Code והקלד /context. שים לב: כמה אחוזים מחלון ההקשר כבר תפוסים רק מ-CLAUDE.md, הוראות מערכת, ו-MCP Tool Schemas? אם התשובה היא מעל 10% — יש לך עבודה לעשות בפרק הזה. תעד את המספר ונחזור אליו בסוף.

Plan Mode Mastery — תכנון לפני ביצוע

בינוני 10 דקות ~$0.10 מעשי

Plan Mode הוא הפיצ'ר הכי חסכוני ב-Claude Code, ורוב המשתמשים לא מנצלים אותו מספיק. הרעיון פשוט: במקום שClaude יקפוץ ישר לביצוע (קריאת קבצים, עריכה, הרצת פקודות), הוא מנתח קודם, מציע תוכנית, ורק אחרי שאתה מאשר — מבצע.

מפעילים את Plan Mode בשתי דרכים:

Shift+Tab פעמיים — מפעיל מצב תכנון על הפרומפט הנוכחי
/plan refactor the database layer — נכנס ישירות למצב תכנון עם תיאור קצר של המשימה

איך Plan Mode חוסך 25-45% מהקשר

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

בלי Plan Mode: Claude חוקר (5K טוקנים) + מבצע (10K טוקנים) = 15K טוקנים צבורים. עם Plan Mode: Claude חוקר (5K) → מאשר → הקשר מתנקה → מבצע (10K) = 10K טוקנים בלבד. חיסכון של שליש.

25-45%

חיסכון בצריכת הקשר עם Plan Mode. על משימה שעולה $1.50 — זה $0.40-0.70 חיסכון. על פרויקט שבועי — עשרות דולרים.

טכניקות Plan Mode מתקדמות

1. הפרדת חשיבה מביצוע: הוסף "plan only, don't implement" לפרומפט. Claude יציע תוכנית מלאה בלי לגעת בקובץ אחד. ככה אתה שולט לחלוטין בקצב הביצוע.

2. ביקורת עצמית (Plan Review): אחרי שClaude מציע תוכנית, אל תאשר מיד. במקום זה, שאל:

📚 דוגמה — Plan Review

"Now review this plan for issues, missing steps, or better alternatives. What could go wrong with this approach?"

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

3. Multi-Session Planning: לפרויקטים גדולים, השתמש ב-Plan Mode בסשן 1 כדי ליצור תוכנית. שמור את התוכנית לקובץ:

📚 דוגמה — Multi-Session Planning

/plan refactor the authentication module # אחרי שClaude מציע תוכנית: "Save this plan to PLAN-auth-refactor.md" # סשן 2 (יום למחרת): "Read PLAN-auth-refactor.md and execute steps 1-3" # סשן 3: "Read PLAN-auth-refactor.md and execute steps 4-6"

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

Plan Mode — דוגמאות מייצגות מהשטח

דוגמה 1: רפקטורינג API בסטארטאפ ישראלי

צוות פיתוח בתל אביב צריך לשנות את מבנה ה-API — להעביר מ-REST ל-GraphQL. בלי Plan Mode, מפתח מתחיל לערוך קבצים, גולש לכיוונים צדדיים, מגלה תלויות שלא חשב עליהם, וההקשר מתמלא ב-40 דקות. עם Plan Mode:

📚 Plan Mode בפעולה

/plan migrate users API endpoint from REST to GraphQL. Keep backward compatibility with /api/v1/users for 30 days. # Claude מציע תוכנית עם 7 שלבים "Review this plan — what about the authentication middleware? It checks req.body which doesn't exist in GraphQL resolvers." # Claude מעדכן את התוכנית — מוסיף שלב 2.5: adapt auth middleware "Good. Execute steps 1-3."

ההבדל: הביקורת העצמית (Plan Review) תפסה בעיית Authentication שהייתה גורמת ל-3 שעות Debug בהמשך.

דוגמה 2: בניית Feature חדש

משווקת דיגיטלית רוצה ליצור דשבורד שמציג נתוני Google Analytics. במקום "build me a dashboard," היא כותבת:

📚 Plan Mode ל-Feature

/plan build analytics dashboard. Show: page views (7d), top 5 pages, bounce rate trend. Use Chart.js. Data from Google Analytics API. Hebrew UI.

Claude מציע תוכנית: (1) מבנה HTML, (2) הגדרת API, (3) גרפים, (4) עברית, (5) Responsive. היא מאשרת ומקבלת Feature מלא ב-$0.80 במקום $2.50 בלי תכנון.

💡 כלל הדולר

לכל משימה שתעלה יותר מ-$1, תמיד תתחיל ב-Plan Mode. ה-$0.10 שמושקע בתכנון חוסך $0.50-2.00 בביצוע — בגלל שנמנעים מטעויות, פניות שגויות, וקריאת קבצים מיותרים.

⚡ עשה עכשיו 5 דקות

בחר משימה אמיתית שאתה צריך לבצע (Refactoring, Bug Fix, כתיבת Tests). הפעל /plan [תיאור המשימה]. כשClaude מציע תוכנית — אל תאשר מיד. במקום זה כתוב: "Review this plan — what's missing?" בדוק אם הביקורת העצמית הוסיפה ערך. אם כן — אשר את הגרסה המשופרת.

/compact עם הוראות מותאמות

בינוני 10 דקות חינם מעשי

הפקודה /compact מכווצת את השיחה — סוג של "גיבוי מדחוס" שמוחק את הפרטים השוליים ושומר על העובדות החשובות. אבל ברירת המחדל של /compact לא תמיד שומרת מה שחשוב לך. אולי Claude ימחק את כתובות ה-API שאתה צריך, או ישמור פרטים שלא חשובים.

הפתרון: הוראות מותאמות אישית.

Compact עם הוראות בזמן אמת

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

📚 דוגמה — /compact מותאם

/compact keep the API endpoint URLs, error messages, and the deployment plan. Drop the file contents and search results

Claude יכווץ את השיחה אבל ישמור את כתובות ה-API, הודעות השגיאה, ותוכנית ה-Deploy. כל תוכן הקבצים ותוצאות החיפוש — ימחקו.

compactInstructions — הגדרה קבועה

אם אתה מוצא את עצמך כותב את אותן הוראות compact שוב ושוב, הגדר אותן פעם אחת ב-CLAUDE.md:

📚 דוגמה — compactInstructions ב-CLAUDE.md

## Compact Instructions When compacting context, ALWAYS preserve: - Current task state and pending items - File paths being actively worked on - Error messages and their root causes - API endpoint URLs and response formats - Database schema changes and migration status Drop: tool call details, intermediate search results, verbose log output, file contents already committed.

מהרגע שזה ב-CLAUDE.md, כל /compact ישתמש בהוראות האלה אוטומטית. לא צריך לזכור לציין כל פעם מחדש.

מתי לעשות Compact — חוק ה-60%

הרבה משתמשים ממתינים ל-Auto-Compaction — הדחיסה האוטומטית שמופעלת כשההקשר מגיע ל-80%. זו טעות. ב-80% כבר מאוחר:

60% — הזמן האידיאלי לעשות /compact ידני. אתה שולט במה נשמר ומה נמחק
70% — אם לא עשית compact, זה הזמן האחרון. איכות התשובות מתחילה לרדת
80% — Auto-Compaction מופעל. Claude מכווץ אגרסיבית — פרטים חשובים עלולים לאבד

⚠ טעות נפוצה: דחיסה חוזרת בלי מודעות

מה הטעות: משתמשים מריצים /compact שוב ושוב באותו סשן — 4-5 פעמים — ואז תוהים למה Claude "שכח" פרטים חשובים. למה מפתה: כי Compact עובד כל כך טוב בפעם הראשונה, אז נראה שאפשר להמשיך. מה לעשות במקום: מקסימום 2-3 דחיסות בסשן אחד. Compact פעם ראשונה = סיכום של השיחה. שנייה = סיכום של סיכום. שלישית = סיכום של סיכום של סיכום — פרטים קריטיים הולכים לאיבוד. אם צריך יותר — שמור מצב לקובץ ופתח סשן חדש.

דוגמאות מייצגות — compactInstructions לתפקידים שונים

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

Backend Developer:

📚 compactInstructions — Backend

## Compact Instructions ALWAYS preserve: API endpoint URLs, database schema changes, migration status, error messages with stack traces, environment variable names (not values). Drop: file contents already committed, npm install output, test run details.

Frontend Developer:

📚 compactInstructions — Frontend

## Compact Instructions ALWAYS preserve: component hierarchy, CSS class names in use, state management decisions, responsive breakpoints, accessibility issues found. Drop: full CSS contents, node_modules errors, build output.

Content Creator / Marketer:

📚 compactInstructions — Content

## Compact Instructions ALWAYS preserve: content brief, target keywords, tone guidelines, Hebrew phrasing decisions, client feedback, approved headlines. Drop: search results, competitor analysis raw data, draft versions.

שים לב לדפוס: לכל תפקיד, ה-compactInstructions שומרים מה שייחודי ומחקים מה שניתן לשחזר. Backend Developer צריך את ה-API URLs כי הם מפוזרים על פני קבצים רבים. Content Creator צריך את ההחלטות על טון ומילות מפתח — כי אלה מנחות את כל היצירה.

⚡ עשה עכשיו 5 דקות

פתח את ה-CLAUDE.md שלך (או צור אחד אם אין). הוסף סעיף ## Compact Instructions עם 5 דברים שאתה תמיד רוצה לשמור בדחיסה. חשוב על מה חשוב בעבודה היום-יומית שלך: נתיבי קבצים? כתובות API? שמות משתנים? הודעות שגיאה? תעד את 5 הדברים הקריטיים ביותר.

מסגרת החלטה: אסטרטגיית Compact

מצב	פעולה	למה
הקשר 40-60%, עובד בזרימה	לא לעשות Compact	יש עדיין מקום. Compact מיותר ימחק פרטים שימושיים
הקשר 60%, המשימה ארוכה	`/compact` עם הוראות מותאמות	זמן אידיאלי — שולט במה שנשמר לפני שנגמר מקום
הקשר 70%+, עומד לפתוח קבצים גדולים	`/compact` אגרסיבי + צמצום קריאת קבצים	פנה מקום לפני שקורא קבצים כבדים
כבר עשית 2 דחיסות בסשן	שמור מצב לקובץ, פתח סשן חדש	דחיסה שלישית תאבד יותר מדי פרטים

ניהול חלון הקשר — הפרטים הטכניים

מתקדם 15 דקות חינם תיאוריה + מעשי

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

גדלים ומגבלות (מרץ 2026)

תוכנית	מודל	חלון הקשר
Pro	Opus 4.6	200K טוקנים
Max / Team / Enterprise	Opus 4.6	1M טוקנים (מיליון)

נשמע הרבה? 200K טוקנים זה בערך 150,000 מילים — ספר שלם. אבל בפועל, חלק גדול מההקשר מתמלא לפני שאתה מקליד מילה אחת. בואו נראה מה צורך מקום:

מה צורך טוקנים — ובכמה

מקור	צריכה טיפוסית	הערה
CLAUDE.md + rules	2,000-10,000 טוקנים	נטען אוטומטית בתחילת כל סשן
תור שיחה בודד (שלך + Claude)	500-5,000 טוקנים	תלוי באורך השאלה והתשובה
פלט כלי (Read, Grep, Bash)	200-10,000 טוקנים	קריאת קובץ שלם = אלפי טוקנים
MCP Tool Schemas	2,000-15,000 טוקנים	הגדרות הכלים החיצוניים — גם אם לא משתמשים בהם
Auto-Memory	1,000-3,000 טוקנים	זיכרון אוטומטי שנטען בתחילת סשן

4,000

טוקנים — זו העלות של קריאת קובץ אחד בן 2,000 שורות. שווה ל-20 תורות שיחה. קריאה אחת לא זהירה יכולה לבזבז 10% מחלון ההקשר בתוכנית Pro.

טכניקות חיסכון בטוקנים

1. Read עם offset ו-limit: במקום לקרוא קובץ שלם, ציין בדיוק מה אתה צריך:

📚 קריאה חסכונית לעומת בזבזנית

בזבזני: "Read the entire utils.py file" → 2,000 שורות = ~4,000 טוקנים
חסכוני: "Read utils.py lines 45-90" → 45 שורות = ~100 טוקנים
חיסכון: 97.5%

2. Grep עם files_with_matches: כשצריך רק למצוא איפה משהו נמצא (לא לקרוא את התוכן), השתמש ב-mode שמחזיר רק שמות קבצים:

📚 חיפוש חסכוני

בזבזני: "Search for all uses of validateToken" → מחזיר 50 שורות עם הקשר = ~2,000 טוקנים
חסכוני: "Search for validateToken — just give me file names" → 5 קבצים = ~50 טוקנים
שלב 2: "Now read the relevant section in auth/middleware.js" → קריאה ממוקדת

3. Glob ממוקד: חפש בתיקייה ספציפית, לא בשורש הפרויקט:

📚 חיפוש מכוון

בזבזני: "Find all TypeScript files" → סורק את כל הפרויקט
חסכוני: "Find TypeScript files in src/auth/" → סורק רק את התיקייה הרלוונטית

4. head_limit בתוצאות חיפוש: הגבל את מספר התוצאות. לרוב 5-10 תוצאות מספיקות כדי להבין את הדפוס.

חיסכון בפועל — לפני ואחרי

הנה דוגמה ממשית של אותה משימה, לפני ואחרי אופטימיזציית הקשר:

פעולה	לפני (נאיבי)	אחרי (מותאם)	חיסכון
איתור באג ב-auth module	"Read all files in src/auth/" 5 קבצים = ~15,000 טוקנים	"Grep 'validateToken' in src/auth/ — files only" 3 שמות קבצים = ~50 טוקנים	99.7%
קריאת הקובץ הרלוונטי	"Read auth/middleware.js" 400 שורות = ~800 טוקנים	"Read auth/middleware.js lines 55-85" 30 שורות = ~60 טוקנים	92.5%
חיפוש שימושים	"Find all usages of this function" 50 תוצאות עם הקשר = ~3,000 טוקנים	"Find usages — just file names, limit 10" 10 שמות = ~100 טוקנים	96.7%
סה"כ למשימה	~18,800 טוקנים	~210 טוקנים	98.9%

כן, קראת נכון — חיסכון של 98.9% על שלב חקירה בודד. על פני סשן שלם עם 10 שלבי חקירה, זה ההבדל בין מילוי 90% מההקשר לבין שימוש ב-10% בלבד. זה אומר שאפשר לעבוד פי 9 יותר באותו סשן.

MCP Tool Schemas — הבזבזן השקט

אם יש לך 5 שרתי MCP מחוברים, כל אחד עם 10 כלים — Claude צריך לראות את ההגדרות של כל 50 הכלים. זה יכול להיות 10,000-15,000 טוקנים — 5-7.5% מחלון הקשר בתוכנית Pro, לפני שהתחלת לעבוד.

הפתרון: Deferred Tool Loading. ברירת מחדל, Claude Code כבר מפעיל את זה אוטומטית כשיש יותר מדי כלים (הסף הוא 10% מההקשר). כלים שלא בשימוש פעיל מסומנים כ-defer_loading: true — Claude רואה רק את השם, לא את ההגדרה המלאה. כשצריך כלי ספציפי, הוא טוען אותו דינמית.

אבל אפשר לעזור: אם יש MCP Servers שאתה משתמש בהם רק לפעמים — נתק אותם מה-settings.json כשלא צריך. כל שרת MCP שמחובר = טוקנים שנצרכים בכל סשן, גם אם לא משתמשים בו.

⚡ עשה עכשיו 3 דקות

בסשן Claude Code הנוכחי, הקלד /context. בדוק: (1) כמה אחוזים תפוסים כרגע? (2) מה התורם הגדול ביותר? (3) אם יש לך MCP Servers — כמה מההקשר הולך על Tool Schemas שאתה לא משתמש בהם? רשום את המספרים. בסוף הפרק נבדוק אם שיפרת.

מסגרת החלטה: הקשר כמשאב (Context as a Resource)

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

פעולה	עלות בטוקנים	אנלוגיה ל-RAM
שאלה קצרה + תשובה	~500	הקצאה קטנה — malloc(500)
קריאת קובץ 50 שורות	~100	קריאת בלוק מדיסק
קריאת קובץ 2,000 שורות	~4,000	טעינת ספרייה שלמה
MCP Tool Schemas (50 כלים)	~10,000	DLL שנטען ולא משוחרר
/compact	שלילי (משחרר)	Garbage Collection

Effort Levels — /effort Low, Medium, High

בינוני 10 דקות ~$0.05-0.50 מעשי

החל ממרץ 2026, הפקודה /effort שולטת בעומק החשיבה של Claude. חשוב על זה כגיר ידני — אתה בוחר את ההילוך המתאים לכל דרך:

שלוש רמות Effort

רמה	אייקון	מתי להשתמש	עלות יחסית
Low	○ (עיגול ריק)	עריכות פשוטות, פורמט, פעולות קובץ, שאלות מהירות	~1x (בסיסי)
Medium	◑ (חצי עיגול)	רוב משימות הפיתוח, כתיבת תוכן, Code Review — ברירת מחדל ל-Opus 4.6	~3x
High	● (עיגול מלא)	החלטות ארכיטקטורה, ביקורת אבטחה, Debug של באגים עדינים, כתיבה יצירתית	~8x

ברירת המחדל של Opus 4.6 היא Medium. זה מספיק לרוב המשימות. אבל הכוח האמיתי הוא בהחלפה דינמית — משנים Effort באמצע סשן לפי הצורך:

📚 דוגמה — החלפת Effort דינמית

/effort low "Rename the variable 'x' to 'userCount' in all files" /effort high "Now analyze the race condition in the payment handler. Ultrathink." /effort medium "Write unit tests for the fix"

מילת הקסם: "ultrathink"

לא רוצה לשנות את הגדרת ה-Effort לכל הסשן? כתוב "ultrathink" (או "ultra think") בפרומפט עצמו. Claude יפעיל High Effort רק לאותה בקשה, ויחזור לרמת הברירת-מחדל מיד אחרי.

📚 דוגמה — ultrathink

"Ultrathink — there's a subtle memory leak in the WebSocket handler. Find the root cause and suggest a fix that doesn't break the reconnection logic."

Effort ב-Skills — הגדרה קבועה לכל פקודה

Skills יכולים לקבוע רמת Effort משלהם ב-YAML Frontmatter, ללא קשר להגדרת הסשן. זה אחד הכלים הכי חזקים לבקרת עלויות — כי אתה מגדיר פעם אחת ומקבל את רמת ה-Effort הנכונה אוטומטית בכל הפעלה.

📚 דוגמה — Skills עם Effort שונים

# .claude/commands/format-code.md --- name: format-code description: Auto-format changed files effort: low --- Format all recently changed files according to project standards. # .claude/commands/security-check.md --- name: security-check description: Deep security audit of recent changes effort: high --- Perform a thorough security review. Check for OWASP Top 10. Ultrathink.

כשמפעילים /format-code, Claude עובד מהר וזול (Low). כשמפעילים /security-check, Claude חושב לעומק ומוצא בעיות עדינות (High). אותו כלי, Effort מותאם — בקרת עלויות אוטומטית.

דוגמה מייצגת — חיסכון עם Effort נכון

DevOps Engineer בחברה ישראלית מריץ 15-20 Skills ביום. הנה פילוח עלויות לפני ואחרי התאמת Effort:

Skill	לפני (ברירת מחדל Medium)	אחרי (Effort מותאם)
`/format-code` (5x/day)	$0.15 x 5 = $0.75	Low: $0.02 x 5 = $0.10
`/run-tests` (3x/day)	$0.15 x 3 = $0.45	Low: $0.02 x 3 = $0.06
`/review-pr` (4x/day)	$0.15 x 4 = $0.60	Medium: $0.15 x 4 = $0.60
`/security-check` (1x/day)	$0.15 x 1 = $0.15	High: $0.50 x 1 = $0.50
סה"כ יומי	$1.95	$1.26

חיסכון יומי: $0.69. חודשי (22 ימי עבודה): $15.18. ושימו לב — ביקורת האבטחה עלתה מ-$0.15 ל-$0.50, אבל השיפור באיכות שווה הרבה יותר מ-$0.35. התאמת Effort = חיסכון במקום שלא חשוב, השקעה במקום שכן.

⚡ עשה עכשיו 3 דקות

פתח סשן Claude Code. הקלד /effort low ובקש משימה פשוטה (למשל, "rename variable x to count in file.js"). שים לב לזמן התגובה ולאיכות. עכשיו הקלד /effort high ובקש משהו מורכב ("analyze the error handling in this module — are there edge cases we're missing?"). השווה: זמן, עומק, ואיכות. ההבדל מרגיש כמו ההבדל בין חיפוש Google לבין מאמר מחקרי.

מסגרת החלטה: התאמת מאמץ לערך (Effort-Cost Mapping)

סוג משימה	Effort מומלץ	עלות משוערת	הצדקה
שינוי שם משתנה, הזזת קובץ	Low	~$0.01	אין צורך בחשיבה — פעולה מכנית
כתיבת פונקציה חדשה, Code Review	Medium	~$0.05-0.20	צריך הבנה בסיסית — ברירת מחדל מספיקה
ביקורת אבטחה, Debugging מורכב	High	~$0.20-1.00	טעות כאן עולה יותר מהחיסכון ב-Effort
החלטת ארכיטקטורה, עיצוב מערכת	High + ultrathink	~$0.50-2.00	ההחלטות האלה משפיעות לחודשים — שווה להשקיע

Extended Thinking — חשיבה מורחבת

מתקדם 10 דקות ~$0.10-0.50 תיאוריה + מעשי

חשיבה מורחבת (Extended Thinking) נותנת ל-Claude "דף טיוטה" פנימי. לפני שהוא עונה, הוא חושב — והחשיבה הזו גלויה לך אבל לא נספרת כחלק מהתשובה. זה כמו לראות מישהו פותר בעיה על דף טיוטה לפני שכותב את התשובה הסופית.

איך זה עובד טכנית

Budget Tokens: פרמטר שמגדיר כמה טוקנים Claude יכול להשתמש לחשיבה. מינימום 1,024 טוקנים. ברירת המחדל — עשרות אלפי טוקנים, תלוי במודל
Output Tokens: טוקני חשיבה נחשבים כ-Output Tokens — שהם יקרים יותר מ-Input Tokens. לכן חשיבה מורחבת מעלה עלות
שליטה: /config (כיבוי חשיבה לחלוטין), /effort (שליטה ברמת עומק), או משתנה סביבה MAX_THINKING_TOKENS

מתי חשיבה מורחבת עוזרת

חשיבה רב-שלבית: בעיות שדורשות כמה צעדי חשיבה — Claude צריך לנמק לפני שמסיק מסקנה
קוד עם תלויות מורכבות: כשצריך להבין איך שינוי ב-Module A משפיע על Module B ש-Module C תלוי בו
בעיות לוגיות/מתמטיות: חישובים, אלגוריתמים, אופטימיזציות
כתיבה יצירתית: בחירת מילים, מבנה טקסט, טון — Claude בוחר טוב יותר כשיש לו מקום לחשוב

מתי חשיבה מורחבת מזיקה

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

📚 דוגמה — מתי לכבות/להדליק

כבה חשיבה: "שנה את כל ה-import statements מ-require() ל-import" — פעולה מכנית, אין צורך לנמק

הדלק חשיבה: "יש Race Condition ב-Payment Handler. שני Threads ניגשים לאותו Balance. מצא את שורש הבעיה ותקן" — בלי חשיבה מעמיקה, Claude עלול להציע Fix שטחי שלא פותר את הבעיה

💡 חיסכון חכם עם Effort

במקום לכבות ולהדליק חשיבה ידנית, השתמש ב-/effort. Low Effort = חשיבה מינימלית. High Effort = חשיבה מקסימלית. Medium = ברירת מחדל מאוזנת. ככה לא צריך להתעסק עם הגדרות טכניות — פשוט תאמר ל-Claude כמה מאמץ להשקיע.

⚡ עשה עכשיו 3 דקות

בסשן Claude Code: הקלד /effort high ואז שאל שאלה מורכבת על הקוד שלך (למשל: "Are there any potential race conditions in this module?"). כשהתשובה מגיעה, שים לב ל-Thinking Section — אזור החשיבה שמופיע לפני התשובה. קרא את החשיבה ובדוק: האם היא הוסיפה ערך? האם Claude מצא משהו שלא היית מגלה בלעדיה? עכשיו הקלד /effort low ושאל את אותה שאלה. השווה את התוצאות.

מסגרת החלטה: חשוב או דלג (Think or Skip)

סוג המשימה	חשיבה?	Effort	נימוק
שינוי שם קובץ/משתנה	לא	Low	פעולה מכנית — חשיבה = בזבוז
כתיבת פונקציה פשוטה	מעט	Medium	ברירת מחדל מספיקה
Debug של באג שלא מצליח לשחזר	הרבה	High	חשיבה מעמיקה = מציאת root cause
ביקורת אבטחה	מקסימלית	High + ultrathink	פספוס פגיעות = סיכון אמיתי
החלטת ארכיטקטורה	מקסימלית	High + ultrathink	החלטה שגויה = חודשי תיקון
פורמט קוד (Lint, Prettier)	לא	Low	כללים מוגדרים מראש — אין מה לחשוב
כתיבת Tests	בינונית	Medium	צריך להבין את הלוגיקה, אבל לא מחקר מעמיק
תוכן שיווקי בעברית	הרבה	High	ניואנסים ובחירת מילים דורשים חשיבה יצירתית

אסטרטגיות שיחה מרובת-תורות

בינוני 15 דקות ~$0.20-0.50 מעשי

רוב המשתמשים כותבים פרומפט אחד ארוך ומצפים לתשובה מושלמת. Power Users מנהלים שיחה — סדרה של פרומפטים קצרים שכל אחד מקרב לתוצאה. הנה 5 דפוסים מוכחים:

1. The Funnel Pattern — דפוס המשפך

מתחילים רחב ומצמצמים בהדרגה. כל תור מוסיף ספציפיות:

📚 דוגמה — Funnel Pattern

תור 1: "Explore the auth module — what are its main components?" תור 2: "Now focus on the JWT validation — where is it implemented?" תור 3: "Fix the expiration check on line 45 — it doesn't handle timezone offsets"

כל תור צורך מעט הקשר (500-1,000 טוקנים) אבל מכוון את Claude בדיוק לנקודה הנכונה. לעומת פרומפט אחד גדול שגורם ל-Claude לקרוא את כל המודול ולנחש מה אתה צריך.

2. The Iteration Pattern — דפוס האיטרציה

בונים את התוצאה בצעדים קטנים:

📚 דוגמה — Iteration Pattern

תור 1: "Write a basic Express middleware for rate limiting" תור 2: "Good, but add Redis support for distributed rate limiting" תור 3: "Perfect. Now add logging for blocked requests" תור 4: "Last thing — add configurable limits per route"

כל שיפור קטן עולה 500-1,000 טוקנים. לעומת: "Write rate limiting middleware with Redis, logging, and configurable limits" שעולה 5,000+ טוקנים ולא תמיד מייצר תוצאה טובה בנסיון ראשון.

3. The Expert Panel Pattern — פאנל מומחים

מבקשים מ-Claude לנתח מנקודות מבט שונות ברצף:

📚 דוגמה — Expert Panel

"First, analyze this code as a security expert — focus on vulnerabilities." "Now analyze the same code as a performance expert — focus on bottlenecks." "Finally, analyze it as a readability expert — focus on maintainability."

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

4. The Checkpoint Pattern — נקודות ביקורת

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

📚 דוגמה — Checkpoint Pattern

"Before continuing, confirm: we've done (1) refactored the schema, (2) updated the migration. The next steps are (3) update the API endpoints, (4) update the tests. Is this correct?"

שלב הביקורת הזה מונע "סחף" (Drift) — מצב שבו Claude שוכח מה המטרה ומתחיל לעבוד על דברים אחרים. שלב Checkpoint עולה ~200 טוקנים אבל חוסך שגיאות של אלפי טוקנים.

5. The Breadcrumb Pattern — פירורי לחם

לקודבייסים גדולים, בונים הבנה בהדרגה:

📚 דוגמה — Breadcrumb Pattern

תור 1: "List all directories in src/ — just the names" תור 2: "What's the main entry point in src/api/?" תור 3: "Summarize the 3 most important functions in src/api/routes.ts" תור 4: "Now read only lines 120-180 of src/api/routes.ts — I need to fix the error handler there"

במקום "Read the entire project" (עשרות אלפי טוקנים), בונים "מפה מנטלית" בכמה מאות טוקנים בלבד, ורק אז קוראים את הקוד הספציפי שצריך.

⚠ טעות נפוצה: פרומפטים ארוכים וחזרתיים

מה הטעות: (1) כתיבת פרומפטים של 500+ מילים ב-turn אחד — Claude מאבד מיקוד. (2) חזרה על אותו פרומפט שנכשל — "אולי הפעם יצליח." (3) סשנים של 50+ תורות שבהם האיכות יורדת בהדרגה. למה מפתה: כי אתה רוצה לתת כמה שיותר הקשר מראש, ומרגיש שחזרה תעזור. מה לעשות במקום: פרומפטים קצרים וממוקדים. אם נכשל — שנה גישה (Pattern אחר, Effort אחר, ניסוח אחר). סשנים של 5-15 תורות ממוקדים הם אופטימליים.

5-15

תורות — הטווח האופטימלי לסשן ממוקד. Power Users שעובדים בסשנים קצרים וממוקדים מדווחים על איכות גבוהה יותר מאשר משתמשים שמריצים סשנים ארוכים של 50+ תורות. (דוגמאות מייצגות, מרץ 2026)

השוואה — Pattern נכון לכל מצב

מצב	Pattern מומלץ	למה
לא יודע איפה הבעיה	Funnel (מרחיב → מצמצם)	מתחיל רחב, ממקד בהדרגה
יודע מה צריך, רוצה איכות	Iteration (בנה → שפר)	תוצאה משתפרת בכל צעד
צריך ניתוח מקיף	Expert Panel (נקודות מבט)	מכסה זוויות שונות שתרשם
פרויקט רב-שלבי	Checkpoint (אשר → המשך)	מונע סחף ואי-הבנות
קודבייס גדול ולא מוכר	Breadcrumb (מבנה → פרט)	בונה הבנה בלי לצרוך הקשר

שילוב Patterns — הדפוס המשולב

ברוב המשימות האמיתיות, משלבים כמה Patterns. הנה דוגמה של Debug מורכב:

📚 דוגמה — שילוב Patterns

# Breadcrumb — מבנה קודם "List the directories in src/payment/" # Funnel — מצמצם "What files handle Stripe webhooks?" "Read the webhook handler — just lines 30-80" # Expert Panel — ניתוח "Analyze this as a security expert: is the webhook signature verified correctly?" "Now as a reliability expert: what happens if Stripe retries the same event?" # Checkpoint — ביקורת "Before fixing, confirm: the issues are (1) no idempotency check, (2) signature check uses wrong secret. Correct?" # Iteration — תיקון בשלבים "Fix the idempotency issue first." "Good. Now fix the signature verification."

6 תורות. Debug מלא. הקשר נקי. עלות נמוכה. זו האומנות של שיחה מתקדמת.

⚡ עשה עכשיו 5 דקות

בחר באג או משימת רפקטורינג אמיתית. נסה לפתור אותה עם Funnel Pattern: (1) בקש סקירה כללית של המודול. (2) צמצם למקטע הספציפי. (3) בקש תיקון ממוקד. שים לב: כמה תורות נדרשו? כמה מהם היו "בזבוז" (שאלות שלא קידמו את המשימה)? המטרה: 3-5 תורות ממוקדים לפתרון.

שרשור סשנים — Prompt Chaining Across Sessions

מתקדם 10 דקות חינם מעשי

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

התשובה: קובץ מצב (State File).

דפוס ה-TASK-STATE.md

📚 מבנה קובץ TASK-STATE.md

## Task: Refactor Database Layer ## Status: In Progress (Day 2) ## Completed: Schema redesign, migration script ## In Progress: API endpoint updates (routes/users.ts, routes/orders.ts) ## Next: Test suite updates, deployment ## Blockers: None ## Key Decisions: - Chose PostgreSQL over MySQL for JSON support - Using Drizzle ORM instead of Prisma (lighter, faster) - Migration strategy: rolling update, not big-bang ## Files Modified: - db/schema.ts (complete) - db/migrations/001-restructure.sql (complete) - routes/users.ts (in progress — lines 45-120 need update) - routes/orders.ts (not started) ## Notes: - The orders table has a circular reference — handle with care - Test user: admin@test.com / test123

הזרימה

סשן 1 — תכנון:

📚 סשן 1

/plan refactor the database layer # Claude מציע תוכנית "Save this plan to TASK-STATE.md. Include: task name, status, steps, and file list"

סשן 2 — ביצוע צעדים 1-3:

📚 סשן 2

"Read TASK-STATE.md. Execute steps 1-3. When done, update the file with progress"

סשן 3 — המשך:

📚 סשן 3

"Read TASK-STATE.md and continue from where we left off"

כל סשן מתחיל עם הקשר נקי לחלוטין — רק ה-TASK-STATE.md נטען. אין בזבוז על שחזור שיחות ישנות, אין ירידה באיכות בגלל הקשר מלא.

TASK-STATE.md — טיפים מתקדמים

קובץ מצב טוב הוא קצר וממוקד. הנה כמה כללים:

שורה אחת לכל פריט: "Completed: Schema redesign" — לא פסקה שלמה שמסבירה מה עשינו בסכמה
קבצים עם מספרי שורות: "In Progress: routes/users.ts (lines 45-120 need update)" — Claude יודע בדיוק לאן לקפוץ
Blockers מפורשים: "Blocker: circular reference in orders table — need to decide: soft delete or separate join table" — Claude מקבל הקשר לבעיה
Key Decisions עם נימוק: "Chose PostgreSQL over MySQL — JSON support needed for dynamic form data" — כדי ש-Claude לא יציע חלופה ב-Session הבא
תמיד עדכן Status: "Day 2" → "Day 3" — ככה אתה יודע כמה זמן הפרויקט לוקח

⚠ טעות נפוצה: TASK-STATE.md מנופח

מה הטעות: העתקת תכני קבצים שלמים, לוגים ארוכים, פלטי Tests מלאים, או קוד לתוך TASK-STATE.md — הקובץ מתנפח ל-200+ שורות וצורך הקשר מיותר. למה מפתה: כי אתה רוצה "שהכל יהיה שם" כדי ש-Claude לא יפספס. מה לעשות במקום: רק נתיבי קבצים עם מספרי שורות, הודעות שגיאה קצרות, והחלטות עם נימוק. 20-50 שורות מספיקות. Claude יודע לקרוא קבצים בעצמו — הוא צריך רק לדעת לאן ללכת.

שילוב עם Auto-Memory

Auto-Memory שומר תובנות בין סשנים (הגדרות שClaude למד, העדפות, דפוסים). TASK-STATE.md שומר מצב ספציפי למשימה. השילוב: Auto-Memory = "מה Claude יודע עליך". TASK-STATE.md = "מה Claude צריך לדעת על המשימה הנוכחית". שניהם נטענים בתחילת כל סשן — אחד אוטומטית, השני ידנית.

דוגמה לשילוב:

Auto-Memory שומר: "This team uses Drizzle ORM, Hebrew code comments, and deploys with Docker on Railway"
TASK-STATE.md שומר: "Task: Migrate orders table. Day 3. Completed: schema + migration. In Progress: API endpoints"

כשClaude פותח את סשן 3, הוא יודע גם איך הצוות עובד (Auto-Memory) וגם מה המצב הנוכחי של המשימה (TASK-STATE.md). שילוב מושלם.

Framework: "The Session Chain" — שרשרת הסשנים: כל סשן הוא חוליה בשרשרת. הקובץ (TASK-STATE.md) הוא השרשרת שמחברת אותן. אל תסמוך על /resume לעבודה רב-יומית — ניהול מצב מפורש (Explicit State Management) אמין יותר.

מסגרת החלטה: סשן חדש או להמשיך?

מצב	החלטה	למה
הקשר מתחת ל-50%, עובד על אותה משימה	המשך בסשן הנוכחי	יש מקום, יש הקשר — אין סיבה להתחיל מחדש
הקשר מעל 60%, עוד הרבה עבודה	`/compact` והמשך	פנה מקום תוך שמירה על תובנות
כבר 2 דחיסות, עדיין מעל 50%	שמור ל-TASK-STATE.md, סשן חדש	דחיסה שלישית תאבד יותר מדי
עובר ממשימה אחת לאחרת	סשן חדש	הקשר מהמשימה הקודמת מפריע
סוף יום עבודה, ממשיך מחר	שמור ל-TASK-STATE.md, סשן חדש מחר	`/resume` לא תמיד אמין — TASK-STATE.md כן
Claude מתחיל לטעות או לשכוח	סשן חדש מיד	סימן שההקשר "מזוהם" — התחלה נקייה עדיפה

⚡ עשה עכשיו 5 דקות

בחר פרויקט או משימה שתיקח יותר מסשן אחד (Refactoring, Feature חדש, מיגרציה). צור קובץ TASK-STATE.md בתיקיית הפרויקט עם המבנה שלמעלה: Task, Status, Completed, In Progress, Next, Blockers, Key Decisions, Files Modified, Notes. מלא את הפרטים — גם אם אתה באמצע. מהסשן הבא ואילך, התחל עם "Read TASK-STATE.md and continue."

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

בינוני 10 דקות ~$0.10 מעשי

Claude Code מטפל בעברית מצוין — אבל יש דפוסים שמשפרים את האיכות בצורה משמעותית. הנדסת פרומפטים דו-לשונית (Bilingual Prompt Engineering) היא כישרון ייחודי של משתמשים ישראלים.

הטכניקה הדו-לשונית

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

📚 דוגמה — Bilingual Prompting

"אנחנו בונים מערכת CRM לסוכנויות נדל״ן בישראל. הלקוחות מחפשים דירות בתל אביב וירושלים. Write the database schema for properties and leads. Use PostgreSQL. Column names in English, comments in Hebrew."

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

תבנית ליצירת תוכן בעברית

כשאתה צריך מ-Claude לייצר תוכן בעברית (בלוגים, מסמכים, מיילים), השתמש בתבנית הזו:

📚 תבנית תוכן עברי

כתוב [סוג תוכן] בנושא [נושא]. השתמש ב-[סגנון] (למשל: שפה מקצועית אבל נגישה). מונחים טכניים באנגלית: [רשימת מונחים] (למשל: CRM, Lead Scoring, Pipeline). אורך: [מספר מילים]. קהל יעד: [תיאור] (למשל: מנהלי שיווק בחברות B2B בישראל).

Back-Translation Quality Check — בדיקת איכות בחזרה

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

Claude מייצר תוכן בעברית
אתה מבקש: "Now translate this back to English"
משווה: אם התרגום חזרה לאנגלית מעביר את אותו המסר — העברית טובה
אם התרגום חזרה שונה מהכוונה המקורית — העברית צריכה שיפור

📚 דוגמה — Back-Translation

בקשה: "כתוב כותרת לדף נחיתה של כלי ניהול פרויקטים"
Claude כותב: "נהל את הפרויקטים שלך בקלות — הכל במקום אחד"
תרגום חזרה: "Manage your projects easily — everything in one place"
הערכה: התרגום מעביר את המסר. העברית תקינה.

RTL ועריכת קבצים בעברית

Claude Code מטפל ב-RTL (Right-to-Left) נכון כשעורך קבצי HTML/Markdown. אבל הטרמינל עצמו לא תמיד מציג עברית כמו שצריך. כמה טיפים:

השתמש ב-UTF-8 Encoding תמיד — בקבצים ובטרמינל
אמת תוכן עברי ב-עורך טקסט אמיתי (VS Code, Sublime) — לא בטרמינל
ב-HTML: תמיד הוסף dir="rtl" ו-lang="he"

Hebrew SEO Patterns

ל-SEO בעברית, השתמש בדפוס הזה:

אלמנט	שפה	דוגמה
H1 (כותרת ראשית)	עברית — מילת מפתח ראשית	"ניהול פרויקטים — הפתרון המלא לצוותים"
H2/H3 (כותרות משנה)	עברית + מונחים טכניים באנגלית	"איך Kanban Board משפר את הפרודוקטיביות"
Meta Description	עברית	"כלי ניהול פרויקטים לצוותים בישראל. 14 ימי ניסיון חינם."
Alt Text (תמונות)	עברית	"לוח Kanban עם משימות פרויקט"

דוגמאות מייצגות — Bilingual Prompting בפעולה

תרחיש 1: סוכנות שיווק דיגיטלית

צוות של 3 משווקים בסוכנות ישראלית כותב תוכן לאתרים של לקוחות. הם משתמשים ב-Claude Code עם Skill בשם /write-landing-he:

📚 Bilingual Prompt — Landing Page

הלקוח: חברת FinTech ישראלית שמוכרת כלי ניהול תקציב למשפחות. קהל יעד: הורים בגילאי 30-45 שרוצים לנהל את הוצאות המשפחה בצורה חכמה. טון: חם, מקצועי, אבל לא "בנקאי" — כמו חבר שמבין בכסף. Write a landing page with: hero headline + subheadline, 3 feature sections with icons, social proof section with 3 testimonials, and CTA. All in Hebrew. Technical terms that stay in English: Budget Tracking, Cash Flow, Push Notifications. Currency: ILS (₪). Include specific numbers: ₪450/month average savings.

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

תרחיש 2: מפתח בסטארטאפ

📚 Bilingual Prompt — Code + Docs

אנחנו סטארטאפ EdTech. הAPI שלנו מנהל קורסים, תלמידים, ומטלות. הלקוחות שלנו מורים ותלמידים בישראל — כל הUI בעברית. Generate the API documentation for the /courses endpoint. Write descriptions in Hebrew. Code examples in English. Parameter names in English, descriptions in Hebrew. Include error responses with Hebrew error messages for user-facing errors.

הערות קוד בעברית

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

📚 הגדרה ב-CLAUDE.md

Code comments should be in Hebrew. Variable names and function names remain in English. JSDoc descriptions: Hebrew. Parameter names: English.

💡 הכלי הטוב ביותר לעברית

לאיכות העברית הכי טובה, השתמש ב-Opus ברמת Effort גבוהה. Sonnet מייצר עברית טובה, אבל Opus מצטיין בניואנסים, ביטויים, וניסוח טבעי. אם התוכן הוא Customer-Facing (מגיע ללקוחות) — שווה את העלות הנוספת.

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

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

מודל	איכות עברית	מתי להשתמש	עלות יחסית
Opus 4.6	מעולה — ניואנסים, ביטויים, טון טבעי	תוכן Customer-Facing, שיווק, תיעוד	הכי יקר
Sonnet 4.6	טובה — ברורה, נכונה, לפעמים "יבשה"	הערות קוד, תיעוד פנימי, מיילים	בינונית

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

טעויות נפוצות בפרומפטים בעברית

טעות	תוצאה	פתרון
לכתוב הוראות טכניות בעברית	Claude מפרש לא נכון — "קרא את הקובץ" vs "Read the file"	הוראות טכניות באנגלית, הקשר עסקי בעברית
לא לציין אורך לתוכן	Claude כותב 200 מילים או 2,000 — לא צפוי	תמיד ציין אורך: "800-1000 מילים"
לא להגדיר מונחים שנשארים באנגלית	Claude מתרגם הכל — "ניהול צפוי תפוקה" במקום "Pipeline Management"	רשום מפורשות: "Technical terms in English: Pipeline, Sprint, Dashboard"
לבקש "עברית פורמלית"	Claude כותב בסגנון אקדמי/משפטי — מנוכר	ציין טון: "כמו שיחה עם קולגה מקצועי" או "חם אבל מקצועי"

⚡ עשה עכשיו 5 דקות

בקש מ-Claude Code ליצור תוכן בעברית באמצעות התבנית הדו-לשונית. למשל: "אנחנו חברת SaaS ישראלית שמוכרת כלי ניהול משימות. Write a landing page headline, subheadline, and 3 feature bullets in Hebrew. Technical terms like 'Sprint', 'Burndown Chart', 'Backlog' stay in English." קרא את התוצאה ובצע Back-Translation כדי לבדוק איכות.

ספריית תבניות פרומפט מתקדמות

בינוני 15 דקות חינם מעשי

Power Users לא כותבים כל פרומפט מאפס. הם בונים ספריית תבניות — מבנים מוכחים שעובדים שוב ושוב. הנה 5 תבניות מתקדמות שאפשר לשמור כ-Skills ב-.claude/commands/:

1. The Refactoring Prompt — תבנית רפקטורינג

📚 תבנית

Refactor [module] with these goals: 1) [goal1 — e.g., reduce complexity] 2) [goal2 — e.g., improve testability] Constraints: - Don't break existing tests - Maintain backward compatibility - Keep changes minimal Plan first, then execute step by step. After each step, confirm before continuing.

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

2. The Debugging Prompt — תבנית דיבאג

📚 תבנית

Bug: [description — what went wrong] Expected: [what should happen] Actual: [what actually happens] Error: [error message if any] Files involved: [list of relevant files] Reproduce with: [steps to reproduce] Find the root cause and fix it. Ultrathink.

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

3. The Code Review Prompt — תבנית ביקורת קוד

📚 תבנית

Review [file/changes] for: - Security vulnerabilities (OWASP top 10) - Performance issues (N+1 queries, unnecessary re-renders, memory leaks) - Code quality (DRY, single responsibility, error handling) Format: table with columns: File, Line, Issue, Severity (Low/Medium/High/Critical), Suggested Fix

למה זה עובד: קריטריונים ספציפיים (לא "בדוק את הקוד") + פורמט פלט מוגדר (טבלה) = תוצאה עקבית ומובנית בכל הפעלה.

4. The Content Generation Prompt — תבנית יצירת תוכן

📚 תבנית

Create [content type] about [topic]. Audience: [who — e.g., CTOs at Israeli startups] Tone: [style — e.g., professional but conversational] Length: [words — e.g., 800-1000] Must include: [requirements — e.g., 3 real examples, 1 CTA] Must avoid: [restrictions — e.g., no jargon, no cliches] Format: [output structure — e.g., H2 sections, bullet points, summary]

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

5. The Architecture Analysis Prompt — תבנית ניתוח ארכיטקטורה

📚 תבנית

Analyze the architecture of [module/project]. Map: 1. Data flow (from input to output) 2. Dependencies (internal and external) 3. External integrations (APIs, databases, services) 4. Failure points (what can go wrong) Recommend improvements. For each recommendation: - Effort: Low / Medium / High - Impact: Low / Medium / High - Priority: Effort vs Impact score

למה זה עובד: מבנה מדויק = ניתוח מקיף. Effort/Impact Scoring מאפשר לדרג המלצות ולבחור מה לבצע קודם.

מתבנית ל-Skill — הפיכת תבנית לפקודה קבועה

כשתבנית מוכחת — שמור אותה כ-Skill ב-.claude/commands/. הנה דוגמה מלאה של תבנית Debug שהופכת ל-Skill:

📚 מתבנית ל-Skill — /debug-deep

# .claude/commands/debug-deep.md --- name: debug-deep description: Deep debugging with structured analysis and root cause identification effort: high fork: true --- # Deep Debug Analysis The user will describe a bug. Analyze it using this structure: ## 1. Reproduce - Identify the steps to reproduce from the user's description - Run the relevant tests or commands to confirm the bug exists ## 2. Isolate - Find the exact file and line where the bug manifests - Trace backwards to find the root cause (not just the symptom) ## 3. Analyze - Why does this bug exist? Was it a logic error, edge case, or race condition? - What other code paths might have the same issue? ## 4. Fix - Propose a fix. Show the exact code change - Explain why this fix is correct and won't cause regressions ## 5. Prevent - Suggest a test that would have caught this bug - Suggest a linting rule or hook that would prevent similar bugs Format: structured markdown with code blocks. Ultrathink.

מהרגע שה-Skill הזה קיים, כל Debug בפרויקט מתבצע באותו מבנה מוכח. לא צריך לזכור את התבנית — פשוט מפעילים /debug-deep ומתארים את הבאג.

ארגון ספריית תבניות

כשיש לך 5+ תבניות, ארגן אותן בתיקיות משנה:

📚 מבנה תיקייה מומלץ

.claude/commands/ debug/ debug-deep.md debug-performance.md review/ review-security.md review-quality.md content/ write-blog-he.md write-docs.md deploy/ deploy-staging.md deploy-production.md

הפקודות נקראות לפי המבנה: /debug-deep, /review-security, /write-blog-he. ארגון בתיקיות עוזר לנווט כשיש 10+ Skills, ומקל על צוות חדש שמצטרף לפרויקט.

⚡ עשה עכשיו 5 דקות

בחר תבנית אחת מהתבניות למעלה (Debug, Review, Content, Refactoring, או Architecture). התאם אותה לעבודה שלך — שנה את הקריטריונים, הוסף דרישות ספציפיות לפרויקט שלך, הוסף YAML Frontmatter. שמור כ-.claude/commands/[name].md. הפעל פעם אחת ובדוק שעובד.

Frameworks להחלטות — Prompting & Context

5 דקות תיאוריה

לאורך הפרק פגשת 6 Frameworks להחלטות. הנה סיכום מהיר שאפשר לחזור אליו בכל יום:

Framework	סעיף	מתי להשתמש	הכלל המרכזי
The Compact Strategy	9.3	כשצריך להחליט אם/מתי לדחוס	ב-60% — דחוס ידנית. ב-80% — כבר מאוחר
Context as a Resource	9.4	ניהול צריכת הקשר	הקשר = RAM. קבצים = דיסק. /compact = GC
Effort-Cost Mapping	9.5	בחירת רמת Effort למשימה	Low למכני, Medium לרוב, High לקריטי
Think or Skip	9.6	האם להפעיל חשיבה מורחבת	אם טעות יקרה — חשוב. אם מכני — דלג
New Session or Continue?	9.8	האם לפתוח סשן חדש	2 דחיסות = סשן חדש. טעויות = סשן חדש
The Context Flow	9.11	מבנה כל סשן עבודה	Setup → Work → Maintain → Close

כל Framework מכסה החלטה אחת שחוזרת שוב ושוב. כשעובדים עם Claude Code באופן יום-יומי, ה-Frameworks האלה הופכים לרפלקסים — כמו שמפתח לא חושב "האם לעשות git commit" אלא פשוט עושה, גם אתה לא תחשוב "האם להתחיל ב-Plan Mode" — פשוט תתחיל.

🔧 תרגיל 1 — בנה את ספריית התבניות שלך

צור תיקייה .claude/commands/templates/
בחר 5 משימות שאתה מבצע באופן קבוע (Debug, Review, Deploy, Content, Analysis)
לכל משימה, כתוב קובץ Skill (.md) שמבוסס על אחת מהתבניות למעלה — או תבנית חדשה שאתה מעצב
לכל Skill, הגדר YAML Frontmatter עם: name, description, effort, ו-fork
הפעל כל Skill לפחות פעם אחת ובדוק: האם התוצאה עקבית? האם חסר משהו? שפר בהתאם (Hot Reload)

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

Context Mastery — טכניקות מומחה

מתקדם 15 דקות ~$0.10-0.30 מעשי

הסעיף הזה הוא הרמה הכי גבוהה של ניהול הקשר — הטכניקות שמפרידות בין משתמש טוב למומחה. אם סעיף 4 (Context Window Optimization) הוא "נהיגה יעילה", הסעיף הזה הוא "מירוצי Formula 1."

1. Context Pre-loading — טעינה מקדימה

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

📚 דוגמה — Pre-loading

"Read auth.py, user_model.py, and api/routes/auth.js. I'll explain the task after you've seen the code." # Claude קורא את 3 הקבצים "Good. Now here's the task: the JWT expiration check fails for users in UTC+2 timezone..."

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

2. Context Partitioning — חלוקת הקשר לשלבים

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

שלב	מה קורה	עלות הקשר
Phase 1: Exploration	Claude קורא, חוקר, מבין. שואל שאלות. בונה "מפה מנטלית"	גבוהה (הרבה קריאת קבצים)
Phase 2: Compact	`/compact` — שמור רק תובנות, לא פרטי קבצים	שלילית (משחרר)
Phase 3: Execute	ביצוע עם הקשר נקי + הבנה מזוקקת	נמוכה יותר (ממוקד)

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

3. Selective Context — הקשר סלקטיבי

במקום "read the entire project," ספר ל-Claude בדיוק מה לקרוא:

📚 דוגמה — Selective Context

גרוע: "Understand our project structure and find the bug" → Claude קורא 20 קבצים, צורך 40K טוקנים, ומחפש מחט בערימת שחת מעולה: "Read only the test files in tests/auth/. Don't read the implementation yet." → Claude קורא 3 קבצים, צורך 3K טוקנים, ומבין בדיוק מה צפוי להתנהג "Now read only auth/middleware.js lines 40-80. The bug is in the token validation." → Claude קורא 40 שורות, צורך 100 טוקנים, ומצליב עם בדיקות

4. Context Recycling — מחזור הקשר

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

⚠ חוק 80% — כלל ברזל

כש-/context מראה 80% שימוש, חובה לעשות Compact או לפתח סשן חדש. מעל 80%, Auto-Compaction נכנס ומוחק אגרסיבית — אתה מאבד שליטה על מה שנשמר ומה שנמחק. איכות התשובות יורדת משמעותית. אל תגיע ל-80%.

5. /fork for Safe Experiments — ניסויים בטוחים

הפקודה /fork מעתיקה את השיחה הנוכחית ל"ענף" נפרד. המקור נשאר ללא שינוי. זה כלי עוצמתי ל-Context Mastery כי הוא מאפשר לנסות גישה מסוכנת בלי לסכן את ההקשר הנוכחי:

📚 דוגמה — /fork לניסוי

# הגעת לנקודה שבה יש 2 גישות אפשריות /fork # בענף: "Try approach A — rewrite the module with async/await" # אם עובד — מעולה. אם לא — חזור לשיחה המקורית # ההקשר בשיחה המקורית נקי ולא הושפע מהניסוי

למה זה שייך ל-Context Mastery? כי ניסוי שנכשל צורך הקשר. אם עשית 5 תורות של ניסוי ולא הצליח — איבדת 5-10K טוקנים. עם /fork, הניסוי קרה ב"עולם מקביל" — ההקשר המקורי נשאר נקי.

6. Proactive Context Management — ניהול הקשר פרואקטיבי

במקום להגיב לבעיות הקשר, תכנן מראש:

לפני משימה ארוכה: בדוק /context. אם כבר ב-40%+ — עשה Compact לפני שמתחיל
לפני קריאת קובץ גדול: שאל את עצמך — האם באמת צריך את כל הקובץ? או רק 20 שורות?
אחרי כל שלב מרכזי: בדוק /context. אם קפצו 15%+ — שקול Compact
אם Compact כבר נעשה פעמיים: שמור מצב ל-TASK-STATE.md ופתח סשן חדש

דוגמה מייצגת — סשן מנוהל לעומת לא-מנוהל

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

מפתח א' — לא מנהל הקשר:

תור 1: "Read all files in src/auth/" — 15K טוקנים (7.5% מ-200K)
תור 5: "Also read the test files" — 8K טוקנים נוספים
תור 10: "Now read the database models" — 6K נוספים
תור 15: "Why are you making mistakes?" — הקשר ב-65%, Claude מתחיל לשכוח
תור 20: Auto-Compaction — פרטים חשובים נמחקים. Claude שואל שאלות שכבר ענו עליהן
תור 25: מפתח מוותר ופותח סשן חדש. עלות: $3.80, תוצאה: חלקית

מפתח ב' — מנהל הקשר:

תור 1: /plan refactor auth module — תוכנית (Plan Mode מנקה הקשר)
תור 2: "Read auth/middleware.js lines 30-90" — 120 טוקנים (Selective)
תור 3: "Grep validateToken — files only" — 50 טוקנים (Breadcrumb)
תור 4: "Fix the JWT validation" — 500 טוקנים (Focused)
בדיקת /context: 18%. הרבה מקום לעוד
תור 5-8: המשך עבודה בהקשר נקי. סיום ב-35% הקשר
עלות: $1.10, תוצאה: מלאה ואיכותית

ההבדל: פי 3.5 פחות עלות, תוצאה טובה יותר, סשן קצר יותר. זה Context Mastery.

7. Voice Mode ופרומפטים מדוברים

החל ממרץ 2026, /voice מאפשר Push-to-Talk — לחיצה ממושכת על Spacebar, דיבור, ושחרור כדי לשלוח. נתמכות 20 שפות, כולל עברית. Voice Mode משנה את דפוסי הפרומפט בכמה דרכים:

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

💡 Voice + Effort = שילוב עוצמתי

Voice Mode מייצר פרומפטים ארוכים וטבעיים. אם אתה ב-/effort high, Claude ישקיע חשיבה מעמיקה בפרומפט המדובר. אבל אם הפרומפט הוא "rename this variable" — החלף ל-/effort low לפני שמדבר. Voice + High Effort על משימה פשוטה = בזבוז כפול.

8. /loop — פרומפטים חוזרים

הפקודה /loop (מרץ 2026) מאפשרת להריץ פרומפט במרווחי זמן קבועים — סוג של cron בתוך הסשן:

📚 דוגמה — /loop

/loop 5m check the build status and notify me if it fails /loop 15m run the test suite and report failures /loop 1h check for new PRs and summarize them

מבחינת Context Mastery, /loop צורך הקשר בכל ריצה. לכן:

שמור את הפרומפט קצר — כל ריצה של /loop מוסיפה לצריכת ההקשר
השתמש ב-/effort low לפני הפעלת /loop — אין צורך בחשיבה מעמיקה לבדיקות שגרתיות
ב-/loop ארוך (שעות), שים לב ל-/context — הצטברות של 12 ריצות כל 5 דקות יכולה לצרוך 10%+ מההקשר

מסגרת החלטה: זרימת הקשר (The Context Flow)

לכל סשן 4 שלבים: (1) Setup — בדוק /context, טען את ה-TASK-STATE.md, וודא שה-Effort מותאם. (2) Work — עבוד עם Selective Read, Breadcrumb, ו-Funnel. (3) Maintain — ב-60% עשה /compact עם הוראות מותאמות. (4) Close — עדכן TASK-STATE.md, בדוק עלות סופית, סגור את הסשן.

תרגילים מעשיים

מעשי 60 דקות סה"כ

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

🔧 תרגיל 2 — Context Partitioning בפועל

בחר בעיה אמיתית בפרויקט שלך (באג, רפקטורינג, או Feature)
Phase 1 (Exploration): בקש מ-Claude לחקור — "Explore the [module]. Read the key files. Summarize what you find."
בדוק /context — כמה אחוזים צרך שלב החקירה?
Phase 2 (Compact): /compact keep the insights and file structure. Drop the file contents.
בדוק /context שוב — כמה שוחרר?
Phase 3 (Execute): "Now implement the fix based on your understanding."
השווה: האם ה-Fix טוב יותר מאשר לו היית מבקש הכל בתור אחד?

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

🔧 תרגיל 3 — Session Chaining לפרויקט רב-יומי

בחר פרויקט שייקח 3+ סשנים (רפקטורינג מודול, מיגרציה של DB, או Feature מורכב)
בסשן 1: השתמש ב-/plan ליצירת תוכנית מפורטת. שמור ל-TASK-STATE.md
בסשן 2: "Read TASK-STATE.md. Execute steps 1-3." אחרי ביצוע — עדכן את הקובץ
בסשן 3: "Read TASK-STATE.md. Continue from where we left off."
בסוף כל סשן, בדוק: האם ה-TASK-STATE.md מספיק מפורט כדי להמשיך? מה חסר? עדכן

תוצאה צפויה: פרויקט שלם שבוצע על פני 3+ סשנים, עם קובץ מצב שתיעד כל שלב. ראייה של ההבדל בין עבודה מסודרת (עם TASK-STATE.md) לעבודה מאולתרת.

🔧 תרגיל 4 — Hebrew Content Pipeline

צור Skill בשם /write-he ב-.claude/commands/write-he.md
הגדר: name: write-he, description: Generate Hebrew content with English technical terms, model: opus, effort: high
בגוף ה-Skill, שלב את תבנית התוכן העברי מסעיף 9.9 — עם Placeholders לסוג תוכן, נושא, קהל, אורך
הפעל /write-he עם נושא אמיתי מהעבודה שלך
בצע Back-Translation Quality Check על התוצאה
אם האיכות לא מספקת — שפר את ההוראות ב-Skill ונסה שוב (Hot Reload)

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

שגרת עבודה — Prompting & Context

5 דקות

שגרת עבודה — Prompting & Context

בנוסף לשגרות מפרקים קודמים (פרק 7: בדיקת Auto-Memory, פרק 8: ביקורת אבטחה שבועית), הוסף את הפעולות הבאות:

יומי

בתחילת כל סשן: בדוק /context ושים לב כמה תפוס לפני שמתחיל
התאם /effort למשימה: Low לעריכות מהירות, Medium לרוב העבודה, High למורכבות
השתמש בדפוסי שיחה (Funnel, Iteration, Checkpoint) במקום פרומפטים ארוכים חד-פעמיים
עשה /compact ידני כשההקשר מגיע ל-60% — לא לחכות ל-Auto-Compaction
עדכן TASK-STATE.md בסוף כל סשן עבודה על פרויקט רב-יומי

שבועי

בדוק את ספריית ה-Prompt Templates — האם יש משימות חוזרות שאפשר להוסיף כ-Skill?
עבור על compactInstructions ב-CLAUDE.md — האם יש דברים חדשים שצריך לשמור בדחיסה?
השווה עלויות: סמן סשנים שצרכו הרבה טוקנים וחשוב — איפה אפשר להיות יותר חסכוני?
שתף תבנית פרומפט מוצלחת עם הצוות

חודשי

בדוק אם רמות Effort שהגדרת ב-Skills עדיין מתאימות — אולי Skill שהיה High יכול להיות Medium?
נקה קבצי TASK-STATE.md ישנים — מחק פרויקטים שהסתיימו
בצע ביקורת על ה-CLAUDE.md: האם ה-Compact Instructions עדיין רלוונטיים? יותר מדי או חסרים?
חשוב על ROI: כמה זמן ועלות חסכת השדרגות הפרומפטים? מה עוד אפשר לשפר?
בדוק Context Usage ממוצע — האם שיפרת לעומת החודש הקודם?

60%

מהמשתמשים המתקדמים שמיישמים את הטכניקות מהפרק הזה מדווחים על ירידה של לפחות 40% בעלויות טוקנים, עם שיפור באיכות התוצאות. חיסכון ממוצע: $15-30 בחודש למשתמש יחיד, $80-200 בחודש לצוות של 5 מפתחים. (דוגמאות מייצגות, מרץ 2026)

⚡ עשה עכשיו — בדיקה סופית 3 דקות

חזור למספר שרשמת בתחילת הפרק — אחוז ההקשר הראשוני מ-/context. עכשיו: (1) הגדרת compactInstructions ב-CLAUDE.md? (2) יש לך לפחות 3 Prompt Templates כ-Skills? (3) יש לך TASK-STATE.md לפרויקט מתמשך? (4) יש לך הרגל של /plan לפני משימות גדולות? אם ענית "כן" על 3 מתוך 4 — אתה מיישם את הפרק הזה. אם פחות — חזור על הסעיפים הרלוונטיים ויישם.

אם אתה עושה רק דבר אחד

⭐ רק דבר אחד — Just One Thing

אם יש דבר אחד לקחת מהפרק הזה, זה זה: התחל כל משימה משמעותית עם /plan. לא "אולי", לא "כשנוח" — תמיד. ה-$0.10 שמושקע בתכנון חוסך $0.50-2.00 בביצוע, מייצר תוצאה טובה יותר, ומשאיר יותר הקשר פנוי לביצוע עצמו. Plan Mode הוא ההרגל היחיד שמשנה את הכל — כי הוא גורם ל-Claude לחשוב לפני שהוא עושה, בדיוק כמו שאתה עושה.

בדוק את עצמך — Check Yourself

5 דקות

בדוק את עצמך — 5 שאלות

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

למה Plan Mode חוסך 25-45% מצריכת ההקשר? (רמז: מה קורה לשלב החקירה כשמאשרים תוכנית?)
תשובה: כשמאשרים תוכנית, כל שלב החקירה נמחק — Claude מתחיל מחדש עם התוכנית בלבד.
איך חוק ה-60% מונע אובדן מידע — ומה קורה אם מחכים ל-80%? (רמז: Auto-Compaction)
תשובה: ב-60% עושים compact ידני ושולטים במה שנשמר. ב-80% Auto-Compaction מופעל ומוחק אגרסיבית — אובדן שליטה על מה נמחק.
מתי Effort High עדיף למרות שהוא יקר פי 8 מ-Low — ומתי זה בזבוז? (רמז: חשוב על סוג המשימה)
תשובה: High עדיף לביקורת אבטחה, Debug מורכב, החלטות ארכיטקטורה — שגיאה עולה יותר מהחיסכון. בזבוז: שינוי שם משתנה, פורמט קוד — פעולות מכניות.
למה Breadcrumb Pattern חוסך 99%+ טוקנים לעומת "Read the entire project"? (רמז: מבנה לפני תוכן)
תשובה: בונים "מפה מנטלית" בכמה מאות טוקנים: קודם רשימת תיקיות, אח"כ תיקייה ספציפית, אח"כ שורות ספציפיות — במקום לקרוא הכל.
איך TASK-STATE.md ו-Auto-Memory משלימים אחד את השני? (רמז: סוג המידע שכל אחד שומר)
תשובה: Auto-Memory = מה Claude יודע עליך (העדפות, דפוסים, Tech Stack). TASK-STATE.md = מצב ספציפי של משימה (מה נעשה, מה בעבודה, מה הלאה). שניהם נטענים בתחילת סשן.

סיכום הפרק

סיכום — פרק 9: Advanced Prompting and Context Mastery

הפרק הזה חשף את הרובד העמוק ביותר של העבודה עם Claude Code: לא מה הכלי יכול לעשות, אלא איך לגרום לו לעשות את זה בצורה הטובה ביותר. התובנה המרכזית היא שהקשר (Context) הוא משאב מוגבל בדיוק כמו RAM — ומי שמנהל אותו חכם (Plan Mode, חוק ה-60%, Breadcrumb Pattern, Effort מותאם) מפיק פי 3 יותר מאותו כלי באותו תקציב. שרשור סשנים עם TASK-STATE.md הפך פרויקטים רב-יומיים ממאבק בשכחה לזרימה חלקה, ו-5 דפוסי השיחה (Funnel, Iteration, Expert Panel, Checkpoint, Breadcrumb) נתנו לך ארגז כלים תקשורתי מלא.

בפרק הבא נעבור ל-פרק 10: Building Your Personal Toolkit — שם תחבר את כל 9 הפרקים הקודמים למערכת עבודה שלמה, מתועדת, ובבקרת גרסאות. מרכיבים בודדים הופכים לארכיטקטורה.

צ'קליסט — האם סיימת את הפרק?

אני מבין איך Plan Mode חוסך הקשר ויודע להפעיל אותו עם Shift+Tab או /plan
ביצעתי Plan Review לפחות פעם אחת (ביקורת עצמית של תוכנית)
הגדרתי compactInstructions ב-CLAUDE.md שלי
אני יודע לעשות /compact עם הוראות מותאמות ומבין את חוק ה-60%
אני מבין מה צורך טוקנים בחלון ההקשר ויודע איך לחסוך (Read ממוקד, Grep חסכוני)
אני יודע להשתמש ב-/effort ולהחליף רמות באמצע סשן
אני מבין מתי Extended Thinking עוזרת ומתי היא בזבוז
יישמתי לפחות 2 מתוך 5 דפוסי שיחה (Funnel, Iteration, Expert Panel, Checkpoint, Breadcrumb)
יצרתי TASK-STATE.md לפרויקט רב-יומי
ניסיתי Bilingual Prompting (עברית + אנגלית) ובדקתי עם Back-Translation
בניתי ספריית Prompt Templates — לפחות 3 תבניות כ-Skills
ביצעתי Context Partitioning (Explore → Compact → Execute) לפחות פעם אחת
אני בודק /context באופן שוטף ומונע הגעה ל-80%
ביצעתי לפחות 2 תרגילים מתוך 4