Hooks — אוטומציה של תהליך העבודה

מה זה Hooks ולמה הם משנים הכל

תדמיין את זה: אתה עובד עם Claude Code על פרויקט React. Claude עורך קובץ, ה-formatting מושלם. יום אחרי, Claude עורך קובץ אחר — ופתאום הקוד לא עומד ב-Prettier. למה? כי Claude הוא probabilistic — הסתברותי. הוא לא מכונה דטרמיניסטית, הוא מודל שפה. לפעמים הוא מפרמט מושלם, לפעמים לא. לפעמים הוא זוכר לבדוק אבטחה, לפעמים לא.

Hooks פותרים את הבעיה הזו. Hook הוא פקודת Shell (או בקשת HTTP) שמופעלת אוטומטית כשאירוע מסוים קורה במהלך סשן של Claude Code. ההוק לא תלוי בשיקול הדעת של Claude — הוא רץ תמיד. בלי יוצא מן הכלל.

חשוב על זה כמו GitHub Actions או CI/CD pipeline, אבל בתוך תהליך העבודה המקומי שלך עם Claude Code. יש trigger (אירוע), יש condition (מתי), ויש action (מה לעשות).

ההבדל בין חיים עם Hooks לחיים בלעדיהם

דוגמאות מייצגות — Hooks בעולם האמיתי

בוא נראה כמה תרחישים מציאותיים שמדגימים למה Hooks הם כל כך חשובים:

תרחיש 1: הפרויקט של אריק — סטארטאפ SaaS
אריק מפתח פלטפורמת ניהול משימות. הוא עובד עם Claude Code 3-4 שעות ביום. לפני Hooks, Claude היה לפעמים מריץ npm run build על סביבת Production בטעות, ופעם אחת עשה git push --force ל-main ומחק commit של שותף. אחרי שהתקין 3 Hooks בסיסיים — Auto-Format, Block Dangerous Commands, ו-Session Logging — הבעיות נעלמו. ההוק הביטחוני חסם 7 פקודות מסוכנות בחודש הראשון. אריק אומר: "זה כמו חגורת בטיחות — אתה לא מרגיש אותה עד שהיא מצילה אותך."

תרחיש 2: צוות הפיתוח של רביד — 5 מפתחים
הצוות של רביד השתמש ב-HTTP Hooks כדי לשלוח כל SessionEnd לדשבורד Grafana מרכזי. ככה הם יודעים כמה שעות Claude עבד, כמה קבצים נערכו, ואילו פקודות רצו. בנוסף, הם הגדירו PreToolUse hook שחוסם כל פקודה שמכילה את המילה "production" — ככה אף Claude של אף מפתח לא יכול לגעת בסביבת Production בטעות.

תרחיש 3: שרה — כותבת תוכן טכני בעברית
שרה משתמשת ב-Claude ליצירת תיעוד ומאמרים בעברית. היא הגדירה PostToolUse hook שבודק כל קובץ .md שנערך: האם מונחים טכניים נשארו באנגלית? האם אין ביטויים "מתורגמים" שנשמעים מלאכותיים? ההוק חוסך לה 15-20 דקות של עריכה ידנית על כל מאמר.

תרחיש 4: חברת SaaS ישראלית — 12 מפתחים
חברת תוכנה בהרצליה עם 12 מפתחים שמשתמשים ב-Claude Code. המנהל הטכני (CTO) הגדיר HTTP Hook מרכזי ששולח כל SessionEnd ו-PostToolUse לדשבורד מבוסס Grafana. בנוסף, PreToolUse hook חוסם כל פקודה שמכילה את המילים "production", "prod-db", או את ה-connection string של מסד הנתונים של Production. תוך חודש, הצוות זיהה שני מפתחים שניסו בטעות להריץ migrations על Production דרך Claude — ההוקים חסמו את שני המקרים. ה-CTO: "בלי Hooks, היה לנו downtime של שעתיים. עם Hooks — אפס."

רגע היסטורי קצר

Hooks הוכנסו ל-Claude Code ב-גרסה 2.0, שיצאה בספטמבר 2025 — יחד עם מערכת ה-Checkpoints, Parallel Agents ו-VS Code Extension. זה היה צעד מהפכני: לראשונה, משתמשים יכלו להוסיף לוגיקה דטרמיניסטית לתהליך העבודה ההסתברותי של AI.

מאז, כל כמה שבועות מתווספים אירועים חדשים: StopFailure הגיע ב-v2.1.78 (מרץ 2026), PostCompact ב-v2.1.76 (מרץ 2026), ו-HTTP Hooks ב-v2.1.63 (פברואר 2026). גם הדרך שבה Hooks מוצגים למשתמש השתפרה — מ-v2.1.75 אפשר לראות מאיזה קובץ settings.json ההוק הגיע, מה שמקל על debugging. המערכת ממשיכה לגדול — ומה שתלמד בפרק הזה יהיה רלוונטי לעוד הרבה זמן.

Hook Lifecycle Events — המפה המלאה

כדי לבנות Hooks טובים, אתה צריך להבין את כל האירועים שזמינים לך. כל אירוע הוא "רגע" בתהליך העבודה של Claude שבו אתה יכול להכניס לוגיקה משלך. נכון למרץ 2026, יש 10 אירועים — 8 אירועי ליבה ו-2 אירועים ייעודיים ל-MCP Elicitation:

כל אירוע בפירוט — מתי ולמה

PreToolUse — ההוק הכי חזק שיש. הוא מופעל לפני ש-Claude קורא לכלי. זה אומר שאתה יכול לבדוק מה Claude עומד לעשות, ואם זה לא בסדר — לחסום. דוגמה קלאסית: Claude רוצה להריץ git push --force main. PreToolUse hook בודק את הפקודה, מזהה "force" + "main", ומחזיר exit 1. הפקודה לא רצה. Claude מקבל הודעה "Hook blocked this action" ומנסה גישה אחרת.

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

SessionStart — רץ פעם אחת כשסשן חדש נפתח. מצוין ל-setup: בדוק שכל ה-dependencies מותקנים, שה-environment variables מוגדרים, שה-database זמין. אם משהו חסר — הציג הודעה ברורה במקום לגלות את זה באמצע העבודה.

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

