איך להגדיר CLAUDE.md בשנת 2026: תבנית ו-6 כללים

חומרים על vibe coding: כלים, מקרי בוחן וטעויות. מדריכי Ailoot.

למה צריך CLAUDE.md, ולמה Claude שוכח את הפרויקט בלעדיו?#

אתם פותחים את Claude Code ביום שלישי ומסבירים: “אני עובד על הפרויקט הזה, אלה הכלים, אל תעשה את זה.” זה עובד.

ביום חמישי, אותו צ'אט כבר הסתיים, אז אתם חוזרים על הכול. בשבת שוב; ביום שני שוב.

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

עם CLAUDE.md שמתעדכן, אין צורך עוד בהקדמה. כל הכללים שנהגתם לחזור עליהם בכל צ'אט נמצאים בקובץ אחד ומופיעים אוטומטית בתחילת כל סשן. ההנחיה נעשית קצרה: “עשה X”, במקום “אני עובד על פרויקט Y, הכלים הם Z, אל תעשה A או B, ודרך אגב, זכור גם את C.”

ואז הטעויות החוזרות נעלמות.

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

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

מהו CLAUDE.md, ובאיזה סדר Claude קורא את הקבצים?#

Anthropic מתארת את CLAUDE.md כך בתיעוד הרשמי שלה:

ארבעת המקומות שבהם Claude Code מחפש CLAUDE.md, לפי סדר עדיפות עולה:

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

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

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

איך כותבים CLAUDE.md מינימלי ב-5 דקות (תבנית מוכנה לשימוש)?#

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

# [PROJECT NAME] - project navigation

This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.

## What this project is

**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].

Details are in `business/INDEX.md`.

## Reading order at the start of every session

