📘 תיעוד 12

שיטות עבודה מומלצות ל-Claude Code

להפיק יותר מ-Claude Code: ספר לקלוד מה הוא לא יכול לראות, תן לו בדיקה להריץ, ואכוף את הכללים שלא יכולים להיות להם חריגים.

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

לדוגמה:

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

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

• תהליך פריסה שחי בראש של מישהו
• קובץ שאסור לקרוא אותו אף פעם
• בדיקה שחייבת לעבור לפני שמשהו נחשב גמור
• תקציב שאתה צריך להישאר מתחתיו

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

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

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

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

[!NOTE]

הגדרה לצוות שלם נמצאת בדף נפרד: הגדר את Claude Code לארגון שלך.

#הוראות דטרמיניסטיות ולא דטרמיניסטיות

כל הוראה שאתה נותן ל-Claude Code היא אחת מאלה:

1. לא דטרמיניסטי: אתה כותב את ההוראה, וקלוד (המודל) קורא אותה. זה יכול להיות ההנחיה שלך, CLAUDE.md, או skill. המודל מחליט אחר כך מה לעשות עם המידע הזה. בדרך כלל הוא ממלא אחרי הפקודות שלך, והמודלים הנוכחיים טובים בהבנת הכוונה שלך בלי הרבה הקשר, אבל אין ערובה שהוא ימלא אחרי ההוראות שלך. הוא עדיין יכול להחליט לא לעשות דברים, או לעשות דברים אחרים.
2. דטרמיניסטי: אתה מגדיר את ההוראה, ו-Claude Code (ה-harness) חייב לבצע אותה. זה יכול להיות hook, כלל deny, או הגדרה מנוהלת. Claude Code מיישם את זה בכל פעם, לא משנה מה המודל החליט לעשות.

רוב הדברים ב-Claude Code מגיעים בשתי הצורות:

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

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

• אף פעם לא לערוך את הלקוח שנוצר ב-src/gen/
• תמיד להריץ את סקריפט כותרת הרישיון אחרי יצירת קובץ

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

[!TIP]

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

#ספר לקלוד מה הוא לא יכול לראות

[!TIP]

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

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

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

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

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

מבחן טוב לפני שאתה כותב משהו לקלוד:

1. האם הוא יכול למצוא את זה מקריאת הקוד?
2. האם הוא באמת ילך לחפש?

אם התשובה לשניהם היא כן, השאר את זה בחוץ.

#כתוב הנחיה ספציפית

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

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

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

• קובץ: הקלד @ ואת הנתיב כדי לכלול את תוכן הקובץ בהודעה שלך.
• תמונה: הדבק את צילום המסך של העיצוב או של השגיאה לתוך ההנחיה.
• פלט פקודה: העבר אותו בצינור מהמעטפת עם cat error.log | claude -p "what's going on here".

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

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

build the settings page from the mockup. be ambitious: empty and error states, the save flow wired up, keyboard navigation, not just the layout

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

וכשאתה חוקר ולא מתקן משהו ספציפי, הנחיה מעורפלת כמו what would you improve in this file? לגמרי בסדר. תתקן קצת יותר תוך כדי, וזה הוויתור.

#סיעור מוחות עם קלוד קודם

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

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

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

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

#שמור את CLAUDE.md קצר

Claude Code טוען את CLAUDE.md לכל סשן, וזה אומר שכל שורה בו לוקחת קצת מתשומת הלב של קלוד בכל משימה, בין שהיא רלוונטית ובין שלא. לכן הקובץ עובד הכי טוב כשהוא מחזיק רק את מה שקלוד לא יכול להסיק מהקוד עצמו:

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

CLAUDE.md שעובר את המבחן הזה נשאר קצר:

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit

# Conventions
- Use the error helpers in src/lib/errors.ts, never throw raw strings
- src/legacy/ is still live but don't copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example

בסשן, הרץ /context all כדי לאשר שקלוד טען את הקובץ.

שים לב ששורת ה-typecheck היא רק הפקודה. קלוד צריך לדעת את הפקודה כדי שיוכל לבדוק את העבודה שלו תוך כדי. אם אתה גם רוצה ש-Claude Code יאכוף typecheck שעובר לפני שקלוד מסיים, זו עבודה ל-hook מסוג Stop. שורה כמו Always typecheck before you finish בקובץ הזה עובדת ברוב הזמן, לא בכל פעם.

