איך להשתמש ב-Claude Code כמו מפתח אמיתי

הרעיון שמאחורי הכל - המודל הוא רק המנוע

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

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

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

מה זה Context Window

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

מה תופס מקום על השולחן הזה? הרבה יותר ממה שרואים על המסך:

• הוראות המערכת של הכלי עצמו, שאתם אף פעם לא רואים.

• קובצי CLAUDE.md והכללים שנטענו בתחילת הסשן.

• רשימת השמות והתיאורים של כל הסקילים הזמינים.

• כל הודעה בשיחה - שלכם ושל Claude.

• כל קובץ שהוא קרא וכל פלט של פקודה שהוא הריץ.

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

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

שלוש פקודות שמנהלות את ההקשר

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

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

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

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

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

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

CLAUDE.md ופקודת init - התדרוך הקבוע של הפרויקט

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

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

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

מה נכנס לקובץ ומה לא

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

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

• ארכיטקטורה - מה יושב איפה, ואיך רכיבים מדברים ביניהם.

• קונבנציות - סגנון קוד, מוסכמות שמות, מבנה שמות הענפים והודעות הקומיט.

• מלכודות - הדברים שנראים הגיוניים אבל שגויים בפרויקט הזה דווקא.

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

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

שלושה מקומות שבהם הקובץ יכול להימצא

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

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

כך נראה קובץ פרויקט קצר ויעיל:

# MyShop

## Commands
- npm run dev    - dev server
- npm test       - run tests
- npm run lint   - lint

## Architecture
- Next.js App Router, SCSS Modules per component
- All API routes call authenticate(req) before querying

## Conventions
- Named exports only
- Branch format: saar/DP-<num>-short-description
- Never commit without running lint

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

ההבדל בין Skills ל-Rules

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

Rules - הוראות שתמיד נטענות בתחילת ה-Session

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

הכוח האמיתי שלהם הוא ביכולת להחיל אותם על נתיבים מסוימים. כלל עם שדה paths ב-frontmatter (הבלוק בראש הקובץ בין שני קווי מקף) נטען רק כש-Claude נוגע בקובץ שתואם לתבנית:

---
paths:
  - "src/api/**/*.ts"
---

# API Rules
- Every endpoint must validate its input
- Use the standard error response format
- Include OpenAPI comments on each route

התוצאה: כשאני עובד על רכיב תצוגה, הכללים של שכבת ה-API בכלל לא תופסים מקום. כשאני נוגע בקובץ תחת src/api, הם נטענים לבד. כך נחסך מקום ב-Context Window בלי לוותר על שום הוראה.

Skills - תהליכי עבודה שנטענים לפי דרישה

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

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

---
name: commit
description: Full commit workflow. Use when wrapping up a feature,
  or when the user says "let's wrap this up".
---

## Step 1: Read the diff and understand what changed
## Step 2: Run the verify-changes skill
## Step 3: Write a commit message in the project format
## Step 4: Commit and push - only if all checks passed

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

למה ההפרדה הזו כל כך משנה

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

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

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

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

מה זה Hooks ולמה הם חשובים

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

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

• PreToolUse - רץ לפני ש-Claude מפעיל כלי. שימושי לחסימת פעולות, למשל פקודות מחיקה מסוכנות.

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

• Stop - רץ כש-Claude מסיים את התשובה. מצוין לשליחת התראה כשמשימה ארוכה הסתיימה.

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

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write"
          }
        ]
      }
    ]
  }
}

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

תנו ל-Claude הקשר חזותי

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

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

מתי זה הכי משתלם:

• באגים חזותיים - יישור, מרווחים, גלישת טקסט, התנהגות במסכים צרים.

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

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

• שגיאות - צילום של הקונסולה או של מסך השגיאה, כולל מה שמסביב.

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

הדרך הנכונה לבנות פרומפטים

זה אולי הטיפ הכי לא טכני במאמר, והוא זה שחוסך לי הכי הרבה זמן.

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

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

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

כך נראה פרומפט חלש:

Fix the login page.

ואותה בקשה אחרי שההסבר בעברית הפך לפרומפט מסודר:

Users report that after a failed login attempt, the error message
disappears as soon as they start typing again, so they lose the reason
it failed.

Goal: keep the error visible until a new submit happens.

Constraints:
- Do not change the auth API contract
- Error text must stay screen-reader accessible
- Follow the existing form-state pattern in the repo

