מה זה CLAUDE.md? מדריך ודוגמאות לקובץ שקלוד קוד קורא

יש שלוש רמות לעבוד עם קלוד קוד.

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

המדריך הזה לוקח אתכם לרמה 3.

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

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

מה זה קובץ CLAUDE.md ומה הוא עושה?

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

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

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

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

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

איפה נמצא קובץ CLAUDE.md, ואיזה צריך: גלובלי, פרויקט או מקומי?

לרוב האנשים מספיקים שני מיקומים. הקובץ הגלובלי יושב בתיקיית המשתמש, ב-~/.claude/CLAUDE.md במק, וב-%USERPROFILE%\.claude\CLAUDE.md ב-Windows, וחל על כל הפרויקטים במחשב. קובץ הפרויקט, בתיקייה הראשית של הפרויקט, חל רק עליו.

הגלובלי הוא קובץ "הורה": לא משנה מאיזה פרויקט עובדים, הוא נטען. הטבלה המלאה:

הקובץ הארגוני, למי שמנהל צוות:

• במק: /Library/Application Support/ClaudeCode/CLAUDE.md
• ב-Windows: C:\Program Files\ClaudeCode\CLAUDE.md
• ב-Linux: /etc/claude-code/CLAUDE.md

איך בוחרים:

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

אם קלוד אומר ששמר את הקובץ ואתם לא רואים אותו, הטיפים על /memory ועל התיקייה המוסתרת בהמשך פותרים את זה.

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

איך יוצרים קובץ CLAUDE.md, ומה כותבים בו?

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

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

אלה שלושת השלבים, בסדר שאני ממליץ עליו.

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

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

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

Help me write my personal, global CLAUDE.md — the ~/.claude/CLAUDE.md that loads in every project.

First ask me 3 short questions: how to address me, my language and tone, and the one thing agents keep getting wrong for me.

Then write a lean file (under 40 lines): Who I am · Communication · Blanket safety (never delete without asking, no destructive commands, never expose secrets) · My conventions.

Keep every line short and earned from something real. Nothing project-specific. Save it to ~/.claude/CLAUDE.md.

הפרומפט עובד גם ב-Windows, כי קלוד קוד יודע איפה תיקיית המשתמש. מי שמעדיף לכתוב לבד מקליד /memory ובוחר את קובץ המשתמש.

מה כותבים בקובץ?

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

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

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

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

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

Please write a dedicated md file that concludes the latest phase of the project that we worked on, plus your most valuable insights.

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

דוגמה לקובץ גלובלי (~/.claude/CLAUDE.md)

# About me
- I run a small marketing agency. No coding background: explain technical steps in plain language.
- I use Claude Code for content and for client projects.

# Safety
- Never delete files, push code or sign up for anything paid without my direct permission.
- API keys and passwords go in a .env file, never in markdown files.

# How to answer me
- Short answers, in bullets. Plain language.
- Reply in English unless I ask for Hebrew.

התבנית שלי לקובץ פרויקט (./CLAUDE.md)

זו התבנית שבניתי לקובץ פרויקט ושיתפתי בקהילת הוואטסאפ. שומרים אותה כ-CLAUDE.md בתיקייה הראשית, ממלאים את Commands ו-Project, ומוחקים כל שורה שנשארה ריקה.

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

# CLAUDE.md

<!--
How to use this file:
1. Save it as CLAUDE.md in your project root.
2. Fill in the Commands and Project sections. Delete any line you leave empty.
3. Run /context in Claude Code to confirm it loaded.

Keep it under 200 lines. Longer files get followed less — every rule you add makes
every other rule slightly less likely to be followed.

Don't put here: code style (use a linter), things Claude can read from the code
itself (folder structure, dependencies), or hard bans (use permissions.deny).

These comments are stripped before Claude reads the file, so they cost nothing.
-->

## Commands

- Install:
- Dev:
- Test:
- Typecheck:
- Lint:

## Project

<!-- Only what Claude can't figure out by reading the repo. A few lines, no more. -->

- What this is:
- Non-obvious constraint:
- Something we do differently from the default, and why:

---

## Workflow

### 1. Plan first

- Plan mode for any task of 3+ steps or any architectural decision. Skip it for one-liners.
- Keep refining the plan until it's complete, not until it's good enough to start.
- If things go sideways mid-execution, stop and re-plan before writing more code.
- Plan the verification too, not just the build.

### 2. Use subagents

- The point is keeping the main context window clean, not parallelism for its own sake.
- Send research, codebase exploration and parallel analysis to subagents. One task each.
- Subagents come back with conclusions, not transcripts.
- Hard problems get more subagents, not one longer attempt.

### 3. Verify before calling it done

- **IMPORTANT: never report a task as complete without evidence it works.** Tests run,
  logs checked, behavior compared against `main`.
- Verification runs in a fresh subagent — not the one that wrote the code.
- Give that subagent the requirement, the diff and the run commands. Not the conversation.
  It should judge the output, not the intent.
- The bar: would a staff engineer approve this diff as-is?

### 4. Ask for the simpler version

- Before a non-trivial change, pause once: is there a simpler design?
- If a fix feels hacky: "knowing what I know now, what's the clean solution?"
- Skip this for obvious fixes. Deleting lines beats adding lines.

### 5. Fix bugs autonomously

- Bug report, failing test or red CI: reproduce it, find the root cause, fix it, confirm.
- Ask only when blocked on access, a decision, or a genuinely ambiguous requirement.