אתה לא חייב לכתוב את הקובץ מאפס:

• /init מייצר גרסת התחלה מבסיס הקוד שלך. משם העבודה היא בעיקר הסרת שורות. מדריך הזיכרון ממליץ להישאר מתחת ל-200.
• /doctor מציע קיצוצים לכל דבר שקלוד יכול כבר להסיק מהקוד.
• /doctor prompt-audit מסמן הוראות שנכתבו למודלים ישנים יותר, מצביע על קבצים שכבר לא קיימים, או סותרות זו את זו.

ההעדפות האישיות שלך הולכות ל-CLAUDE.local.md במקום ל-CLAUDE.md, ואתה מוסיף את הקובץ הזה ל-.gitignore כדי שהוא יישאר מחוץ לריפו.

[!NOTE]

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

#תחם כללים לחלק אחד של בסיס הקוד

אם כלל חשוב רק בחלק אחד של בסיס הקוד, שים אותו ב-.claude/rules/ עם מסנן paths: כדי שהוא ייטען רק כשקלוד באמת עובד שם. לדוגמה, .claude/rules/api.md הזה נטען לקובצי TypeScript תחת src/api/:

---
paths:
  - "src/api/**/*.ts"
---
- Validate request bodies with the zod schemas in src/api/schemas/, don't hand-roll checks
- Every new endpoint needs an entry in openapi.yaml, CI fails without it

#שים נהלי צוות ב-skills

מודל מסוגל יותר יודע יותר על הנדסה, אבל לא איך הצוות שלך עושה שחרור גרסה, מה אומר ספר התפעול לתקריות שלך, או איך אתה רוצה שתיעוד API ייכתב. ידע מהסוג הזה הולך ל-skill: הליך או פיסת ידע צוותי שנשמרים ב-.claude/skills/<name>/SKILL.md.

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

[!NOTE]

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

להליך עם תופעות לוואי, כמו באמת לחתוך את השחרור הזה, הוסף disable-model-invocation: true. אז קלוד לא יכול להתחיל את ה-skill בעצמו, והוא רץ רק כשאתה מקליד /release בעצמך. כשהוא נשמר כ-.claude/skills/release/SKILL.md, הוא יכול להיראות כך:

---
name: release
description: Cut a new release. Bumps the version, writes the changelog entry, tags it and pushes the tag so CI can publish.
disable-model-invocation: true
---
1. Make sure you're on main with a clean tree. If not, stop and ask.
2. Run `pnpm changeset version` and commit the result.
3. Summarize the PRs merged since the last tag into CHANGELOG.md, one line each, user-facing changes only.
4. Tag `v<new version>` and push the tag. CI publishes from there, never publish from your machine.

#חבר את הכלים שקלוד צריך

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

למערכות בלי CLI, יש MCP. אתה מוסיף שרת מהמעטפת:

claude mcp add --transport http notion https://mcp.notion.com/mcp

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

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

#תן לקלוד בדיקה להריץ

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

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

טיפ

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

הבדיקה יכולה להיות כמעט כל דבר, כל עוד קלוד יכול לקרוא את התוצאה:

• קובץ בדיקות
• קוד היציאה של בנייה
• לינטר
• סקריפט שמשווה פלט מול fixture
• צילום מסך של הדפדפן ליד המוקאפ

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

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