Before writing code: find where login form state is handled and explain
what you plan to change.

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

הכלל הכללי: תנו הקשר, לא רק הוראה. במקום "תבנה לי מסך ניהול", הסבירו מה הבעיה שהמסך פותר, מי המשתמש ומה חשוב לו. ככל שיש יותר הקשר, כך גדל הסיכוי שההחלטות הקטנות - שאתם לא תכתיבו ממילא - יהיו נכונות. אם מעניין אתכם איך ניסוח משפיע על התנהגות המודל ברמה העמוקה, כתבתי על כך במאמר על Functional Emotions ו-Prompt Engineering.

בחירת המודל ורמת המאמץ

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

לצד בחירת המודל יש בורר נוסף, פחות מוכר אבל חשוב לא פחות: רמת המאמץ (effort level). היא נעה בין low ל-max, ולא קובעת רק "כמה המודל חושב" - היא משפיעה גם על כמה קבצים הוא יקרא, עד כמה יאמת את עבודתו וכמה רחוק יתקדם במשימה מרובת שלבים לפני שיחזור אליכם. ההמלצה הרשמית היא להישאר ברמת ברירת המחדל של המודל ברוב המקרים, ולשנות אותה רק כשיש סיבה.

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

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

הרגלי עבודה שמשנים את התוצאה

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

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

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

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

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

• סשן חדש למשימה חדשה - אני מריץ את הפקודה clear בין משימות לא קשורות. זה מחזיר אותנו לנקודה הראשונה: הקשר ממוקד מנצח הקשר גדול.

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

סיכום

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

• CLAUDE.md - העובדות הקבועות של הפרויקט. יוצרים אותו באמצעות init, ורצוי לשמור על אורך של פחות מ-200 שורות.

• Rules - כללי "תמיד תעשה X", מפוצלים לקבצים ומוחלים על נתיבים כדי לחסוך מקום ב-Context Window.

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

• Hooks - אכיפה אוטומטית לדברים שחייבים לקרות תמיד.

• compact, clear ו-context - שליטה יומיומית במה שנמצא על השולחן.

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

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

שאלות נפוצות על עבודה עם Claude Code

מהו קובץ CLAUDE.md ולמה הוא חשוב

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

מה ההבדל בין Rules ל-Skills ב-Claude Code

Rules הם קובצי הוראות בתיקיית .claude/rules שנטענים לתוך ההקשר בתחילת כל סשן, או רק כשנפתח קובץ תואם אם הוגדר להם שדה paths. הם מתאימים להוראות מסוג "תמיד תעשה X". Skills הם תהליכי עבודה שנשמרים בקובץ SKILL.md בתיקיית .claude/skills. רק השם והתיאור של כל סקיל נטענים מראש, ואילו הגוף המלא נטען רק כשהסקיל מופעל. לכן תהליך מרובה-שלבים כמו קומיט, בדיקת נגישות או דיפלוי צריך להיות סקיל ולא כלל.

מתי כדאי להשתמש ב-Hooks במקום בהוראות טקסט

כשההתנהגות חייבת להתרחש תמיד. הוראה ב-CLAUDE.md היא הנחיה ש-Claude קורא ומנסה לקיים, אבל הוא עלול לדלג עליה. הוק הוא סקריפט שמוגדר בקובץ settings.json ורץ אוטומטית באירוע קבוע - למשל PreToolUse לפני שימוש בכלי, PostToolUse אחריו או Stop כשהמשימה מסתיימת. Claude לא יכול לעקוף אותו, ולכן הוקים מתאימים לעיצוב אוטומטי של הקוד, להרצת לינטר, לבדיקות ולהתראות.

מהו Context Window ולמה צריך את הפקודה compact

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

איזה מודל של Claude כדאי לבחור לכל משימה

Haiku מתאים למשימות מהירות ופשוטות, Sonnet מתאים לרוב עבודת הפיתוח היומיומית, Opus מתאים לבעיות שדורשות חשיבה עמוקה כמו החלטות ארכיטקטוניות, באגים סמויים וסקירת קוד רחבה, ו-Fable מתאים למשימות ארוכות ואוטונומיות. הכלל המעשי של Anthropic הוא שכאשר משהו נכשל, כדאי לשאול אם המודל לא ידע מספיק - ואז צריך מודל חזק יותר - או שלא התאמץ מספיק, ואז צריך להעלות את רמת המאמץ.

איך כותבים פרומפט טוב ל-Claude Code

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