למה סוכני תכנות מתעלמים מההנחיות שלכם?

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

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

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

ראשית, שני מונחים. ה-context window הוא בלוק הטקסט שהמודל רואה בתור נתון: ה-system prompt, קובצי ההנחיות שלכם, השיחה, וכל קובץ שהסוכן קרא. ה-harness הוא התוכנית שעוטפת את המודל, הרכיב שקורא קבצים מהדיסק ומרכיב את הבלוק הזה. כמעט כל תלונה בפוסט זה היא למעשה תלונה על ה-harness, לא על המודל.

קובץ ההנחיות שלכם הוא הודעה, לא הגדרה

קובץ הנחיות אינו תצורה (configuration). שום רכיב בסביבת הריצה לא קורא את CLAUDE.md ואוכף אותו. המנגנון קורא את הקובץ מהדיסק ומדביק את הטקסט לתוך השיחה. ב-Claude Code תוכן זה מועבר כהודעת משתמש הממוקמת אחרי ה-system prompt, מה שאומר שהמודל רואה את הכללים שלכם באותו אופן שבו הוא רואה כל דבר אחר שהקלדתם.

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

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

אילו קובצי הנחיות נטענים ומתי

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

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

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

מלכודת טעינה נוספת, והיא הגרסה הנפוצה ביותר לטענה ש"הסוכן התעלם מההנחיות שלי": Claude Code קורא את CLAUDE.md, ולא את AGENTS.md. מאגר שסטנדרט העבודה שלו הוא AGENTS.md ואין בו CLAUDE.md לא מספק ל-Claude Code דבר לטעינה. הגישור הנתמך הוא CLAUDE.md שהשורה הראשונה בו היא @AGENTS.md, המייבאת את הקובץ בעת ההפעלה, עם כל הערה ספציפית ל-Claude מתחתיה. גם קישור סימבולי (symlink) יעבוד כאשר אין לך מה להוסיף. ההחלטה מה מקומו של מידע בקובץ זה היא שאלה נפרדת, המכוסה ב-הפרדת הנחיות לסוכן מתיעוד אנושי.

אימות טעינת הקובץ לפני שכתובו

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

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

לצורך בדיקה מעמיקה יותר, בצעו רישום (log) של הטעינות. אירוע ה-hook מסוג InstructionsLoaded מופעל בכל פעם שקובץ CLAUDE.md או קובץ חוקים נכנס להקשר, וה-matcher שלו מפרט את סיבת הטעינה: session_start, nested_traversal, path_glob_match, include, או compact. הוסיפו זאת ל-.claude/settings.json:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

ה-hook מקבל את ה-payload שלו כ-JSON דרך הקלט הסטנדרטי, לכן cat מצרף את הרשומה המלאה. עקבו אחריה באמצעות tail -f /tmp/instructions-loaded.log בזמן העבודה. סטטוס היציאה של אירוע זה אינו נלקח בחשבון, כך שה-hook יכול רק לצפות, אך לעולם לא לחסום. אם הקובץ המקונן שלכם אינו מופיע בלוג במהלך סשן שבו ציפיתם לראותו, הפסיקו את השכתוב. הבעיה נעוצה במיקום הקובץ.

השפעת סשן ארוך על הכללים שלכם

שתי השפעות נפרדות פועלות כאן, והן דורשות מענה שונה.

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

דחיסה. כאשר החלון מתמלא, המערכת מסכמת את השיחה עד כה וממשיכה מתוך הסיכום הזה. מה ששורד הוא מה שהמסכם שפט כחשוב, וזה לא בהכרח מה שאתם מחשיבים כחשוב. Claude Code מתעד את התוצאה לפי מנגנון, וההבדלים גדולים. שורש הפרויקט CLAUDE.md וכללים ללא טווח (unscoped) מוזרקים מחדש מהדיסק לאחר דחיסה. זיכרון אוטומטי מוזרק מחדש מהדיסק. כללים עם frontmatter מסוג paths: אובדים עד שקובץ תואם נקרא שוב. קובצי CLAUDE.md מקוננים בתת-תיקיות אובדים עד שקובץ באותה תת-תיקייה נקרא שוב.

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

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

מדוע הקוד הקיים גובר על הכלל