• בפרומפט: run the auth tests after, and keep going until they pass. קלוד מחליט בעצמו מתי הוא מרוצה. זה עובד לכל משימה, היום, בלי הגדרה.
• כיעד: /goal all tests in tests/auth pass and lint is clean קובע תנאי שמודל נפרד בודק מול השיחה אחרי כל תור, וקלוד ממשיך עד שהתנאי מתקיים. בתוך הסשן אתה עצמך כמעט לא צריך את זה. זה חשוב לריצות רקע ארוכות, שבהן קלוד לפעמים מסיים תור עם סיכום התקדמות בזמן שפריטים עדיין פתוחים, והיעד שולח אותו בחזרה.
• כהוק Stop: הוק Stop מריץ את הסקריפט שלך בכל פעם שקלוד מנסה לסיים את התור שלו, ומחזיר את קלוד לעבודה אם הסקריפט יוצא עם קוד 2. את זה אוכף קלוד קוד (ה-harness), כך שהתור לא מסתיים עד שה-typecheck עובר או עד שמגיעים למגבלת החסימה. יש דוגמה בהמשך.
• על ידי מישהו שלא כתב את הקוד: בטרמינל, /code-review סוקר את ה-diff בסוכן משנה חדש שמעולם לא ראה את השיחה שלך. הוא לא מושפע מההנמקה שייצרה את הקוד.

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

טיפ

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

#סקירה מול המפרט שלך

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

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

הערה

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

#אכוף את הבדיקה עם הוק Stop

גרסת הוק ה-Stop של כלל ה-typecheck היא כמה שורות ב-.claude/settings.json. קוד יציאה 2 הוא מה שחוסם את העצירה. כל מה שהפקודה מדפיסה ל-stderr חוזר לקלוד כסיבה לכך שהוא עדיין לא יכול לסיים, ולכן פלט המהדר מנותב לשם:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

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

#אכוף את הכללים שלא יכולים להיות להם חריגים

טיפ

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

קח שלושה כללים שייתכן שיש לך ב-CLAUDE.md היום: Never read .env, Always run the formatter after editing, Don't touch the migrations folder. קלוד יפעל לפיהם כמעט בכל פעם. למעטים שבהם "כמעט" לא מספיק טוב, העבר אותם אל מחוץ ל-CLAUDE.md ואל תצורה שקלוד קוד (ה-harness) מפעיל בעצמו. מכאן והלאה, התוצאה לא תלויה במה שהמודל זוכר או מחליט.

#אכוף שלבים עם הוקים

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

• פקודת shell (המקרה הרגיל)
• POST לנקודת קצה של HTTP
• קריאת כלי באחד משרתי ה-MCP שלך
• הוק prompt או agent, שמאפשר למודל להחליט

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

הנה כלל הפורמטר כהוק PostToolUse. הוא רץ אחרי כל Edit או Write, וכבר לא משנה אם קלוד זוכר את הכלל, כי קלוד אינו זה שמריץ אותו:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write --ignore-unknown \"$(jq -r '.tool_input.file_path')\"" }
        ]
      }
    ]
  }
}

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

כלל ה-migrations הופך להוק PreToolUse שיוצא עם קוד 2 לכל נתיב תחת migrations/. אתה לא חייב לכתוב אותו בעצמך: write a hook that blocks edits to the migrations folder עובד כפרומפט, ו-/hooks מציג את התוצאה. אל תגזים: הוק מיועד לכלל עם אפס חריגים, ול-Prefer named exports יש הרבה, ולכן הכלל הזה נשאר ב-CLAUDE.md.

#הגבל גישה עם כללי הרשאה והארגז חול

כללי הרשאה מחליטים מה קלוד רשאי להריץ, לקרוא ולאחזר. כללי deny תקפים בכל מצב הרשאה, כולל auto ו-bypassPermissions, וזו בדיוק הסיבה שכלל .env שייך לשם:

{
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

כשהקובץ הזה שמור, שאלה לקלוד מה יש ב-.env נכשלת, גם דרך כלי Read וגם דרך cat .env.

כללים תואמים לקריאות כלים, לא לכוונה, ולכן כדאי לדעת איפה הקצוות:

• כלל Read כן תופס את cat .env, כי קלוד קוד מזהה את פקודות קריאת הקבצים הנפוצות.
• הוא לא יתפוס סקריפט שפותח את הקובץ.
• כלל deny של WebFetch לדומיין לא משפיע על curl לאותו דומיין, אלא אם הארגז חול פועל.

להגבלה ברמת מערכת ההפעלה על גישה למערכת הקבצים או לרשת, הפעל את הארגז חול עם /sandbox בסשן. הוא מגביל את פקודות ה-shell של קלוד ב-macOS, ב-Linux וב-WSL2, וגם קולט את כללי ה-deny של Read ואת כללי WebFetch(domain:...), ולכן לכל דבר שקשור לאבטחה תרצה את שניהם.

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

אזהרה

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

#בחר על מי הכלל חל

המקום שבו הכלל יושב קובע על מי הוא חל:

• .claude/settings.local.json ו-~/.claude/settings.json הם שלך בלבד. כשאתה בוחר Yes, and don't ask again לפקודה, קלוד קוד שומר את הכלל בקובץ המקומי.
• .claude/settings.json וההוקים שבו שייכים למאגר. אחרי שאתה מבצע commit, הם חלים על כל מי שעובד במאגר. כללי ה-deny שלו חלים מיד. כללי ה-allow שלו ממתינים עד שכל אדם מאשר את תיבת האמון של התיקייה הזו, ואמון בסביבת העבודה גם קובע מתי ההוקים שלו מתחילים לרוץ במחשב שלהם.
• הגדרות מנוהלות שייכות לארגון. הן מגיעות מקונסולת הניהול, מ-MDM, או מקובץ managed-settings.json, ואף קובץ הגדרות אישי לא יכול לעקוף אותן, וזה הופך אותן למקום היחיד למדיניות של צוות אבטחה. אם אתה האדם שמגדיר אותן, ראה הגדרת קלוד קוד לארגון שלך.

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

#שינוי ברירת מחדל

[!TIP]

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

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

• סשני מסוף אינטראקטיבי ו-VS Code מתחילים במצב auto.
• הוא מריץ את Claude Opus 5.5 ברמת מאמץ medium ברוב התוכניות והספקים.
• הוא מאציל עבודה לסוכני משנה כשהוא רואה סיבה לכך.
• הוא מצמצם את השיחה ככל שהיא גדלה.

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

#שינוי מצב ההרשאות

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

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

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

• curl | bash
• פריסות לייצור ומיגרציות
• force push מעל עבודה של אנשים אחרים
• נתונים רגישים שנשלחים לנקודות קצה חיצוניות
• פעולות שנראות מונעות מתוכן ש-Claude קרא ולא מכם

כשמצב auto חוסם פעולה, אתם מקבלים התראה והפעולה מופיעה תחת Recently blocked ב-/permissions, שם אתם יכולים לאשר את הפעולה כדי ש-Claude יוכל לנסות שוב. אחרי שלושה חסימות ברצף (או עשרים בסך הכל), מצב auto נעצר וחוזר לשאול אתכם.

כל זה לא מחליף את הבקרות הדטרמיניסטיות שלכם, כי זה רץ אחריהן. כללי deny ו-ask ו-hooks של PreToolUse חלים לפני שהמסווג רואה משהו, כך שכלל deny חוסם במצב auto בדיוק כמו בכל מקום אחר. ה-sandbox עדיין מגביל את פקודות ה-shell שהוא עוטף.

[!NOTE]

אפשר גם לומר don't push until I've reviewed בשיחה, והמסווג מתייחס לזה כאות חסימה. זה עדיין מודל שקורא את התמליל, והמשפט יכול ללכת לאיבוד כשהשיחה מצטמצמת, כך שכל דבר שחשוב שייך לכלל deny.

הבעיה ההפוכה היא שהמסווג עוצר שוב ושוב משהו ששגרתי בהגדרה שלכם. במקום לאשר אותו ידנית בכל פעם, הוסיפו אותו ל-autoMode.allow או תארו את התשתית המהימנה שלכם בהגדרת מצב auto. זו אנגלית פשוטה ולא תבניות, ו-/auto-mode-setup יכול לנסח עבורכם את חלק ה-environment מתוך הפרויקט והסשנים האחרונים:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-org and every repo under it",
      "Trusted internal domains: *.internal.example.com"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is fine, it's isolated from production and resets nightly"
    ]
  }
}

[!WARNING]

השאירו את "$defaults" בכל רשימה שאתם מגדירים, כי בלעדיו הרשומות שלכם מחליפות את הכללים המובנים של הרשימה במקום להוסיף אליהם. ב-environment וב-allow תאבדו את ההקשר והחריגים המובנים, ורשימת soft_deny בלי זה מורידה את החסימות המובנות על force push ועל פריסות לייצור.