Notification — רץ כש-Claude שולח notification. אם אתה מריץ Claude ב-background (עם & או דרך Remote Control), זה שימושי לניתוב ההתראות למקום שתראה אותן — Slack, Telegram, desktop notification. דוגמה מעשית: נניח שהרצת Claude לעבוד על refactoring ארוך עם Remote Control מהטלפון. במקום לבדוק כל כמה דקות אם הוא סיים, תגדיר Notification hook שישלח לך הודעה ב-Telegram כשהוא צריך תשומת לב.

{
  "hooks": {
    "Notification": [
      {
        "command": "curl -s -X POST 'https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage' -d \"chat_id=$TELEGRAM_CHAT_ID&text=Claude Code: $CLAUDE_NOTIFICATION_MESSAGE\" &"
      }
    ]
  }
}

Stop — רץ כש-Claude מסיים לייצר תשובה שלמה. שונה מ-PostToolUse — Stop מופעל על התשובה כולה, לא על כלי ספציפי. שימושי למעקב עלויות (כמה tokens השתמשנו?) או ל-triggering של השלב הבא ב-pipeline. דוגמה מעשית: חברת פיתוח שרוצה לעקוב אחרי עלויות שימוש ב-Claude Code — Stop hook שסופר כמה "תשובות" Claude נתן בכל סשן ומדווח לדשבורד.

StopFailure — חדש יחסית (v2.1.78). רץ כש-Claude נתקל בשגיאת API או נכשל להשלים תשובה. זה קריטי ל-resilience: במקום שהסשן נתקע, ההוק יכול לשלוח התראה, לנסות retry, או לשמור את הסטטוס ל-recovery מאוחר יותר.

PostCompact — חדש (v2.1.76). רץ אחרי פעולת /compact. למה זה חשוב? כש-Claude עושה compaction, הוא מוחק חלק מה-context כדי לפנות מקום. ההוק הזה מאפשר לך להזריק מחדש מידע קריטי ששורד את ה-compaction — כמו הוראות עבודה, סטטוס פרויקט, או context חשוב.

Elicitation — חדש (v2.1.76). רץ כשמשרת MCP מבקש מהמשתמש קלט באמצעות דיאלוג אינטראקטיבי. לדוגמה: MCP Server של מסד נתונים שמבקש ממך לבחור טבלה לפני ביצוע שאילתה. ההוק מאפשר לך לבדוק מה נשאל, להזריק ברירות מחדל, או לתעד את הדיאלוג.

ElicitationResult — חדש (v2.1.76). רץ אחרי שהמשתמש השיב ל-Elicitation dialog. שימושי לוולידציה (האם התשובה תקינה?), לוגינג (מה הוזן?), ול-triggering של פעולות המשך. שני אירועי ה-Elicitation רלוונטיים בעיקר למי שעובד עם MCP Servers — נלמד עליהם לעומק בפרק 3 (MCP).

PreToolUse לעומת PostToolUse — מתי להשתמש במה

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

חשוב: Hooks רצים בסביבת ה-Shell שלך

נקודה קריטית שצריך להבין: Hooks רצים מחוץ ל-Sandbox של Claude Code. הם רצים ב-Shell שלך (bash/zsh), עם ההרשאות המלאות שלך. זה אומר שהוק יכול לגשת לכל קובץ במערכת, להריץ כל פקודה, ולשנות כל דבר. זה עוצמתי — וזה מחייב אחריות.

Command Hooks — אוטומציה מבוססת Shell

Command Hooks הם הסוג הבסיסי והנפוץ ביותר. כשאירוע מופעל, Claude Code מריץ פקודת Shell שהגדרת. הפקודה רצה ב-Shell המקומי שלך עם גישה מלאה למערכת הקבצים.

איפה מגדירים Hooks

ההגדרה נמצאת ב-settings.json. יש שתי רמות:

המבנה הבסיסי הוא פשוט. הנה הוק PostToolUse שמריץ prettier אחרי כל עריכת קובץ:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

הרכיבים של Hook

כל הוק מורכב מ-3 חלקים:

1. Event — באיזה אירוע הוא מופעל (PreToolUse, PostToolUse, SessionStart וכו')
2. Matcher (אופציונלי) — מסנן שקובע על אילו כלים ההוק מופעל. "Edit" = רק עריכות. "Bash" = רק פקודות Shell. אם אתה לא מגדיר matcher — ההוק רץ על כל קריאה לכלי
3. Command — פקודת ה-Shell שרצה. יכולה להיות פקודה פשוטה או סקריפט שלם

Environment Variables — המשתנים שזמינים לך

כשההוק רץ, Claude Code מזריק משתני סביבה שמספקים הקשר על מה שקורה:

שים לב: לא כל המשתנים זמינים בכל אירוע. $CLAUDE_FILE_PATH זמין רק כשיש קובץ מעורב (Edit, Write, Read). $CLAUDE_BASH_COMMAND זמין רק כשהכלי הוא Bash. $CLAUDE_SESSION_ID זמין תמיד. כלל אצבע: אם המשתנה ריק — ההוק רץ על אירוע שלא כולל את המידע הזה. תמיד בדוק שהמשתנה לא ריק לפני שאתה משתמש בו.

Exit Code — קוד היציאה משנה הכל

ההוק מחזיר exit code, וזה קובע מה קורה אחר כך:

• exit 0 = הצלחה. ההוק רץ, הכל בסדר, Claude ממשיך לשלב הבא
• exit 1 = כישלון. עבור PreToolUse: הפעולה נחסמת לחלוטין. Claude מקבל הודעה "Hook blocked this action" ויכול לנסות גישה אחרת. עבור PostToolUse: Claude מקבל אזהרה אבל הפעולה כבר קרתה — לא ניתן לבטל

ההבדל הזה הוא קריטי. PreToolUse עם exit 1 הוא שומר סף — הוא מונע את הפעולה לגמרי. PostToolUse עם exit 1 הוא סירנת אזהרה — הוא מתריע, אבל מה שנעשה נעשה.

בפועל, רוב ההוקים שלך יחזירו exit 0. גם הוקים שמזהים בעיות (כמו Brand Voice) עדיפים עם exit 0 + הודעת warning, כי חסימה יכולה להיות מתסכלת. השתמש ב-exit 1 רק כשחסימה היא הכרחית — בעיקר ב-PreToolUse hooks שמגנים על אבטחה.

Hooks על כלי Write — לא רק Edit

חשוב לזכור: Claude משתמש בשני כלים שונים לעבודה עם קבצים. Edit עורך קובץ קיים (מחליף טקסט), ו-Write יוצר קובץ חדש או כותב מחדש קובץ שלם. אם ההוק שלך מגדיר "matcher": "Edit", הוא לא ירוץ כש-Claude יוצר קובץ חדש עם Write. כדי לכסות את שני המקרים, הגדר שני הוקים — אחד ל-Edit ואחד ל-Write:

{
  "hooks": {
    "PostToolUse": [
      {"matcher": "Edit", "command": "bash .claude/hooks/format-on-edit.sh"},
      {"matcher": "Write", "command": "bash .claude/hooks/format-on-edit.sh"}
    ]
  }
}

או, אם אתה רוצה שההוק ירוץ על כל כלי (כולל Read, Bash, Glob ועוד) — פשוט אל תגדיר matcher בכלל. אבל זה בדרך כלל לא מה שאתה רוצה — אין טעם לפרמט קובץ אחרי שקראו אותו.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "echo \"$(date '+%H:%M:%S') EDIT: $CLAUDE_FILE_PATH\" >> /tmp/claude-hooks.log"
      }
    ]
  }
}