זהו הכשל שאנשים מתארים בתדירות הגבוהה ביותר ומאבחנים בתדירות הנמוכה ביותר. הקובץ שלכם מציין שגישה למסד הנתונים עוברת דרך שכבת ה-repository. הסוכן כותב handler שקורא ל-ORM (מיפוי אובייקטיבי-יחסי) ישירות. לא התעלמו מכם משיקולי סגנון. הראיות הכריעו אתכם.

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

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

גישה חדשה למסד הנתונים עוברת דרך app/repositories/. קבצים תחת app/legacy/ עדיין קוראים ל-ORM ישירות. זהו קוד ישן, לא התבנית. אל תעתיקו אותו.

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

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

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

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

• לא בר-בדיקה: "שמור על פונקציות קטנות." בר-בדיקה: "פונקציה שאורכה עולה על 60 שורות מחייבת הערה מעליה המסבירה את הסיבה לכך."
• לא בר-בדיקה: "בדוק את השינויים שלך." בר-בדיקה: "הרץ את npm test והדבק את מספר הכשלים לפני הכרזה על סיום משימה."
• לא בר-בדיקה: "שמור על קבצים מאורגנים." בר-בדיקה: "מטפלי HTTP נמצאים ב-src/api/handlers/. שום דבר אחר לא נכנס לספרייה זו."
• לא בר-בדיקה: "עצב את הקוד כראוי." בר-בדיקה: "השתמש בהזחה של 2 רווחים בקובצי .ts."

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

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

כיצד לאבחן זאת בתוך עשר דקות

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

1. ודאו שהקובץ נטען. הריצו את /context ועברו על רשימת קובצי ה-Memory. אם הקובץ אינו מופיע שם, תקנו את המיקום ועצרו. שום דבר אחר ברשימה זו אינו רלוונטי עדיין.
2. שחזרו את הבעיה בסשן חדש. התחילו סשן חדש ובצעו את המשימה הקטנה ביותר שאמורה להפעיל את החוק. אם הפעולה מצליחה כאן אך נכשלת בסשן ארוך, הבעיה נעוצה במרחק או בדחיסה (compaction). אם היא נכשלת גם כאן, החוק עצמו הוא הבעיה.
3. הסירו גורמים מתחרים. בקשו את אותו השינוי בספרייה שבה הקוד הקיים כבר מציית לחוק. אם הציות חוזר, הקוד שמסביב "הצביע" נגד ההנחיה שלכם.
4. חפשו התנגשות. שני קבצים שנותנים הנחיות שונות עבור אותה התנהגות הם כשל מתועד: המודל עשוי לבחור באחד מהם באופן שרירותי, והוא לא ידווח לכם על כך.
5. הפכו את החוק לבדיק ובצעו בדיקה חוזרת. נסחו מחדש את החוק עם נתיב קונקרטי ותנאי ברור. קפיצה גדולה בציות מעידה על כך שהניסוח היה הגורם לבעיה.

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

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

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

התיקונים, לפי סדר השפעה

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

1. הפכו את הכלל לקונקרטי. ציינו נתיב, פקודה או תנאי. הוסיפו את הראיות הנגדיות שהסוכן ימצא במאגר, כפי שהוצג קודם לכן. זה בחינם ופותר חלק מפתיע מהמקרים.
2. קרבו את הכלל למה שהוא מנהל. CLAUDE.md מקונן, כלל מוגבל נתיב בתוך .claude/rules/, או הערה בראש הקובץ עצמו. הכלל מגיע באותה קריאה של הקוד שעליו הוא חל. קבלו את הפשרה: כל מה שנטען בדרך זו יוסר בדחיסה הבאה ויחזור בקריאה התואמת הבאה.
3. העבירו את האכיפה לתוך hook. פרוזה מבקשת. hook מחליט. hooks רצים כקוד באירועי מחזור חיים קבועים וחלים ללא קשר למה שהמודל מסיק.
4. תנו את הכלל לכלי דטרמיניסטי ומחקו את הפרוזה. עיצוב, סדר ייבוא, אורך שורה, ייבואים אסורים, מבנה הודעת commit. ruff format, prettier --write, eslint, או hook מסוג pre-commit. המעצב (formatter) צודק בכל פעם ועולה אפס tokens. המשפט צודק ברוב הפעמים ועולה tokens בכל פנייה.

שלב 3 במלואו. נניח שקבצי הגירה (migration files) לעולם לא צריכים להיערך על ידי הסוכן. הציבו זאת בתוך .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