בלוק ה-autoMode גם צריך לגור ב-~/.claude/settings.json ולא בפרויקט, כי המסווג מתעלם מ-autoMode בהגדרות הפרויקט.

אם אתם מעדיפים לראות כל עריכה וכל פקודה לפני שהן קורות, Shift+Tab בסשן עובר בין מצבי ההרשאות, כולל Manual, או התחילו עם claude --permission-mode manual מה-shell. ואם Manual אז שואל לעתים קרובות מדי, /fewer-permission-prompts סורק את התמלילים האחרונים שלכם אחר קריאות Bash ו-MCP נפוצות לקריאה בלבד ומוסיף אותן לרשימת allow ב-.claude/settings.json.

#שינוי המודל ורמת המאמץ

מאמץ הוא הבקרה העיקרית לכמה זמן Claude חושב, והוא מחליף את רוב מה שאנשים נהגו לעשות בניסוח ההנחיה. Claude Opus 5.5, Sonnet 5.5 ו-Haiku 5.5 ברירת המחדל שלהם היא medium, וזה מספיק לעבודת פיצ'רים יומיומית עם היקף ברור. הזמנים שבהם כדאי להזיז את זה, עם /effort בסשן:

• העלו אותו עם /effort high או /effort xhigh כשלהצליח תלוי במקרים שקל לפספס. חשבו על באג בקוד שלא אתם כתבתם, בדיקה לא יציבה, או שינוי סכמה שבו Claude צריך למצוא כל קורא של הצורה הישנה. Claude אז בודק יותר מקרי קצה ומאמת יותר מהעבודה שלו לפני שהוא עונה, ושם הולכים הזמן והטוקנים הנוספים.
• הורידו אותו עם /effort low כשאתם הולכים הלוך ושוב במהירות ובכל מקרה סוקרים כל תוצאה: סיעור מוחות, סקיצה ראשונה, שינוי שם בכמה קבצים. Claude מביא לכם נקודת התחלה מוקדם יותר, ומכיוון שאתם מנווטים כל צעד, השיקול הנוסף לא היה משנה הרבה מעבר להמתנה.
• שמרו את max לבעיה קשה שאתם רוצים ש-Claude יעבוד עליה בלעדיכם, כמו חיפוש אחר חולשת אבטחה. במשימות רגילות הוא נוטה לחשוב יותר מדי, כך שאתם משלמים יותר על תשובה שאולי לא טובה יותר ממה ש-high היה נותן לכם.
• כשרק ההודעה הבאה צריכה את זה, כמו שאלה אחת מסובכת באמצע עבודה שגרתית אחרת, שימו ultrathink בהנחיה הזו במקום לשנות את ההגדרה.

לגבי המודל עצמו, ברירת המחדל Opus 5.5 מטפלת ברוב כתיבת הקוד היטב ו-Sonnet עולה פחות בעבודה שגרתית. Claude Fable 5.1 שם כשאתם בוחרים אותו במפורש עם /model fable, ו-Haiku מתאים לסוכני משנה שעושים עבודות פשוטות. הגדרת מודל כוללת את הרשימה המלאה לפי תוכנית וספק.

#לדעת מה עולים סוכני משנה

Claude מאציל לסוכני משנה בעצמו:

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

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

סוכני משנה משתלמים במצבים האלה:

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

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

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

כדי להוציא עליהם פחות:

• הגדירו model: haiku בהגדרה של סוכן משנה אם העבודה שלו פשוטה, כמו איסוף הקבצים שמייבאים מודול או בדיקת קישורים בתיעוד. עבודה מהסוג הזה לא צריכה את המודל הגדול יותר, ו-Haiku עולה הרבה פחות לכל בקשה.
• בקשו סיכומים קצרים בחזרה, כדי שעשרים תוצאות לא ימלאו את ההקשר שלכם בכל מקרה.
• בדקו את /usage כדי לראות איזה חלק מהשימוש שלכם כל סוג של סוכן משנה תופס, כך שתוכלו לדעת אילו מהם מצדיקים את העלות שלהם.
• תנו לסוכן משנה מותאם ב-.claude/agents/ רק tools: Read, Grep, Glob. עכשיו זה סוקר שלא יכול לערוך כלום, והמגבלה הזו נאכפת על ידי Claude Code ולא מתבקשת בהנחיה.