HTTP Hooks — אינטגרציה מבוססת Webhooks

מאז 28 בפברואר 2026 (גרסה 2.1.63), Hooks יכולים לשלוח בקשות HTTP במקום להריץ פקודות Shell. זה פותח עולם שלם של אינטגרציות: שליחת נתונים ל-Slack, n8n, Make, Zapier, דשבורד מותאם, או כל שירות שמקבל webhooks.

ההבדל בין Command Hook ל-HTTP Hook

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "url": "https://your-server.com/claude-hook"
      }
    ]
  }
}

מה נשלח בבקשת ה-HTTP

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

• allow (boolean) — האם לאפשר את הפעולה (רלוונטי ל-PreToolUse)
• message — הודעה שתוצג ל-Claude
• modifiedInput — אפשרות לשנות את ה-input של הכלי (למשל, להוסיף flags לפקודת Bash)

מתי להשתמש ב-HTTP Hooks

HTTP Hooks מצטיינים ב-4 תרחישים עיקריים:

1. לוגינג מרכזי לצוות — כל חברי הצוות שולחים Hook data לדשבורד אחד. אפשר לראות מה כל מפתח עושה עם Claude
2. תהליכי אישור — PreToolUse HTTP Hook שדורש אישור ממנהל לפני deploy. השרת בודק אם יש אישור, ומחזיר allow: true/false
3. אינטגרציה עם n8n / Zapier / Make — כל אירוע Claude Code מפעיל workflow חיצוני. למשל: SessionEnd שולח סיכום ל-Slack
4. אכיפת מדיניות מרכזית — במקום שכל מפתח יגדיר Hooks מקומיים, יש שרת מרכזי שמגדיר מה מותר ומה אסור

דוגמה מעשית: חיבור ל-n8n

אם יש לך instance של n8n (כלי אוטומציה self-hosted), אתה יכול לחבר Claude Code ישירות ל-workflows שלך. הנה דוגמה שמדווחת לצוות ב-Slack כשסשן מסתיים:

1. ב-n8n: צור workflow חדש עם Webhook trigger. העתק את ה-webhook URL
2. ב-settings.json: הגדר HTTP Hook:

   {
     "hooks": {
       "SessionEnd": [
         {
           "url": "https://n8n.your-domain.com/webhook/claude-session-end"
         }
       ]
     }
   }

3. ב-n8n: הוסף node של Slack/Telegram שמקבל את ה-data מהוובהוק ושולח הודעה: "Claude Code session ended. Duration: X minutes. Files modified: Y"

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

HTTP Hooks לעומת curl ב-Command Hook — מה עדיף?

יש דרך נוספת לשלוח webhooks: במקום HTTP Hook "רשמי", אתה יכול להשתמש ב-Command Hook שמריץ curl:

{
  "hooks": {
    "SessionEnd": [
      {
        "command": "curl -s -X POST 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK' -d '{\"text\":\"Claude session ended\"}' &"
      }
    ]
  }
}

שני ההבדלים החשובים:

כלל אצבע: אם אתה צריך שהשרת יגיד ל-Claude מה לעשות (allow/block, modify input) — השתמש ב-HTTP Hook. אם אתה רק שולח מידע החוצה (logging, notifications) — Command Hook עם curl ב-background פשוט יותר ומהיר יותר.

הוק מעשי: Auto-Format בכל עריכה

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

הוק לשפה אחת

אם אתה עובד בשפה אחת, ההגדרה פשוטה:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "ruff format $CLAUDE_FILE_PATH"
      }
    ]
  }
}

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "gofmt -w $CLAUDE_FILE_PATH"
      }
    ]
  }
}

הוק מרובה שפות — הסקריפט הנכון

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

#!/bin/bash
# .claude/hooks/format-on-edit.sh
# Auto-format based on file extension

FILE="$CLAUDE_FILE_PATH"
EXT="${FILE##*.}"

case "$EXT" in
  js|jsx|ts|tsx|json|css|html|md)
    prettier --write "$FILE" 2>/dev/null
    ;;
  py)
    ruff format "$FILE" 2>/dev/null
    ;;
  go)
    gofmt -w "$FILE" 2>/dev/null
    ;;
  rs)
    rustfmt "$FILE" 2>/dev/null
    ;;
  *)
    # Unknown extension — do nothing
    exit 0
    ;;
esac

exit 0

ואז ב-settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "bash .claude/hooks/format-on-edit.sh"
      }
    ]
  }
}

שים לב לכמה פרטים חשובים בסקריפט:

• 2>/dev/null — מנתב שגיאות stderr לכלום. אם prettier לא מותקן, או אם הקובץ לא ניתן לפירמוט — ההוק לא יקרוס
• ${FILE##*.} — זה bash parameter expansion שמחלץ את הסיומת מנתיב הקובץ. לדוגמה, /src/App.tsx יחזיר tsx
• exit 0 בסוף — ההוק תמיד מצליח. כשלון בפירמוט לא צריך לעצור את Claude. זו בחירה מכוונת: אנחנו רוצים "best effort" formatting, לא חסימה
• הענף *) — Default case. אם הסיומת לא מוכרת (למשל קובץ .yaml), ההוק פשוט יוצא בהצלחה בלי לעשות כלום

בעיות נפוצות עם Auto-Format

הוק Auto-Format הוא פשוט ליצירה, אבל יש כמה מלכודות שכדאי להכיר:

בעיה: ההוק רץ על קבצי Lock. אם Claude עורך package-lock.json ואתה מריץ prettier עליו, התוצאה עלולה לשבור את ה-lock file. הפתרון: הוסף exclusion ב-prettier config (בקובץ .prettierignore) או בסקריפט עצמו.

בעיה: פירמוט מתנגש עם ה-edit. לעתים נדירות, prettier יכול לשנות את הקובץ באופן שגורם ל-Claude "לאבד" את ההקשר של מה שהוא עורך. זה קורה בעיקר עם קבצים גדולים. אם אתה רואה התנהגות מוזרה — נסה להוסיף השהייה קצרה: sleep 0.1 && prettier --write "$FILE".

בעיה: הפורמטר לא מותקן. אם prettier לא מותקן בפרויקט, ההוק ייכשל בשקט (בזכות 2>/dev/null). זה מתוכנן — אבל כדאי להוסיף בדיקה ב-SessionStart hook שמתריעה אם הפורמטר חסר.

הוק מעשי: חסימת פקודות מסוכנות

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

מה חוסמים — ומה לא

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

הסקריפט — block-dangerous.sh

#!/bin/bash
# .claude/hooks/block-dangerous.sh
# PreToolUse hook for Bash — blocks dangerous commands

CMD="$CLAUDE_BASH_COMMAND"

# ===== TIER 1: ALWAYS BLOCK =====
BLOCKED_PATTERNS=(
  "rm -rf /"
  "rm -rf ~"
  "DROP TABLE"
  "DROP DATABASE"
  "git push --force main"
  "git push --force master"
  "git push -f origin main"
  "git push -f origin master"
  "chmod 777"
  "mkfs\."
  "> /dev/sda"
)

for pattern in "${BLOCKED_PATTERNS[@]}"; do
  if echo "$CMD" | grep -qi "$pattern"; then
    echo "BLOCKED: Command matches dangerous pattern '$pattern'" >&2
    echo "If intentional, run this command manually outside Claude Code." >&2
    exit 1
  fi
done

# ===== TIER 2: WARN BUT ALLOW =====
WARN_PATTERNS=(
  "sudo "
  "rm -rf"
  "--force"
  "--hard"
)

for pattern in "${WARN_PATTERNS[@]}"; do
  if echo "$CMD" | grep -qi "$pattern"; then
    echo "WARNING: Potentially risky command detected: $pattern" >&2
    # Log it, but allow
    echo "$(date '+%Y-%m-%d %H:%M:%S') WARN: $CMD" >> .claude/logs/security.log
  fi
done

# ===== TIER 3: LOG ALL BASH COMMANDS =====
echo "$(date '+%Y-%m-%d %H:%M:%S') CMD: $CMD" >> .claude/logs/commands.log

exit 0

ואז ב-settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "bash .claude/hooks/block-dangerous.sh"
      }
    ]
  }
}

גישה מתקדמת: קובץ Blocklist חיצוני

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

# .claude/blocked-commands.txt
# One pattern per line. Lines starting with # are comments.
rm -rf /
DROP TABLE
DROP DATABASE
git push --force main
chmod 777

הסקריפט קורא את הקובץ:

while IFS= read -r pattern || [[ -n "$pattern" ]]; do
  [[ "$pattern" =~ ^#.*$ ]] && continue  # Skip comments
  [[ -z "$pattern" ]] && continue         # Skip empty lines
  if echo "$CMD" | grep -qi "$pattern"; then
    echo "BLOCKED: $pattern" >&2
    exit 1
  fi
done < .claude/blocked-commands.txt

היתרון: כל חבר צוות יכול להוסיף דפוסים ל-blocklist בלי לגעת בסקריפט. זה גם אומר שאפשר לשמור את ה-blocklist ב-git ולעשות Code Review על שינויים בו — בדיוק כמו כל קוד אחר.

חשיבה על False Positives

ההוק חוסם פקודה שמכילה "DROP TABLE" — אבל מה אם Claude כותב תיעוד שמזכיר את המונח? או מה אם יש פקודה לגיטימית שכוללת "force" (כמו --force-publish ב-Lerna)?

הפתרון: היה ספציפי בדפוסים. במקום לחסום כל מופע של "force", חסום את השילוב "git push --force main". במקום לחסום "DROP", חסום את השילוב "DROP TABLE" או "DROP DATABASE". ככל שהדפוס יותר ספציפי — פחות false positives.

דרך נוספת: אם ההוק חוסם פקודה שאתה צריך להריץ, הודעת החסימה אומרת לך "If intentional, run this command manually outside Claude Code." זה כיוון חשוב — Claude לא צריך להריץ פקודות מסוכנות. אם הפקודה לגיטימית, אתה תריץ אותה בעצמך בטרמינל.

הוספת הגנה על Credentials

סוג נוסף של חסימה שכדאי להוסיף: פקודות שמכילות credentials או secrets. למשל, אם Claude מנסה להריץ פקודה שמכילה API key בטקסט — זה בעייתי, כי הפקודה תופיע ב-bash history, בלוגים, ואולי אפילו ב-git.

# Block commands that contain what looks like API keys
if echo "$CMD" | grep -qE "(sk-[a-zA-Z0-9]{20,}|AKIA[A-Z0-9]{16}|ghp_[a-zA-Z0-9]{36})"; then
  echo "BLOCKED: Command appears to contain an API key or secret." >&2
  echo "Use environment variables instead of hardcoded credentials." >&2
  exit 1
fi

הוק מעשי: אכיפת Brand Voice

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

הגישה הפשוטה: בדיקת Grep

הדרך הכי מהירה — סקריפט שמחפש מילים ודפוסים אסורים:

#!/bin/bash
# .claude/hooks/brand-check.sh
# PostToolUse hook on Edit/Write — checks brand guidelines

FILE="$CLAUDE_FILE_PATH"

# Only check content files (not code)
case "$FILE" in
  *.md|*.txt|*.html) ;;
  *) exit 0 ;;
esac

# Forbidden terms
FORBIDDEN=(
  "click here"
  "synergy"
  "leverage"
  "disrupt"
  "game-changer"
)

for term in "${FORBIDDEN[@]}"; do
  if grep -qi "$term" "$FILE"; then
    echo "BRAND WARNING: Found forbidden term '$term' in $FILE" >&2
    echo "Please replace with approved terminology." >&2
  fi
done

exit 0  # Warn but don't block

הגישה לתוכן עברי

כשאתה מייצר תוכן בעברית עם Claude, יש בדיקות ספציפיות שכדאי לעשות:

• מונחים טכניים — צריכים להישאר באנגלית (SEO, CRM, API), לא "אופטימיזציה למנועי חיפוש"
• שפה "מתורגמת" — ביטויים שנשמעים כמו תרגום ממכונה צריכים להיפסל
• טון — פנייה ישירה (אתה/את), לא טון אקדמי (יש לציין כי)

# Patterns that indicate "machine translation" Hebrew
BAD_HEBREW=(
  "יש לציין כי"
  "ניתן לראות כי"
  "באופן משמעותי"
  "מומלץ בחום"
  "הינו"
  "הנו"
)

for term in "${BAD_HEBREW[@]}"; do
  if grep -q "$term" "$FILE"; then
    echo "STYLE: '$term' sounds like machine translation. Rewrite naturally." >&2
  fi
done

הגישה המתקדמת: בדיקה מבוססת מודל

grep מצוין לזיהוי מילים ספציפיות, אבל הוא לא מבין הקשר. הביטוי "synergy" יכול להיות בדוגמה של "מה לא לכתוב" — ו-grep יחסום אותו בכל זאת. אם אתה רוצה בדיקה אמיתית של טון ואיכות, אתה יכול לשלוח את התוכן למודל AI מהיר וזול (כמו Haiku) לקבלת חוות דעת:

#!/bin/bash
# brand-check-ai.sh — Advanced brand check using Claude Haiku
# CAUTION: This costs tokens! Use only for final checks, not on every edit.

FILE="$CLAUDE_FILE_PATH"
CONTENT=$(cat "$FILE" | head -500)  # First 500 lines

VERDICT=$(echo "$CONTENT" | curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -d "{
    \"model\": \"claude-haiku-4-5\",
    \"max_tokens\": 100,
    \"messages\": [{\"role\": \"user\", \"content\": \"Check if this Hebrew content follows brand guidelines: natural tone (not academic), technical terms in English, no machine-translation patterns. Reply only PASS or FAIL with one line explanation.\n\n$CONTENT\"}]
  }" | jq -r '.content[0].text')

if echo "$VERDICT" | grep -q "FAIL"; then
  echo "BRAND CHECK FAILED: $VERDICT" >&2
fi

exit 0  # Always pass — brand check is advisory

הגישה הזו עולה כ-$0.001-0.005 לכל בדיקה (תלוי באורך התוכן). זול, אבל מצטבר. לכן: grep לבדיקות תכופות (כל עריכה), model-based לבדיקות סופיות (לפני פרסום). לעולם אל תריץ בדיקת מודל על כל Edit — זה ישחוק את התקציב שלך.

הוק מעשי: Session Logging ו-Audit Trail

זו אחת מהתועלות הגדולות של Hooks — לדעת בדיוק מה Claude עשה. אם אתה עובד לבד, זה שימושי לדיבוג ומעקב. אם אתה עובד בצוות, זה הכרחי ל-compliance ולהבנה מה קורה.

ארכיטקטורת הלוגינג — 3 הוקים

הלוגינג המלא דורש שלושה Hooks שעובדים ביחד:

{
  "hooks": {
    "SessionStart": [
      {
        "command": "mkdir -p .claude/logs && echo '=== SESSION START ===' >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log && echo \"Time: $(date)\" >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log && echo \"Project: $(pwd)\" >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log && echo \"Session: $CLAUDE_SESSION_ID\" >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log && echo '---' >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log"
      }
    ],
    "PostToolUse": [
      {
        "command": "echo \"$(date '+%H:%M:%S') [$CLAUDE_TOOL_NAME] $CLAUDE_FILE_PATH\" >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log"
      }
    ],
    "SessionEnd": [
      {
        "command": "echo '=== SESSION END ===' >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log && echo \"End: $(date)\" >> .claude/logs/session-$(date +%Y-%m-%d-%H%M).log"
      }
    ]
  }
}

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

#!/bin/bash
# .claude/hooks/session-logger.sh
# Usage: session-logger.sh [start|tool|end]

LOG_DIR=".claude/logs"
LOG_FILE="$LOG_DIR/session-$(date +%Y-%m-%d).log"
mkdir -p "$LOG_DIR"

case "$1" in
  start)
    echo "" >> "$LOG_FILE"
    echo "========================================" >> "$LOG_FILE"
    echo "SESSION START: $(date '+%Y-%m-%d %H:%M:%S')" >> "$LOG_FILE"
    echo "Project: $(pwd)" >> "$LOG_FILE"
    echo "Session ID: $CLAUDE_SESSION_ID" >> "$LOG_FILE"
    echo "========================================" >> "$LOG_FILE"
    ;;
  tool)
    echo "  $(date '+%H:%M:%S') [$CLAUDE_TOOL_NAME] $CLAUDE_FILE_PATH" >> "$LOG_FILE"
    ;;
  end)
    echo "========================================" >> "$LOG_FILE"
    echo "SESSION END: $(date '+%Y-%m-%d %H:%M:%S')" >> "$LOG_FILE"
    echo "========================================" >> "$LOG_FILE"
    ;;
esac

exit 0

ואז ב-settings.json:

{
  "hooks": {
    "SessionStart": [{"command": "bash .claude/hooks/session-logger.sh start"}],
    "PostToolUse": [{"command": "bash .claude/hooks/session-logger.sh tool"}],
    "SessionEnd": [{"command": "bash .claude/hooks/session-logger.sh end"}]
  }
}

מה הלוג מספק לך

אחרי יום עבודה, הקובץ ייראה משהו כזה:

========================================
SESSION START: 2026-03-23 09:15:22
Project: /home/user/my-project
Session ID: sess_abc123
========================================
  09:15:30 [Read] /home/user/my-project/src/App.tsx
  09:16:45 [Edit] /home/user/my-project/src/App.tsx
  09:16:46 [Bash]
  09:18:12 [Edit] /home/user/my-project/src/utils/api.ts
  09:19:30 [Write] /home/user/my-project/src/types/user.ts
  09:22:01 [Bash]
========================================
SESSION END: 2026-03-23 09:25:44
========================================

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

שימושים מתקדמים של Session Logging

מעקב עלויות: אם אתה מוסיף ללוג את מספר ה-tool calls, אתה יכול לחשב עלויות משוערות. כל tool call = קריאה ל-API = tokens. עם logging טוב, אתה יודע אילו סשנים היו "יקרים" ולמה.