וזאת בתוך .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

הריצו את chmod +x .claude/hooks/guard-migrations.sh, לאחר מכן התחילו סשן חדש ובקשו מהסוכן לערוך קובץ תחת migrations/. העריכה תסורב וההודעה שלכם תחזור כסיבה. סטטוס יציאה 2 ב-PreToolUse חוסם את קריאת הכלי לפני שהיא רצה, וטקסט ה-stderr שלכם מועבר למודל כהודעת החסימה. ${CLAUDE_PROJECT_DIR} מתורגם לשורש הפרויקט, כך שה-hook עובד ללא קשר לספרייה שבה הסוכן נמצא. הסוכן לא צריך להסכים עם הכלל, לזכור את הכלל, או להחזיק את הכלל בהקשר. העריכה לא מתרחשת.

עבור איסור גורף ללא לוגיקה, permissions.deny בהגדרות שלכם עושה את אותה עבודה ללא סקריפט לתחזוקה, ו-מצבי ההרשאה קובעים מה רץ מבלי לשאול אתכם תחילה. אם הנחיה חייבת באמת לשבת ברמת ה-system prompt ולא בהודעת משתמש, --append-system-prompt מציב אותה שם, אם כי יש להעביר אותה בכל הפעלה, מה שמתאים לסקריפטים יותר מאשר לעבודה אינטראקטיבית.

מה שלא ניתן לפתור באמצעות הנחיות

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

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

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

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

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

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

FAQ

מדוע Claude Code מתעלם מקובץ ה-CLAUDE.md שלי?

בדקו אם הקובץ נטען לפני שתניחו שהוא התעלם ממנו. הריצו את /context ועיינו ברשימת ה-Memory files; קובץ שאינו מופיע שם אינו חלק מהשיחה. קובצי הנחיות מועברים כהודעת משתמש לאחר ה-system prompt ומתייחסים אליהם כאל הקשר (context) ולא כאל תצורה מחייבת, לכן אין הבטחה לאכיפה קפדנית. רוב המקרים נובעים מאחת מארבע סיבות: הקובץ נמצא בתת-ספרייה שהסוכן מעולם לא קרא ממנה, שני קבצים סותרים זה את זה והמודל בחר אחד מהם באופן שרירותי, הכלל מעורפל מדי מכדי לבדוק פעולה מולו, או שהקוד שמסביב מדגים את ההפך ממה שהכלל מורה.

האם עריכת קובץ ההנחיות באמצע סשן משנה משהו?

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

איזה קובץ קובע כאשר יש סתירה בין CLAUDE.md בשורש לבין קובץ מקונן?

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

האם ההנחיות שלי שורדות פעולת /compact?

זה תלוי באופן שבו הן נטענו. קובץ CLAUDE.md בשורש הפרויקט, כללים ללא הגדרת היקף (unscoped) וזיכרון אוטומטי מוזרקים מחדש מהדיסק לאחר compaction. כללים עם frontmatter מסוג paths: וקבצי CLAUDE.md מקוננים בתת-ספריות הולכים לאיבוד עד שקובץ תואם נקרא שוב. כל מה שהקלדתם בצ'אט בלבד ישרוד רק אם תהליך הסיכום (summariser) במקרה שמר אותו. אם כלל חייב להישמר לאורך סשן שלם, הציבו אותו בקובץ שורש הפרויקט ללא frontmatter מסוג paths:.

מתי כלל צריך להפוך ל-hook במקום לטקסט חופשי?

כאשר הבדיקה היא דטרמיניסטית והמחיר של פספוס גבוה מהמחיר של כתיבת סקריפט קטן. הגבלות על נתיבי קבצים, פקודות נדרשות לפני ביצוע commit, וקריאות אסורות לכלים – כולם מתאימים לכך. ה-hook מסוג PreToolUse שיוצא עם סטטוס 2 חוסם את קריאת הכלי לחלוטין ומחזיר את טקסט ה-stderr שלכם למודל כסיבה, כך שהוא נשמר ללא קשר לשאלה אם הכלל עדיין נמצא איפשהו בהקשר. כל דבר שפורמטר או linter יכולים להחליט לגביו צריך להיות באחריות אותו כלי ולהימחק מקובץ ההנחיות לחלוטין.