הסוקר הזה הוא קובץ קצר אחד, .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

בקשו מ-Claude have the reviewer compare the rate limiter against SPEC.md והפערים חוזרים לתוך הסשן שלכם, שם Claude יכול לתקן אותם.

#שמירה על עלות והקשר נמוכים

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

/usage הוא המקום הראשון להסתכל בו. ב-Pro, Max, Ultra, Team ו-Enterprise הוא מפרק את השימוש שלכם לפי skill, סוכן משנה, תוסף ושרת MCP. הוא גם מסמן דפוסים כמו הקשר ארוך או החטאות מטמון תכופות ברגע שאחד מהם עובר 10% מהשימוש שלכם. משם, התיקונים הרגילים:

• /clear בין משימות לא קשורות. זה לא עולה כלום, וזה אומר שהמשימה הבאה לא ממשיכה לשלם על ההיסטוריה של הקודמת. /clear oauth-migration נותן שם לסשן שאתם עוזבים, כך שתוכלו לחזור אליו אחר כך.
• /compact עם מיקוד, כמו /compact keep the API changes and the test commands. בסשן ארוך /compact הוא בעצמו בקשה גדולה, כי הוא קורא את כל השיחה כדי לסכם אותה, ועוד יותר אחרי שהמטמון פג.
• שימו עין על עבודה ברקע: /loop, בדיקה של goal אחרי כל תור, וסוכני המשנה של Claude עצמו, כולם ממשיכים לשלוח בקשות בזמן שאתם לא מקלידים.

[!NOTE]

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

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

#הכוונת הסשן

[!TIP]

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

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

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

[!WARNING]

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

שתיים קטנות יותר: /btw עונה על שאלה מהירה בלי להוסיף שום דבר להיסטוריה. ולעבודה שנמשכת כמה ימים, /rename oauth-migration בסשן נותן לו שם, כך ש-claude --resume oauth-migration מה-shell שלכם מרים אותו בחזרה אחר כך, כולל נקודות הביקורת. claude --continue ממשיך את האחרון ביותר.

#תנו לקלוד לרוץ בליכם

[!TIP]

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

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

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

1. האם היא יודעת איך נראה סיום? תנאי מטרה, קובץ מפרט, או בדיקה כושלת שהיא צריכה להפוך לירוקה.
2. האם היא יכולה לבדוק את העבודה שלה? חבילת הבדיקות, הוק Stop, או סוג כלשהו של שלב סקירה.
3. במה מותר לה לגעת? כללי הרשאות, dontAsk, ארגז החול, worktree, הענף היחיד שאליו מותר לה לדחוף.
4. מה עוצר אותה? --max-turns, --max-budget-usd, מגבלת הוצאה.
5. לאן התוצאה הולכת, ומי מאשר? PR, תגובה, או סיכום, ואז אדם שמאשר את המיזוג, את הפריסה, או כל דבר אחר שאי אפשר לקחת בחזרה.

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

#הרצת קלוד מתוך סקריפט

claude -p "prompt" רץ פעם אחת ויוצא, וכך קלוד קוד מגיע למשימות CI, להוקי git, וללולאות מעטפת.

בסקריפט כמעט תמיד תרצו עוד כמה דגלים:

• --bare מדלג על הוקים, מיומנויות, תוספים, שרתי MCP, וקבצי CLAUDE.md, גם של המאגר וגם של המכונה, כך שההרצה עושה את אותו הדבר בכל מקום שהיא רצה. הוא גם אף פעם לא נוגע בהתחברות שלכם ל-claude.ai: האימות מגיע מ-ANTHROPIC_API_KEY, מ-apiKeyHelper בקובץ שאתם מעבירים עם --settings, או מאישורי הגישה של ספק הענן שלכם.
• --append-system-prompt, --mcp-config ו---settings מעבירים במפורש את מה שההרצה כן צריכה. הוקים שאתם מעבירים עם --settings לא רצים תחת --bare, אז אל תשתמשו ב---bare להרצה שצריכה אותם.
• --allowedTools מאשר מראש את הכלים שלו, ו---permission-mode dontAsk מסרב לכל דבר אחר שהיה מבקש אישור.
• --output-format json נותן לכם אובייקט תוצאה יחיד לניתוח, ו-stream-json עם --verbose מזרים אירועים בזמן שהם קורים.