Compliance בצוותים: בסביבות מוסדרות (fintech, healthcare, govtech), תיעוד של מה AI עשה בקוד הוא דרישה. Session logs מספקים audit trail מלא — מי הריץ, מתי, מה שונה, ומה הפלט.

דיבוג: "למה הקוד נראה ככה?" שבוע אחרי סשן ארוך, אתה מסתכל על קובץ ולא מבין למה הוא נראה ככה. פותח את הלוג ורואה: "14:23:05 [Edit] src/api.ts" — Claude ערך את הקובץ. עכשיו אתה יודע לחפש ב-git log מה שונה.

שליחה לדשבורד: לצוותים, שילוב של HTTP Hook על SessionEnd ששולח סיכום ל-Grafana, Datadog, או אפילו Google Sheet פשוט (דרך Apps Script webhook) — נותן visibility מלא על השימוש ב-Claude Code בצוות.

הוק מעשי: PostCompact — שמירה על context קריטי

כש-Claude עובד על משימה ארוכה, חלון ה-context (context window) מתמלא. כשהוא מגיע ל-80% קיבולת, מופעלת אוטומטית פעולת compaction — Claude דוחס את השיחה כדי לפנות מקום. הבעיה: ב-compaction, מידע חשוב יכול "ללכת לאיבוד". פרטי משימה, הוראות ספציפיות, מידע על סביבת הפרויקט — הכל יכול להימחק.

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

איך לבנות PostCompact Hook

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

# .claude/critical-context.txt
# ================================
# מידע שחייב לשרוד compaction:
# ================================
Current task: Building payment integration API
Test command: npm run test:payments
Deploy restriction: NEVER push directly to main
Key file: src/services/payments.ts
API endpoint: https://api.staging.example.com
Database: Use test DB only (never prod)

#!/bin/bash
# .claude/hooks/inject-context.sh
# PostCompact hook — re-inject critical context after compaction

if [ -f .claude/critical-context.txt ]; then
  echo "=== CRITICAL CONTEXT (restored after compaction) ==="
  cat .claude/critical-context.txt
  echo "==================================================="
fi
exit 0

ב-settings.json:

{
  "hooks": {
    "PostCompact": [
      {"command": "bash .claude/hooks/inject-context.sh"}
    ]
  }
}

עכשיו, בכל פעם ש-Claude עושה compaction — או שאתה מריץ /compact ידנית — המידע הקריטי מוזרק מחדש. Claude "זוכר" את מה שחשוב, גם אחרי ניקוי ה-context.

Hooks ב-Agent ו-Skill Frontmatter

מאז גרסה 2.1.0 (ינואר 2026), Hooks יכולים להיות מוגדרים גם בתוך ה-YAML frontmatter של קובצי Agent ו-Skill. זה אומר שכל Skill יכול להביא איתו את ההוקים שלו — הם פעילים רק כשה-Skill רץ, ומתבטלים כשהוא נגמר.

למה זה חשוב

בלי Frontmatter Hooks, אתה צריך הוקים גלובליים שרצים על הכל. זה בעייתי כי:

• הוק Brand Voice לא צריך לרוץ כשאתה כותב קוד
• הוק Auto-Deploy לא צריך לרוץ כשאתה כותב תיעוד
• הוק בדיקת עברית לא צריך לרוץ כשאתה כותב באנגלית

עם Frontmatter Hooks, כל Skill מביא את ההוקים שלו. ה-content-writer skill מביא הוק Brand Voice. ה-deploy skill מביא הוק בדיקת tests. כל אחד פעיל רק כשהוא צריך.

איך זה עובד

---
name: content-writer
description: Writes marketing content in Hebrew
hooks:
  PostToolUse:
    - matcher: Edit
      command: bash .claude/hooks/brand-check.sh
    - matcher: Write
      command: bash .claude/hooks/brand-check.sh
---

# Content Writer Skill
Write marketing content following our brand guidelines...

Framework: "Layered Hooks" — שכבות של הוקים

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

חשוב: Frontmatter hooks רצים בנוסף להוקים הגלובליים והפרויקטיים. הם לא מחליפים אותם. הוק אבטחה גלובלי תמיד ירוץ, גם אם ל-Skill אין הוקים משלו.

דוגמה מעשית: Skill ל-Deploy עם הוקים

תדמיין שיש לך Skill ששמו /deploy. הוא מריץ את תהליך ה-deployment של הפרויקט. אתה רוצה שלפני כל deploy יהיה בדיקת tests מלאה, ואחרי ה-deploy תשלח הודעה ל-Slack:

---
name: deploy
description: Deploy the project to production
hooks:
  PreToolUse:
    - matcher: Bash
      command: npm test
  PostToolUse:
    - matcher: Bash
      command: |
        if echo "$CLAUDE_BASH_COMMAND" | grep -q "deploy"; then
          curl -s -X POST "$SLACK_WEBHOOK" \
            -d '{"text":"Deploy completed for $(basename $(pwd))"}'
        fi
---

# Deploy Skill
Deploy the current project to production.
1. Run all tests first
2. Build the project
3. Deploy to production server
4. Verify deployment is healthy

ההוקים האלה פעילים רק כשאתה מריץ /deploy. כשאתה עובד רגיל — הם לא קיימים. זו הנקודה: hooks ברמת Skill הם "קוד שנוסע עם ה-workflow" — לא עומס שרץ כל הזמן.

בפרק הבא (פרק 2 — Custom Agents) נלמד לבנות agents ו-skills מאפס. מה שחשוב להבין כאן: Hooks הם לא רק עניין של settings.json. הם חלק אינטגרלי ממערכת ה-Skills וה-Agents של Claude Code.

Debugging Hooks — כשמשהו לא עובד

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

בעיות נפוצות ופתרונות

שיטת הדיבוג: "Echo First"

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

#!/bin/bash
# Add this as the FIRST LINE of any hook during debugging:
echo "HOOK FIRED: tool=$CLAUDE_TOOL_NAME file=$CLAUDE_FILE_PATH" >> /tmp/claude-hooks-debug.log

# ... rest of your hook logic

טסט ידני — הרץ את ההוק בעצמך

אתה לא חייב לחכות ל-Claude כדי לבדוק הוק. הרץ אותו ידנית מהטרמינל:

# Set the environment variables Claude would set:
export CLAUDE_FILE_PATH="/path/to/test-file.ts"
export CLAUDE_TOOL_NAME="Edit"
export CLAUDE_BASH_COMMAND="npm test"
export CLAUDE_SESSION_ID="test-session"