### 6. Write down corrections

- When I correct you, write the rule down so the mistake doesn't repeat.
- Add it here only once the same correction has come up twice and applies every session.

---

## Ask me first

- Destructive SQL or schema changes — show a rollback plan before running anything.
- Deleting files, `rm -rf`, overwriting uncommitted work.
- `git push --force`, `reset --hard`, amending published commits.
- New dependencies or major version upgrades.
- Anything that stages or commits secrets.
- API calls that cost money or burn rate limits.

---

## Principles

- Simplicity first — the smallest change that solves the problem.
- No laziness — root causes only. No temporary patches, no leftover TODOs.
- Minimal impact — touch only what the task requires.

---

## House rules

<!-- Add a line here whenever a review catches something Claude should have known. -->
<!-- Example: prefer `type` over `interface`; never `enum`, use string literal unions. -->

מה יש בקובץ CLAUDE.md של בוריס צ'רני, היוצר של Claude Code?

שישה סעיפי עבודה, ומתחתם ניהול משימות ושלושה עקרונות ליבה. החלק של Workflow בתבנית למעלה בנוי על אותם סעיפים. ב-14 בספטמבר 2026 פרסמתי פוסט עם החידודים שלי לכל סעיף, ואלה הם.

הראשון, Plan mode כברירת מחדל. כל משימה של שלושה צעדים ומעלה מתחילה בתכנון. ככל שהביצוע עובר למודל, הרבה מהכוח שלכם נמצא בתכנון מדויק, ולכן נתכנן שוב ושוב עד שנגיע לתכנית שהיא 100/100.

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

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

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

תשובת בוריס צ'רני: "verification is probably the single most important thing that people do not get right."

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

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

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

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

מה ההבדל בין CLAUDE.md ל-Skills ול-AGENTS.md?

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

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

מתי סקיל ומתי CLAUDE.md?

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

התקלה הייתה בשרת ה-MCP של n8n שאני עובד איתו. הוא התנתק שוב ושוב, וכל ניתוק כזה לקח לי 40 עד 45 דקות לפתור.

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

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

מה רוב האנשים מפספסים ב-CLAUDE.md? שבעה טיפים

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

הפקודה /memory מוצאת את הקובץ בשבילכם. אין צורך לחפש את התיקייה בכלל, קלוד קוד יודע איפה היא. מקלידים /memory, בוחרים את הקובץ, והוא נפתח בעורך שלכם (גם בלי VS Code). קובץ שעוד לא קיים, הפקודה יוצרת.

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

במק, ב-Finder, הצירוף Cmd+Shift+. מציג ומסתיר קבצים מוסתרים. ב-Windows 11, בסייר הקבצים: תצוגה, הצג, ומסמנים פריטים מוסתרים. אפשר גם להדביק %USERPROFILE%\.claude בשורת הכתובת של הסייר, והתיקייה נפתחת ישר.

עם @ הקובץ נטען תמיד, בלי @ קלוד מחליט. כתיבה של @docs/brand.md בתוך CLAUDE.md מכניסה את כל תוכן הקובץ להקשר כבר בתחילת השיחה. ייבוא מסדר את הקבצים, אבל לא חוסך הקשר.

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

הקובץ שורד את /compact, ההוראות מהשיחה לא תמיד. קובץ ה-CLAUDE.md שבתיקייה הראשית של הפרויקט נקרא מחדש מהדיסק אחרי דחיסה, והוראה שנתתם רק בשיחה עלולה להיעלם.

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

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

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

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

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

איפה CLAUDE.md לא מספיק?

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

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

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

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

הקובץ לא מתעדכן מעצמו. הפתרון שלי הוא סעיף קבוע בקובץ הפרויקט: כל שינוי בקוד, תיקייה חדשה, שרת MCP שחיברת או שינוי ב-settings.json, תעדכן את CLAUDE.md. לתיקונים שלכם, בתבנית יש את סעיף 6 ואת House rules.

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

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

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

שמות ברורים, כמו architecture.md או engineering.md, מקטינים את הסיכון, ולכן אני נותן לכל קובץ הקשר שם שאומר מה יש בו.

לפרויקט קטן אחד מספיקים /init ועוד כמה שורות שכתבתם בעצמכם.

איך נראות 30 הדקות הראשונות שלכם עם CLAUDE.md?

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

דקות 0–5: פותחים את Claude Code בתיקייה הראשית של הפרויקט, ומריצים /init או מבקשים ממנו ליצור CLAUDE.md.

דקות 5–15: קוראים את מה שקלוד כתב. מוחקים כל שורה שלא הייתם רוצים שקלוד יקרא בכל שיחה, ומה שנשאר מסדרים תחת Commands ו-Project, כמו בתבנית.

דקות 15–20: כותבים את הקובץ הגלובלי, עם פרומפט ראיון או דרך /memory. מי אתם, כללי בטיחות, ואיך אתם רוצים תשובות. תקצו לראיון ארבע-חמש דקות.

דקות 20–30: מדביקים לקובץ הפרויקט את Workflow, Ask me first ו-Principles מהתבנית, ומוחקים מה שלא מתאים לפרויקט. אם יש לכם קבצי תיעוד, מוסיפים רשימה ממוספרת שלהם, עם שם ברור לכל אחד. מהשיחה הבאה, כל תיקון שאתם מקלידים בפעם השנייה נכנס ל-House rules או לקובץ הגלובלי.