ביחד, זה נראה כך:

for file in $(cat files.txt); do
  claude --bare -p "Migrate $file to the new logger API and commit. Reply OK or FAIL." \
    --allowedTools "Read,Edit,Bash(git add *),Bash(git commit *)" \
    --permission-mode dontAsk \
    --max-turns 20
done

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

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

#התחלת הרצות לפי לוח זמנים או לפי אירוע

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

בתוך סשן פתוח זה /loop, שחוזר על פרומפט במרווח קבוע:

/loop 15m check CI on this branch, and if it's red pull the failing job's log, fix it and push

כל הרצה היא תור נוסף באותו סשן, אז אל תשאירו אחת רצה בשיחה ארוכה. לכל דבר שצריך לקרות בזמן שהמחשב הנייד סגור, /schedule מגדיר משימה מתוזמנת בענן שרצה לפי טיימר. היא צריכה התחברות ל-claude.ai ולא מפתח API. אפשר להוסיף טריגר של אירוע GitHub על ידי בקשה מקלוד, או טריגר API ב-claude.ai/code/routines.

[!WARNING]

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

#הרצת סשנים במקביל

כשיש חלקי עבודה נפרדים שרצים בבת אחת, תנו לכל אחד checkout משלו כדי שהעריכות לא יתנגשו. claude -w feature-auth מתחיל סשן ב-worktree חדש, אפליקציית שולחן העבודה מריצה כמה כאלה זה לצד זה, ו-סשנים בענן מריצים אותם בענן במקום על המכונה שלכם.

worktree הוא checkout חדש, וזה אומר שקבצים ב-gitignore כמו .env לא נמצאים שם ותלויות לא מותקנות. לעניין הראשון, רשמו את קבצי ה-gitignore שאתם צריכים ב-.worktreeinclude בשורש המאגר (אותו תחביר כמו .gitignore) וקלוד קוד מעתיק אותם לכל worktree שהוא יוצר:

.env
.env.local
config/dev-credentials.json

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

לרוב אין צורך לנקות את זה בעצמכם:

• כשיוצאים מסשן worktree בלי שם, קלוד קוד מסיר את ה-worktree אם אין בו כלום. לסשן עם שם, או לסשן עם שינויים, הוא שואל מה לעשות.
• worktrees של תת-סוכן נעלמים כשהתת-סוכן מסיים בלי שינויים.
• worktrees של תת-סוכן ושל סשן רקע שנשארים מאחור מנוקים ברגע שהם ישנים יותר מ-cleanupPeriodDays ואין בהם עבודה.

[!NOTE]

הרצה של claude -p --worktree היא הרצה שאתם מנקים בעצמכם, כי היא יוצאת בלי לשאול. הסירו אותן עם git worktree remove <path>, ואם git מסרב כי ה-worktree נעול, קודם git worktree unlock <path>.

לשינוי מכני גדול אחד על פני קבצים רבים, /batch migrate every handler to the v2 response helpers מפצל את העבודה ל-5 עד 30 יחידות ומראה לכם את התוכנית. אחרי שאתם מאשרים אותה, כל יחידה מקבלת worktree משלה ופותחת PR או מדווחת מה קרה. מהמעטפת, claude agents (עדיין תצוגה מקדימה מחקרית) נותן לכם מסך אחד לכל מה שרץ ברקע על המכונה שלכם.

סשן שני הוא גם הסוקר העצמאי הכי קל שאפשר להשיג. סשן אחד כותב את מגביל הקצב, סשן אחר סוקר את @src/middleware/rateLimiter.ts בלי שראה אותו נכתב, ואתם מדביקים את הממצאים בחזרה לראשון. אותו רעיון כמו /code-review, כשאתם מעבירים את ההודעות.

#מה אפשר להפסיק לעשות

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

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

#משאבים קשורים

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