# Run the hook:
bash .claude/hooks/format-on-edit.sh
echo "Exit code: $?"

אם ההוק עובד בטרמינל אבל לא בתוך Claude Code — הבעיה היא בהגדרת ה-settings.json או בסביבת ההרצה.

הפקודה /doctor

Claude Code כולל פקודה מובנית — /doctor — שבודקת בעיות נפוצות בהגדרות, כולל Hooks. אם אתה חושד שמשהו לא תקין, הרץ /doctor ובדוק את הפלט.

Hook Source Display

מאז גרסה 2.1.75, כש-Claude מבקש הרשאה לפעולה, הוא גם מציג מאיזה קובץ settings.json ההוק הגיע. זה עוזר מאוד כשיש לך הוקים ברמה גלובלית וגם ברמת פרויקט — ופתאום משהו נחסם ואתה לא יודע למה. ה-source display אומר לך: "ההוק הזה הגיע מ-~/.claude/settings.json" או "מ-.claude/settings.json" — ואתה יודע לאיפה לגשת כדי לתקן.

Troubleshooting Flow — שלב אחרי שלב

כשהוק לא עובד כצפוי, עבור על הרשימה הזו בסדר:

1. בדוק שהקובץ settings.json תקין: הרץ python3 -m json.tool .claude/settings.json — אם יש שגיאת syntax, הקובץ כולו לא ייקרא
2. בדוק שהסקריפט executable: ls -la .claude/hooks/format-on-edit.sh — צריך לראות -rwxr-xr-x
3. בדוק שהסקריפט רץ בעצמו: הרץ אותו ידנית מהטרמינל עם export של משתני הסביבה
4. הוסף echo ראשון: שורה ראשונה בסקריפט: echo "HOOK ALIVE" >> /tmp/hook-test.log
5. בדוק ב-Claude Code: בקש מ-Claude לעשות פעולה שצריכה להפעיל את ההוק
6. בדוק את הלוג: cat /tmp/hook-test.log — אם יש "HOOK ALIVE", ההוק רץ
7. אם ההוק לא רץ: בדוק matcher (case sensitive!), בדוק event type, בדוק נתיב הסקריפט
8. אם ההוק רץ אבל לא עובד: הבעיה בלוגיקה — דבג את הסקריפט עצמו

הדגל --bare — כשאתה רוצה לדלג על Hooks

מאז גרסה 2.1.81 (מרץ 2026), אפשר להריץ Claude Code עם הדגל --bare. מה הוא עושה? הוא מדלג על כל ההוקים, וגם על LSP, plugins, וסריקת תיקיית Skills. התוצאה: הפעלה מהירה בהרבה, בלי "תקורת" אוטומציה.

למה זה חשוב להבין?

אם אתה בונה מערכת Hooks מורכבת, אתה צריך לדעת שיש מצב שבו היא לא תרוץ. --bare משמש בעיקר ב-CI/CD pipelines ובסקריפטים אוטומטיים שבהם מהירות חשובה יותר מאכיפה:

# CI/CD pipeline — hooks לא רצים כאן
claude -p "run all tests and report results" --bare

# עבודה רגילה — hooks רצים כרגיל
claude

הנקודה: אם אתה מסתמך על Hooks לאבטחה (חסימת פקודות מסוכנות), דע ש---bare עוקף את ההגנה הזו. ב-CI/CD זה בסדר — שם יש לך הגנות אחרות (permissions, read-only repos). אבל אם מישהו בצוות מריץ --bare על מכונה מקומית כדי לעקוף הוקים — זו בעיה. ודא שה---bare משמש רק לאוטומציה, לא כ-"דרך עוקפת".

# עם hooks (רגיל):
claude -p "echo hello"

# בלי hooks (bare):
claude -p "echo hello" --bare

דפוסים מתקדמים

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

1. Chained Hooks — שרשור הוקים

אפשר להגדיר מספר הוקים על אותו אירוע. הם רצים בסדר שהם מוגדרים:

{
  "hooks": {
    "PostToolUse": [
      {"matcher": "Edit", "command": "bash .claude/hooks/format-on-edit.sh"},
      {"matcher": "Edit", "command": "bash .claude/hooks/lint-check.sh"},
      {"matcher": "Edit", "command": "bash .claude/hooks/brand-check.sh"}
    ]
  }
}

הסדר: format → lint → brand check. אם הוק אחד נכשל (exit 1), ההוקים הבאים עדיין ירוצו (חוץ מ-PreToolUse, שם exit 1 חוסם את הפעולה עצמה).

2. Conditional Hooks — הוקים מותנים לפי סוג קובץ

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

#!/bin/bash
# .claude/hooks/smart-check.sh
# Runs different checks based on file type

EXT="${CLAUDE_FILE_PATH##*.}"

case "$EXT" in
  ts|tsx)
    npx tsc --noEmit "$CLAUDE_FILE_PATH" 2>/dev/null
    ;;
  py)
    mypy "$CLAUDE_FILE_PATH" 2>/dev/null
    ;;
  go)
    go vet "$CLAUDE_FILE_PATH" 2>/dev/null
    ;;
esac

exit 0

3. Stateful Hooks — הוקים עם זיכרון

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

#!/bin/bash
# .claude/hooks/edit-counter.sh
# Run tests every 10 edits

COUNTER_FILE="/tmp/claude-edit-count"
COUNT=$(cat "$COUNTER_FILE" 2>/dev/null || echo 0)
COUNT=$((COUNT + 1))
echo "$COUNT" > "$COUNTER_FILE"

if [ $((COUNT % 10)) -eq 0 ]; then
  echo "Running tests after $COUNT edits..."
  npm test 2>/dev/null
fi

exit 0

4. Cross-Session Hooks — המשכיות בין סשנים

SessionEnd hook ששומר סיכום, ו-SessionStart hook שקורא אותו — יוצרים "זיכרון" בין סשנים:

# SessionEnd: save what we worked on
echo "$(date): Worked on $CLAUDE_FILE_PATH" >> .claude/last-session.txt

# SessionStart: remind what we did last time
if [ -f .claude/last-session.txt ]; then
  echo "=== Last session summary ==="
  tail -5 .claude/last-session.txt
  echo "==========================="
fi

5. Rate-Limiting Hooks — הגבלת קצב

מנע מ-Claude לבצע יותר מדי פעולות בזמן קצר. שימושי במיוחד לפקודות Bash שגישת ל-APIs חיצוניים:

#!/bin/bash
# .claude/hooks/rate-limit.sh
# Block if more than 5 Bash commands in last 60 seconds

LIMIT_FILE="/tmp/claude-rate-limit"
NOW=$(date +%s)
WINDOW=60
MAX=5

# Clean old entries
touch "$LIMIT_FILE"
awk -v cutoff=$((NOW - WINDOW)) '$1 > cutoff' "$LIMIT_FILE" > "${LIMIT_FILE}.tmp"
mv "${LIMIT_FILE}.tmp" "$LIMIT_FILE"

# Count recent commands
COUNT=$(wc -l < "$LIMIT_FILE")
if [ "$COUNT" -ge "$MAX" ]; then
  echo "RATE LIMIT: Too many commands ($COUNT in last ${WINDOW}s). Slow down." >&2
  exit 1
fi

echo "$NOW" >> "$LIMIT_FILE"
exit 0

6. Hooks שמשנים את ה-Input של Claude

PreToolUse hook לא חייב רק לחסום — הוא יכול גם לשנות את מה ש-Claude עומד לעשות. על ידי כתיבת output מסוים ל-stdout בפורמט שמוגדר, ההוק יכול לשנות את ה-input של הכלי. לדוגמה: אם Claude עומד להריץ npm install package, ההוק יכול להוסיף --save-exact באופן אוטומטי.

זהו pattern מתקדם שדורש הבנה של הפורמט שבו Claude Code מצפה לקבל את ה-modified input. הוא שימושי במיוחד לאכיפת conventions — למשל, לוודא שכל git commit כולל signing, או שכל docker run כולל --rm.

מתי כדאי ומתי לא כדאי להשתמש בדפוסים מתקדמים

Frameworks להחלטות — איזה הוק, איפה, ומתי

שגרת עבודה — Hooks שוטף

Best Practices לתחזוקת Hooks

אחרי שבועות של עבודה עם Hooks, הנה כמה best practices שנלמדו מניסיון:

1. כל הוק בקובץ נפרד. במקום inline commands ב-settings.json, שמור כל הוק כסקריפט ב-.claude/hooks/. זה מאפשר version control, debugging קל יותר, ושימוש חוזר
2. הוסף comments בסקריפטים. שורה ראשונה: מה ההוק עושה. שורה שנייה: על איזה event הוא רץ. עתיד-אתה יודה לך
3. בדוק הוקים ב-CI/CD. אם ההוקים שלך ב-git, הוסף בדיקה שמוודאת שהם syntactically valid: bash -n .claude/hooks/*.sh
4. נקה לוגים ישנים. קבצי לוג גדלים. הוסף הוק SessionStart שמנקה לוגים ישנים מלפני 30 יום
5. תעד את ההוקים. צור .claude/hooks/README.md עם תיאור קצר של כל הוק — מה הוא עושה, למה הוא קיים, ואיך לבטל אותו אם צריך

#!/bin/bash
# .claude/hooks/cleanup-logs.sh
# Runs on SessionStart — cleans logs older than 30 days

find .claude/logs -name "*.log" -mtime +30 -delete 2>/dev/null
exit 0

הכל ביחד — settings.json שלם ומוכן

הנה דוגמה מלאה של .claude/settings.json שמשלב את כל ההוקים שלמדנו בפרק הזה. זה ה-baseline שלך — הנקודה שממנה אתה ממשיך לבנות:

{
  "hooks": {
    "SessionStart": [
      {
        "command": "bash .claude/hooks/session-logger.sh start"
      },
      {
        "command": "bash .claude/hooks/cleanup-logs.sh"
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "bash .claude/hooks/block-dangerous.sh"
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "bash .claude/hooks/format-on-edit.sh"
      },
      {
        "matcher": "Write",
        "command": "bash .claude/hooks/format-on-edit.sh"
      },
      {
        "command": "bash .claude/hooks/session-logger.sh tool"
      }
    ],
    "PostCompact": [
      {
        "command": "bash .claude/hooks/inject-context.sh"
      }
    ],
    "SessionEnd": [
      {
        "command": "bash .claude/hooks/session-logger.sh end"
      }
    ]
  }
}

שים לב לסדר ולמבנה: SessionStart כולל לוגינג + ניקוי לוגים ישנים. PreToolUse כולל חסימת פקודות מסוכנות. PostToolUse כולל שלושה הוקים — שניים עם matcher (format on Edit/Write) ואחד בלי matcher (logging כל tool use). PostCompact מזריק context קריטי אחרי compaction. SessionEnd סוגר את הלוג. הלוגינג רץ על כל כלי — כולל Read, Bash, Grep — בלי קשר ל-matcher. זה מכוון: אנחנו רוצים לתעד הכל.

סיכום קבצים בתיקיית .claude/hooks/

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

תרגילים מעשיים

בדוק את עצמך — האם עברת את פרק 1?

צ'קליסט — סיכום פרק 1

• מבין מה Hooks הם ולמה הם חשובים (deterministic vs probabilistic)
• מכיר את כל 10 אירועי Lifecycle: PreToolUse, PostToolUse, SessionStart, SessionEnd, Notification, Stop, StopFailure, PostCompact + Elicitation, ElicitationResult (MCP)
• יודע את ההבדל בין Command Hook ל-HTTP Hook ומתי להשתמש בכל אחד
• יצרתי קובץ .claude/settings.json עם לפחות הוק אחד עובד
• בניתי הוק Auto-Format שמפרמט קוד אוטומטית על כל Edit
• בניתי הוק חסימת פקודות מסוכנות (PreToolUse על Bash)
• בניתי מערכת Session Logging (SessionStart + PostToolUse + SessionEnd)
• מבין את Framework "Layered Hooks": גלובלי, פרויקטי, Skill
• יודע לדבג Hooks: שיטת Echo First, טסט ידני, /doctor
• מכיר Frontmatter Hooks ומתי להשתמש בהם
• מכיר דפוסים מתקדמים: Chained, Conditional, Stateful, Cross-Session, Rate-Limiting
• מבין מתי Hooks לא רצים: מצב --bare ב-CI/CD מדלג על כל ההוקים
• בדקתי את כל ה-3 הוקים שבניתי — כולם עובדים ומתועדים
• יש לי שגרת עבודה: בדיקה יומית של לוגים, סקירה שבועית, עדכון חודשי
• מוכן לפרק הבא — Custom Agents ו-Subagents

סיכום הפרק