למה סוכני תכנות מתעלמים מההנחיות שלכם?
סוכני תכנות מתעלמים מהוראות בגלל מגבלות בחלון ההקשר או ב-harness. גלו כיצד לאבחן את הבעיה לפני שתשכתבו את הקובץ שוב ותלמדו למה המודל לא תמיד רואה את ההנחיות שלכם.
מדוע סוכני תכנות מתעלמים מההנחיות שלכם
סוכני תכנות מתעלמים מההנחיות שלכם בגלל ארבע סיבות, ואף אחת מהן אינה נובעת מכך שהייתם מנומסים מדי. הכלל מעולם לא היה בתוך חלון ההקשר (context window). הכלל היה מעורפל מדי מכדי שניתן יהיה לבדוק פעולה מולו. משהו אחר בהקשר סתר אותו, בדרך כלל הקוד שהסוכן קרא זה עתה. או שהכלל עדיין טעון אך נמצא הרחק מאחורי התור הנוכחי, והסוכן פועל על סמך מה שקרוב אליו.
לכל סיבה יש פתרון משלה, לכן המשימה הראשונה היא להבדיל ביניהן. אותיות רישיות והמילה IMPORTANT אינן מהוות אבחנה. המנגנונים להלן משתמשים ב-Claude Code כדוגמה עבודה, מכיוון שהתנהגות הטעינה והדחיסה שלו מתועדת בפירוט נכון לאוגוסט 2026. כלים אחרים נבדלים בפרטים אך מתנהגים באותו אופן בקווי המתאר.
תחילה, שני מונחים. חלון ההקשר (context window) הוא בלוק הטקסט שהמודל רואה בתור נתון: הנחיית המערכת (system prompt), קובצי ההנחיות שלכם, השיחה, וכל קובץ שהסוכן קרא. ה-harness הוא התוכנית שעוטפת את המודל, הרכיב שקורא קבצים מהדיסק ומרכיב את הבלוק הזה. כמעט כל תלונה בפוסט זה היא למעשה תלונה על ה-harness, לא על המודל.
קובץ ההנחיות שלכם הוא הודעה, לא הגדרה
קובץ הנחיות אינו קובץ הגדרות (configuration). שום רכיב בסביבת הריצה אינו קורא את CLAUDE.md ואוכף אותו. ה-harness קורא את הקובץ מהדיסק ומדביק את הטקסט בתוך השיחה. ב-Claude Code, תוכן זה מועבר כהודעת משתמש הממוקמת לאחר ה-system prompt, מה שאומר שהמודל רואה את הכללים שלכם באותו אופן שבו הוא רואה כל דבר אחר שהקלדתם.
לכך יש השלכה לא נוחה. הכללים שלכם מתחרים בכל פיסת טקסט אחרת בחלון, על בסיס שווה. כלל הוא טענה. הקובץ שהסוכן פתח זה עתה הוא ראיה. כאשר השניים אינם מסכימים, הראיה לרוב מנצחת, ושום דבר אינו מעלה שגיאה, כיוון שמנקודת המבט של המודל לא השתבש דבר.
התיעוד הרשמי מציין זאת במפורש: קובצי הנחיות מטופלים כהקשר (context), ולא כהגדרות נאכפות. כדי לחסום פעולה ללא קשר להחלטת המודל, אתם זקוקים ל-hook, לא למשפט. זכרו זאת. רוב התיקונים בסוף פוסט זה הם יישום של קו מחשבה זה למקרה ספציפי.
אילו קובצי הוראות נטענים ומתי
Claude Code סורק את עץ הספריות כלפי מעלה, החל מהספרייה שבה הפעלת אותו. כל קובץ CLAUDE.md ו-CLAUDE.local.md מהשורש של מערכת הקבצים ועד לספריית העבודה שלך נטענים במלואם בעת ההפעלה. הקבצים משורשרים לפי סדר זה, כך שהקובץ הקרוב ביותר למיקום שבו הפעלת את הכלי נקרא אחרון, ובתוך אותה ספרייה, הקובץ .local מתווסף לאחר הקובץ הראשי.
קבצים בספריות משנה מתחת לספריית העבודה שלך מתנהגים אחרת. הם אינם נטענים בעת ההפעלה. הם נטענים כאשר הסוכן קורא קובץ באותה ספרייה. כך גם לגבי חוקים בעלי טווח נתיב ב-.claude/rules/ המכילים שדה frontmatter מסוג paths:: הם נכנסים להקשר כאשר נקרא קובץ תואם, ולא בכל שלב בתהליך.
הבדל יחיד זה מסביר חלק גדול מהכשלים המדווחים. אתה מציב חוק ב-packages/api//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 מציגה את מיקומי הקבצים ופותחת אותם לעריכה, כולל קבצים שטרם נוצרו.
לבדיקה מעמיקה יותר, ניתן לתעד את הטעינות. אירוע ה-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 מקבל את המידע בפורמט 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."
גודל הוא אותה בעיה בתחפושת אחרת. ההנחיות של Claude Code מכוונות לפחות מ-200 שורות לכל קובץ הוראות ומציינות במפורש שקבצים ארוכים יותר מפחיתים את רמת הציות. קובץ של 700 שורות אינו מהווה הנחיה מוצקה יותר. הוא מכיל 700 שורות של טענות עם סיכוי גבוה יותר לסתירות פנימיות, והוא נצרך מחלון ההקשר שלך בכל פנייה, מה ש-בא לידי ביטוי ישירות בניצול ה-tokens שלך. ארגון הקובץ כך שכל כלל יופיע תחת כותרת שניתן לסרוק בקלות מוסבר ב-כתיבת קובץ הוראות שסוכן יכול לפעול לפיו.
כיצד לאבחן זאת בתוך עשר דקות
בצעו את הפעולות הבאות לפי הסדר. דילוג על השלבים עד לשלב האחרון הוא הגורם לכך שאנשים מסיימים עם קובץ ארוך של חוקים צעקניים שעדיין אינם עובדים.
- וודאו שהקובץ נטען. הריצו את
/contextועברו על רשימת קובצי ה-Memory. אם הקובץ אינו מופיע שם, תקנו את הנתיב ועצרו. שום דבר אחר ברשימה זו אינו רלוונטי עדיין. - שחזרו את הבעיה בסשן חדש. התחילו סשן חדש ובצעו את המשימה הקטנה ביותר שאמורה להפעיל את החוק. הצלחה כאן אך כישלון בסשן ארוך מצביעים על בעיית מרחק או דחיסה (compaction). כישלון כבר בשלב זה אומר שהחוק עצמו הוא הבעיה.
- הסירו גורמים מתחרים. בקשו את אותו השינוי בספרייה שבה הקוד הקיים כבר מציית לחוק. אם הציות חוזר, הקוד שמסביב "גבר" על ההנחיה שלכם.
- חפשו התנגשות. שני קבצים שנותנים הנחיות שונות לאותה התנהגות הם כשל מתועד: המודל עשוי לבחור באחד מהם באופן שרירותי, והוא לא ידווח לכם על כך.
- הפכו את החוק לבדיק ובצעו בדיקה חוזרת. נסחו מחדש את החוק עם נתיב קונקרטי ותנאי ברור. קפיצה גדולה ברמת הציות מעידה על כך שהניסוח היה הגורם לבעיה.
שלב 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תוצאה בשני קבצים שאומרים דברים שונים היא הבאג שלכם. מחקו אחד מהם. אל תנסו לדרג אותם באמצעות ניסוח חזק יותר, כיוון שאין מנוע דירוג שניתן לפנות אליו.
התיקונים, לפי סדר השפעה
לכל שלב להלן יש השפעה רבה יותר מהשלב שמעליו, אך הוא דורש עלות הקמה גבוהה יותר. התחילו מהחלק העליון כאשר קל לשנות את ניסוח הכלל. רדו למטה ברגע שכלל הופך לחשוב מספיק כדי שפספוסים מזדמנים לא יהיו קבילים.
- הפכו את הכלל לקונקרטי. ציינו נתיב, פקודה או תנאי. הוסיפו את הראיות הנגדיות שהסוכן ימצא במאגר, כפי שהוצג קודם לכן. זהו צעד ללא עלות שפותר חלק מפתיע מהמקרים.
- קרבו את הכלל למה שהוא מנהל.
CLAUDE.mdמקונן, כלל המוגבל לנתיב בתוך.claude/rules/, או הערה בראש הקובץ עצמו. הכלל מופיע באותה קריאה של הקוד שעליו הוא חל. קבלו את הפשרה: כל מה שנטען בדרך זו יוסר בדחיסה הבאה ויחזור בקריאה התואמת הבאה. - העבירו את האכיפה לתוך hook. פרוזה מבקשת. hook מחליט. hooks רצים כקוד באירועי מחזור חיים קבועים וחלים ללא קשר למה שהמודל מסיק.
- העבירו את הכלל לכלי דטרמיניסטי ומחקו את הפרוזה. עיצוב, סדר ייבוא, אורך שורה, ייבואים אסורים, מבנה הודעת commit.
ruff format,prettier --write,eslint, או hook מסוגpre-commit. המעצב (formatter) צודק בכל פעם ולא עולה בטוקנים. המשפט צודק ברוב הפעמים ועולה בטוקנים בכל תור.
שלב 3 במלואו. נניח שקובצי הגירה (migration) לעולם לא צריכים להיערך על ידי הסוכן. הציבו זאת בתוך .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.
הסשן שלכם הופך לדוגמה. אם הסוכן הפר את הכלל בתור 12 ואתם אפשרתם לזה לעבור, ההפרה הזו יושבת כעת בהקשר כהדגמה, והיא עדכנית הרבה יותר מהכלל. תקנו הפרה ברגע שאתם רואים אותה. הפרה שלא תוקנה מלמדת את המשך הסשן.
קובץ הנחיות אינו גבול אבטחה. הוא מעצב התנהגות אך אינו אוכף אותה. כל דבר שבו טעות היא יקרה, כגון אישורים או פקודות הרסניות, שייך להרשאות או ל-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 מקוננים בתת-ספריות הולכים לאיבוד עד שקובץ תואם נקרא שוב. כל דבר שהקלדתם רק בצ'אט ישרוד רק אם מנגנון הסיכום בחר לשמור אותו. אם כלל חייב להישמר לאורך כל הסשן, הציבו אותו בקובץ שורש הפרויקט ללא frontmatter מסוג paths:.
מתי כלל צריך להפוך ל-hook במקום לטקסט חופשי?
כאשר הבדיקה היא דטרמיניסטית ועלות של פספוס גבוהה מעלות כתיבת סקריפט קטן. הגבלות על נתיבי קבצים, פקודות נדרשות לפני commit וקריאות אסורות לכלים – כולם מתאימים לכך. PreToolUse hook שמסתיים עם סטטוס 2 חוסם את קריאת הכלי לחלוטין ומחזיר את טקסט ה-stderr שלכם למודל כסיבה, כך שהכלל נשמר ללא קשר לשאלה אם הוא עדיין נמצא איפשהו בהקשר. כל דבר שפורמטר או linter יכולים להחליט לגביו צריך להיות מנוהל על ידי אותו כלי ולהימחק לחלוטין מקובץ ההנחיות.