1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/<current plan>`,
   `mastery/<area>` or the feature folder in the code

Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.

## Repository structure

[NAME]/
├── CLAUDE.md            ← this file, navigation
├── about-me/            ← digital projection of you (how you think, what you value)
│   └── INDEX.md
├── business/            ← the business’s second brain
│   ├── INDEX.md
│   ├── audience/        ← customer profile
│   ├── products/        ← products, prices
│   ├── goals/           ← goals, metrics
│   └── economics/       ← unit economics, revenue
├── plans/               ← technical plans (one plan = one feature)
├── retrospectives/      ← reflections after each session
└── (project code)

### Where to find things

| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |

## Tools

[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].

## Repo rules

1. Never hardcode dynamic data (prices, dates, figures) -
   get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
   builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
   `grep "^VAR=" .env`.

## Big features = a plan in `plans/`

Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.

## End-of-feature cycle

After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.

## End-of-session reflection

In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.

## Language

Always respond in the user’s preferred language. Use hyphens only, not em dashes.

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

Create a CLAUDE.md file at the project root using this template:

[INSERT THE ENTIRE TEMPLATE FROM ABOVE]

Proceed as follows:

Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.

Fill in all the square-bracketed fields in the template based on what you find in those folders.

If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.

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

Show me the final file and ask what should be revised.

Always respond in the user’s preferred language.

אם עדיין אין לכם תיקיות about-me/ ו-business/, זה בסדר. Claude ישאל שאלות הבהרה וירכיב CLAUDE.md מינימלי על סמך המידע הקיים. תוכלו ליצור את התיקיות בהמשך, אחרי שתדעו מה להכניס לתוכן.

אילו 6 כללים הופכים את CLAUDE.md למסמך שמתעדכן כל הזמן?#

כלל 1. שמרו על פחות מ-200 שורות

Anthropic אומרת זאת בתמציתיות בתיעוד הרשמי שלה:

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

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

כלל 2. סיימו כל סשן ברפלקציה

כתבו ב-CLAUDE.md: “בסוף כל סשן, תעדו מה עשיתם ולמדתם ב-retrospectives/YYYY-MM-DD_*.md.” אחרי שתוסיפו את השורה הזאת, Claude יתחיל לסיים כל סשן ברפלקציה משלו; לא תצטרכו לבקש זאת.

למה לעשות רפלקציה:

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

כלל 3. בצעו commit אחרי כל משימה שהושלמה

ב-CLAUDE.md שלי כתוב: “אחרי כל משימה שהושלמה, צרו git commit עם הודעה משמעותית.” Claude מתחיל לפרק את העבודה ל-commits אטומיים בעצמו.

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

כלל 4. עיינו תמיד בתיקיית business/

בכל משימה שקשורה ללקוחות, למוצרים או לטקסט, הסוכן צריך לפתוח תחילה את business/INDEX.md ואת הקובץ הרלוונטי שמופיע בו. ב-CLAUDE.md שלי כתוב במפורש: “כשעובדים על ממשק המשתמש או על טקסט, בדקו תחילה את business/audience/avatar.md ואת business/assets/brand-guidelines.md.”

בלי הכלל הזה, Claude כותב טקסט ב“סגנון הכללי של אתר איכותי.” איתו, הטקסט נכתב בסגנון שלכם, עבור הלקוח שלכם, בלי המילים האסורות שלכם.

כלל 5. הוסיפו כלל אחרי כל טעות של הסוכן

זהו הכלל המרכזי שמשאיר את CLAUDE.md עדכני.

דוגמאות מתוך CLAUDE.md שלי, שנוספו אחרי טעויות מסוימות:

• “לעולם אל תבצעו commit לקובצי WIP של מישהו אחר באמצעות git add . - הוסיפו קבצים ל-staging לפי שם.”
• “לפני push ל-main, בדקו git log origin/main..main --oneline - אם הפלט אינו ריק, אל תבצעו push.”
• “אל תמציאו ערכים - קחו אותם מ-.env או מהקוד. במיוחד כתובות URL, שמות משתמש וטוקנים.”

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

כלל 6. שימו את האבטחה ב-.claude/settings.json, לא ב-CLAUDE.md

אפשר לכתוב ב-CLAUDE.md “אל תיגע ב-.env”, אבל זו בקשה; Claude עלול להפר אותה כי CLAUDE.md נטען כהודעת משתמש ולא כחוק. לאבטחה קריטית, השתמשו ב-.claude/settings.json, שבו אפשר לחסום פקודות מסוימות באופן קשיח.

רשימת החסימה שאני מוסיף לכל פרויקט חדש:

• rm -rf (מחיקה רקורסיבית של קבצים כלשהם).
• קריאה של כל תוכן .env (Read .env).
• export ו-curl באותה פקודה (תבנית לדליפת סודות החוצה).
• git push --force ללא אישור מפורש.

מצאו מדריכים נוספים ב-Ailoot.

איך בנוי CLAUDE.md בעסק פעיל (אנטומיה של קובץ בן 280 שורות)?#

רוב דוגמאות CLAUDE.md באינטרנט הן תבניות טכניות למפתחים: “השתמשו ב-TypeScript,” “אל תכתבו בדיקות שאורכן עולה על 50 שורות.” עבור יזם, CLAUDE.md כזה חסר תועלת - הוא אינו עוסק בצד העסקי.

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

1. תיאור קצר של הפרויקט (15 שורות). מה אנחנו עושים, מי קהל היעד ואילו מוצרים אנחנו מציעים. לא סיכום של אתר שיווקי, אלא תקציר לסוכן כדי שיבין “לאן אנחנו הולכים.”

2. עליי (10 שורות). הפניה לתיקיית about-me/ - ייצוג דיגיטלי של צורת החשיבה שלי. טון, ערכים, עקרונות ומילים אסורות. כש-Claude כותב טקסט “בשמי”, הוא קורא קודם את התיקייה הזאת כדי להתאים את הקול.

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

4. טבלת “היכן למצוא דברים” (25 שורות). ניתוב מ“שאלה → קובץ.” למשל, עבור משרד תיווך, היא עשויה לומר “צריך תנאי משכנתה → business/products/mortgage.md,” או “צריך את הטון של פוסטים → business/assets/voice.md.” החליפו בקבצים שלכם. הטבלה הזאת היא לבו של CLAUDE.md. בלעדיה, הסוכן מנחש איזה קובץ מכיל את התשובה. איתה, הוא מגיע ישר למקור.

5. עקרונות מרכזיים של הפרויקט (40 שורות, 10-15 פריטים). החלק הזה מצטבר לאט ודורש את מירב המאמץ. כל פריט הוא עקבה של טעות מסוימת. לדוגמה, הכללים לחנות מקוונת יכולים להיות “לעולם אל תקבעו מחירים וזמני משלוח בקוד,” “אל תפרסמו מוצר ללא הוראה מפורשת,” ו“בדקו את הסגנון מול מילון המותג לפני פרסום רשומת מוצר.” החלק הזה הוא “חוקת הפרויקט.”

6. תכנון תפעולי (20 שורות). טבלת טריגרים שממפה “ביטוי משתמש → פעולה.” למשל: “כשאני אומר ‘תכנן את השבוע,’ פתח את ops/monthly.md וצור את הקובץ של השבוע.” כך Claude הופך לעוזר תפעולי שמבין את ההקשר של הפקודות.

7. כלים (5 שורות). טכנולוגיות. בקצרה, בלי מלל מיותר.

8. פרסום (15 שורות). תהליך שלב אחר שלב לפרסום שינויים בייצור: אילו פקודות להריץ, באיזה סדר ומה לבדוק. בעבר הייתי מסביר זאת בכל פעם. עכשיו Claude יודע.

9-12. אבטחה (35 שורות). ארבע תתי-סעיפים נפרדים: כללים לעבודה עם .env, גישה למסד הנתונים בייצור, פקודות בטוחות להדגמות (הקלטות מסך, שידורים, צילומי מסך כדי שטוקנים לא ייחשפו בטעות) וכללים לסבב של סודות.

13. תיקיית plans/ (10 שורות). תקן לתוכניות: שם הקובץ, מבנה שלבים ומה לכלול בבלוק הסיכום.

14. תיקיית retrospectives/ (5 שורות). תקן לרפלקציה: תבנית, שם קובץ ומה הוא צריך לכלול.

15. נתוני מסד נתונים חיים (15 שורות). כלל לסימון “נתונים טריים”: כשקובץ אומר שהנתונים חייבים להיות עדכניים, הסוכן מביא אותם מהמקור ולא משתמש בנתונים ישנים. כך נמנע הסיכון ש-Claude ישתמש בנתוני אתמול.

16. שפה (3 שורות). “תמיד השב בשפה המועדפת על המשתמש. השתמש רק במקפים, לא בקווים מפרידים ארוכים.”

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

מה עושה הפקודה /init, ולמה היא לא מספיקה?#

Anthropic מתארת את הפקודה כך בתיעוד שלה:

מה /init עושה היטב:

• מזהה כלים מתוך package.json, Cargo.toml ו-pyproject.toml.
• רושמת פקודות בנייה ובדיקה.
• מזהה מוסכמות מקבצים קיימים (.eslintrc, .prettierrc).
• מזהה כללי Cursor קיימים (.cursorrules, .cursor/rules/) וכללי Copilot ומכניסה את החלקים הרלוונטיים. היא מזהה AGENTS.md במצב CLAUDE_CODE_NEW_INIT=1.

מה /init לא תעשה:

• היא לא תדע מי הלקוחות שלכם.
• היא לא תכלול מילים אסורות לכתיבת טקסט.
• היא לא תוסיף כללים על טעויות של הסוכן (כי עדיין לא היו כאלה).
• היא לא תיצור טבלת “היכן למצוא דברים” למבנה העסקי שלכם.

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

1. הריצו /init ב-Claude Code

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

2. הוסיפו עליו את התבנית מהמאמר הזה

   השתמשו בחלק “CLAUDE.md מינימלי ב-5 דקות.” הוסיפו חלקים לניווט, ניתוב ועקרונות.

3. מלאו את השדות שבסוגריים המרובעים

   תנו ל-Claude את ההנחיה “קרא את הפרויקט שלי ומלא את התבנית.” אם תיקיות business/ ו-about-me/ עדיין אינן קיימות, Claude ישאל שאלות הבהרה.

4. ערכו בדיקת עמידות

   אמרו ל-Claude, “קרא את CLAUDE.md שלי ומצא 10 עמימויות שעלולות לגרום לך, כסוכן, להבין לא נכון.” תקבלו רשימת תיקונים.

5. ואז חיו עם הקובץ

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

הנחיה לשלב הרביעי:

I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.

Your task is to stress-test it. Find 10 reasons we could potentially fail:

where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it

where there are gaps that would force you to make things up

where rules contradict one another

where I overestimate how much can be done in one day

where I underestimate things (this is even worse)

Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.

CLAUDE.md לעומת AGENTS.md לעומת MEMORY.md: מי קורא מה בשנת 2026?#

השאלה המרכזית שמבלבלת משתמשים חדשים היא: האם Claude Code קורא AGENTS.md? לפני ספטמבר 2026, התשובה הייתה “לא”: התיעוד של Anthropic המליץ ליצור CLAUDE.md שמייבא את AGENTS.md. מגרסה 2.1.277 (שפורסמה ב-18 בספטמבר 2026), Claude Code קורא את AGENTS.md בעצמו, אבל רק אם אין CLAUDE.md,‏ .claude/CLAUDE.md או CLAUDE.local.md בתיקיית העבודה או מעליה.

אם בפרויקט יש CLAUDE.md, Claude Code קורא כברירת מחדל רק אותו ומדלג על AGENTS.md. אפשר לשנות זאת ב-/config, תחת Project instructions: למשל, ההגדרה claude-md-and-agents-md גורמת לו לקרוא את שני הקבצים. דרך נוספת פועלת בכל גרסה: הוסיפו יבוא ל-CLAUDE.md:

@AGENTS.md

## Claude Code

Additional rules for Claude Code that other agents don’t need.

תחביר @filename מייבא קובץ אחר. Claude קורא אותו וטוען אותו להקשר יחד עם CLAUDE.md. היבוא אינו גורם לקריאת הקובץ פעמיים, גם אם Claude Code יכול לקרוא את AGENTS.md בעצמו.

מתי צריך AGENTS.md. אם אתם עובדים במקביל עם Claude Code ועם Codex CLI, Cursor או Copilot, צרו AGENTS.md כמקור האמת היחיד, שימו @AGENTS.md ב-CLAUDE.md והוסיפו מעליו כללים ייחודיים ל-Claude. אם אין כללים כאלה, אין צורך ליצור CLAUDE.md: מגרסה 2.1.277, Claude Code יקרא את AGENTS.md בעצמו. אם אתם עובדים רק עם Claude Code, אין צורך ב-AGENTS.md; השתמשו ב-CLAUDE.md יחיד. לכל האפשרויות שלב אחר שלב, ראו המדריך לשימוש ב-AGENTS.md וב-CLAUDE.md בפרויקט אחד.

מהו MEMORY.md? מאז עדכון אחרון, Claude Code שומר אוטומטית הערות עליכם ב-~/.claude/projects/<project-name>/memory/MEMORY.md. ההערות כוללות הרגלי שיחה (“המשתמש מעדיף תשובות קצרות”), ביטויים חוזרים (“אסר אימוג'ים בקוד”) ותצפיות התנהגותיות (“עובד על macOS, משתמש ב-zsh”).

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

מהו גודל שימושי ל-CLAUDE.md, ואיך כדאי לבדוק קובץ ארוך?#

בכל חלון של Claude Code נטענות להקשר כמה שכבות: הודעת המערכת של Anthropic (ההערכה היא עשרות אלפי טוקנים), CLAUDE.md שלכם, קבצים שיובאו באמצעות @,‏ MEMORY.md, היסטוריית הצ'אט הנוכחית ותוכן הקבצים ש-Claude פותח. כל אלה צריכים להיכנס להקשר של המודל (200K טוקנים עבור Sonnet, מיליון עבור Opus).

ככל ש-CLAUDE.md גדל, נשאר פחות מקום לעבודה הנוכחית. קובץ בן 1,000 שורות הוא בערך 8,000 טוקנים, והוא חוזר בכל סשן. במנוי Pro (מניסיוני, כ-10-12 הנחיות “כבדות” ביום), הדבר מקטין את הקיבולת שלכם ברבע.

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

לכן זהו כלל האצבע לגודל:

• 80-120 שורות - טווח התחלתי נוח למפת פרויקט תמציתית, ללא הבטחה לציון היענות מסוים.
• 150-200 שורות - תזכורת שימושית לבדוק רלוונטיות ולהעביר נהלים מפורטים לקבצים מקושרים.
• 200-300 שורות - בדקו נפח טוקנים, כפילויות ותוצאות משימות; הדוגמה העסקית בת 280 השורות שלמעלה עדיין עשויה לפעול היטב.
• 400+ שורות - סיבה טובה לבדיקה ממוקדת, ולא הוכחה שהקובץ אינו שמיש. שמרו מגבלות חיוניות והעבירו פרטים רק לאחר בדיקה שהקישורים והכללים עדיין פועלים.

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

Anthropic נותנת בדיקה ישירה בתיעוד שלה:

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

אילו 7 טעויות הופכות את CLAUDE.md לחסר תועלת?#

טעות 1. “היה מהנדס טוב”

הטעות הנפוצה ביותר. אנשים כותבים ב-CLAUDE.md משאלות כלליות: “כתוב קוד נקי,” “השתמש בשיטות העבודה המומלצות,” “חשוב כמו מהנדס בכיר.”

המילים האלה אינן אומרות דבר. Claude כבר כותב “קוד נקי” במובן הכללי. השורות האלה תופסות מקום בהקשר בלי להשפיע על שום החלטה.

החליפו “כתוב קוד נקי” ב“השתמש בהזחה של 2 רווחים,” “אל תשתמש ב-any ב-TypeScript,” או “אורך פונקציה לא יעלה על 30 שורות.” ספציפי וניתן לבדיקה.

טעות 2. כפילות של דברים ש-Claude כבר יודע

תיאורים של מוסכמות שפה רגילות (“ב-JavaScript, פונקציות הן אזרחים מדרגה ראשונה,” “ל-TypeScript יש טיפוס סטטי”). הסברים על אופן הפעולה של npm,‏ git או docker.

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

טעות 3. הוראות ארוכות שלב אחר שלב בתוך CLAUDE.md

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

זה לא המקום להוראות ארוכות שלב אחר שלב. זה המקום לכללים בני שורה אחת. שימו הוראות ארוכות ב-skills/ (מנגנון נפרד של Claude Code שנטען לפי הצורך) או ב-docs/. ב-CLAUDE.md השתמשו בקישור בן שורה אחת: “כשיוצרים מיגרציה חדשה, פתחו את docs/migrations.md.”

טעות 4. כללים שכבר נבדקים בידי מנתח קוד אוטומטי

“השתמש בנקודה-פסיק,” “אל תשאיר import שלא נעשה בו שימוש,” “אל תשתמש ב-var.” ESLint,‏ Prettier ו-Biome מזהים את כל אלה - הם linters (כלים לבדיקה אוטומטית של קוד).

Linter הוא דטרמיניסטי: הוא רץ, מוצא שגיאה ומתקן אותה. כלל ב-CLAUDE.md הוא הסתברותי; הסוכן עלול לשכוח. אין צורך לשכפל אותו - קל יותר להגדיר את ה-linter.

טעות 5. סודות ב-CLAUDE.md

ראיתי סיסמאות של חשבונות בדיקה, טוקנים של API בסביבת sandbox וקישורים ללוחות ניהול מאומתים. הכול היה בקובץ שנשמר ב-git ונטען להקשר של המודל של Anthropic.

לעולם לא. סודות שייכים ל-.env, שנמצא ב-.gitignore. לכל היותר, CLAUDE.md צריך לומר: “אל תקרא את .env כולו; השתמש ב-grep עבור משתנה מסוים.”

טעות 6. קובץ השלכה בן 500+ שורות שלא נוקה במשך שישה חודשים

CLAUDE.md גדל, משכפל מחצית מהתוכן של docs/, סותר את עצמו בכמה מקומות ואיש אינו זוכר מה נמצא בו. הסוכן מתחיל להתעלם מרובו. הצוות מתלונן ש“Claude לא מציית להוראות” ומוסיף עוד כללים, מה שמחמיר את המצב.

סימנים לכך ש-CLAUDE.md הוזנח: יותר מ-300 שורות, כללים חוזרים בחלקים שונים, קישורים מיושנים לקבצים שכבר אינם קיימים והערות “היסטוריות” כמו “ב-2024 החלטנו לעשות את זה כך, ואז שינינו את דעתנו.”

הפתרון: מדי שבועיים בקשו מ-Claude לבדוק אותו לפי המבחן של Anthropic: “אם השורה הזאת תוסר, האם הסוכן יטעה?” מחקו כל דבר שהתשובה לגביו היא “לא.”

טעות 7. CLAUDE.md שנוצר ונשכח

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

סימן מובהק: אתם חוזרים על אותה הוראה בכל סשן. “אל תעשה X,” “אל תיגע ב-Y,” “זכור את Z.” אם חזרתם עליה יותר מפעמיים, מקומה של ההוראה ב-CLAUDE.md, לא בראש שלכם.

איך לגרום ל-CLAUDE.md ללמוד בעצמו באמצעות כלל “עדכון בסוף הסשן”?#

ב-CLAUDE.md שלי יש חלק קצר:

## Self-learning

At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?

If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).

I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.

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

אחרי חודשיים של עבודה כך, יש לי יותר משני תריסר קבצים ב-about-me/feedback/ - כללים שנלמדו מטעויות מסוימות. כל קובץ הוא עמוד אחד בפורמט כלל → למה → איך ליישם. התיקייה הפכה ל“זיכרון שני” שמתעד את ההעדפות והאיסורים האישיים שלי.

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

איך להוסיף כללים משפטיים, שיווקיים ותפעוליים ל-CLAUDE.md?#

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

כשיזם מתחזק CLAUDE.md, הגיוני להוסיף חלקים עסקיים. שלושה חשובים במיוחד:

כללים משפטיים (לשווקים מפוקחים)

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

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

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

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

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

אותה גישה עובדת עבור:

• פרויקטים רפואיים (אין לטעון שמשהו “מטפל” או “מרפא”).
• פרסום תרופות (אין לטעון שהן “היעילות ביותר”; יש לכלול אזהרות נדרשות).
• כל ענף מפוקח אחר שיש לו כללי פרסום משלו.

סגנון שיווקי ופורמט טקסט

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

בעת כתיבת פוסטים לערוץ, עיין ב-style/posts.md. השתמש בסימוני העיצוב שהערוץ מתיר והימנע מתווים מיוחדים “מסוכנים”. סיים ב-CTA עם תג UTM לפי המוסכמה הזאת: utm_source=<channel>&utm_medium=<type>&utm_campaign=<slug>.

בעבר Claude כתב פוסטים ב“סגנון הכללי של אתר שיווקי.” עכשיו הוא פועל לפי הפורמט שלכם, משתמש ב-UTM שלכם ולא מסגיר שהטקסט נכתב בידי AI.

הרגלים תפעוליים

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

“תכנן את השבוע” → פתח את ops/monthly.md, צור YYYY-WNN.md באותה תיקייה והעבר את המשימות מ-ops/backlog.md אל הימים המתאימים. “מה נמצא ברשימת המשימות?” → קרא את ops/backlog.md והצג אותה כרשימה. “סגור את השבוע” → מלא את החלק “סיכום שבוע” בקובץ של השבוע הנוכחי.

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

איך לבדוק את CLAUDE.md לפי רשימת ביקורת בת 12 נקודות בתוך 5 דקות?#

1. גודל. האם הקובץ תמציתי, כשכ-200 שורות הן יעד לבדיקה ולא תקרת עובר/נכשל?
2. שם. האם שמו בדיוק CLAUDE.md באותיות גדולות, ולא claude.md?
3. מיקום. האם הוא בשורש הפרויקט או ב-./.claude/CLAUDE.md?
4. תיאור הפרויקט. האם חמש השורות הראשונות מבהירות מהו הפרויקט ולמי הוא מיועד?
5. כלים. האם הטכנולוגיות מפורטות במפורש וללא מלל מיותר?
6. מבנה. האם יש תרשים של המאגר עם הסברים?
7. ניתוב. האם יש טבלת “שאלה → קובץ” שמראה היכן למצוא תשובות?
8. עקרונות. האם יש חלק עם כללים שמתחילים ב“לעולם לא” וב“תמיד”?
9. ספציפיות. האם אפשר לאמת כל כלל? (“השתמש ב-2 רווחים,” לא “כתוב יפה.”)
10. עדכון עצמי. האם יש כלל ל“בדיקה מה להוסיף בסוף הסשן”?
11. רפלקציה. האם יש כלל ל“תיעוד סיכום הסשן ב-retrospectives/”?
12. אבטחה. האם איסורים קריטיים (.env,‏ rm -rf) מופיעים גם ב-.claude/settings.json?

אם עניתם “לא” יותר מחמש פעמים, פתחו את Claude ותנו לו את ההנחיה הזאת:

Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.

Checklist:

Compact enough for the task; review around 200 lines without treating it as a hard ceiling

Project description in the first 5 lines

Tools listed explicitly

Repository structure diagram included

“Question → file” table included

Principles section with rules included

Every rule is specific and verifiable

“Update at the end of the session” rule included

“Reflect at the end of the session” rule included

Critical prohibitions included in .claude/settings.json

No duplicates of the same rule in different sections

No dangling links to files that no longer exist

After the audit, give me a list of specific changes that will make the file living.

במה להשתמש אחרי CLAUDE.md: Plan Mode, Skills או sub-agents?#

CLAUDE.md הוא הבסיס. ברגע שהוא עובד, תוכלו להוסיף שלושה מנגנונים של Claude Code שמחזקים זה את זה.

Plan Mode. מצב שבו Claude יוצר תחילה תוכנית לשינויים, ממתין לאישור שלכם ורק אז מתחיל לעבוד. מפעילים אותו באמצעות Shift+Tab או הפקודה /plan. הוא מטפל בנקודת הכאב העיקרית של vibe coding: “ביקשתי מ-Claude לתקן דבר אחד, והוא שכתב מחדש חצי מהפרויקט.” זה לא יקרה ב-Plan Mode - אתם רואים את התוכנית לפני שהסוכן נוגע בקבצים.

Skills. קובצי .md נפרדים בתיקיית .claude/skills/ שמכילים ידע לסוג מסוים של משימה. לדוגמה, skill בנושא “איך לכתוב מיגרציה למסד נתונים” מכיל הליך ספציפי, תבנית ודוגמאות. הידע הזה אינו ב-CLAUDE.md כי הוא ארוך מדי. אבל כש-Claude נתקל במשימה כמו “כתוב מיגרציה,” הוא טוען את ה-skill המתאים ופועל לפיו.

Sub-agents. כשמשימה דורשת הרבה הקשר (למשל, סקירת תכונה גדולה), Claude יכול להפעיל sub-agent נפרד בהקשר נקי משלו. ה-sub-agent מבצע את העבודה ומחזיר את התוצאה בלי להעמיס על ההקשר של הצ'אט הראשי.

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

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

אם תרצו לבנות מסגרת שלמה סביב CLAUDE.md - תיקיית business/ למוח שני, תיקיית about-me/ לייצוג דיגיטלי שלכם, skills בסיסיים ו-Plan Mode מוגדר - השתמשו בשלבים ובדוגמאות שבמאמר הזה. מדריכי Ailoot.

המשך עם Ailoot.