Headless Mode and CLI Automation — מצב ללא ממשק ואוטומציה בשורת הפקודה

מ-Interactive ל-Headless — שינוי הפרדיגמה

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

Headless mode (מצב ללא ממשק, נקרא גם CLI mode או Print mode) מסיר את הבן אדם מהמשוואה לחלוטין. Claude מקבל פקודה, מריץ, מייצר פלט, ויוצא. אין back-and-forth, אין אישורים, אין ממשק. זה ההבדל בין לדבר עם עובד לבין לתת לו מעטפה עם הוראות ולקבל את התוצאה מוכנה על השולחן.

למה זה כל כך חשוב? כי כל מה שתלמדו בקורס הזה — CI/CD pipelines, GitHub Actions, SDK-based agents, automated testing, scheduled monitoring — הכל מבוסס על היכולת של Claude Code לרוץ בלי בן אדם. בלי Headless mode, אין אוטומציה.

המעבר המנטלי — מ-"משתמש" ל-"אדריכל"

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

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

תרחיש 1: חברת SaaS ישראלית בהרצליה — 8 מפתחים. לפני Headless mode, כל מפתח היה צריך לזכור להריץ code review ידנית לפני PR. חלק שכחו. עכשיו, כל PR מפעיל אוטומטית claude -p "review this diff" --bare דרך GitHub Actions. התוצאה: 100% כיסוי review, אפס שכחות, עלות של כ-15 ש״ח ביום.

תרחיש 2: מפתח freelancer שעובד על 6 פרויקטים. כל בוקר ב-08:00, cron job רץ על כל 6 הפרויקטים ומייצר "morning briefing" — סיכום שינויים מאתמול, TODO items פתוחים, בעיות אבטחה חדשות. המפתח פותח את הבוקר עם תמונת מצב ברורה בלי לפתוח Claude אפילו פעם אחת.

תרחיש 3: צוות DevOps שמנהל 20 שרתים. כל שעה, watchdog script רץ עם claude -p ומנתח את מטריקות השרתים. אם משהו חריג — Slack alert. בחודש הראשון, המערכת תפסה דליפת זיכרון שהייתה גורמת ל-downtime תוך 12 שעות.

הדגל -p — הכניסה לעולם ה-Headless

הדגל -p (קיצור של print) הוא הכלי הבסיסי ביותר ל-Headless mode. המכניקה פשוטה: הוא שולח prompt ל-Claude, מקבל תשובה ב-stdout (ערוץ הפלט הרגיל של כל תוכנית), ומחזיר exit code (קוד יציאה שמציין הצלחה או כישלון). זה הכל. אין back-and-forth, אין שיחה, אין ממשק.

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

שימוש בסיסי

# שימוש בסיסי — שלח prompt, קבל תשובה
claude -p "analyze this codebase and list all TODO comments"

# לכוד את התוצאה במשתנה
RESULT=$(claude -p "summarize README.md")
echo "$RESULT"

# שמור לקובץ
claude -p "generate a .gitignore for a Node.js project" > .gitignore

# הוסף לקובץ קיים (append)
claude -p "generate 5 test cases for the login function" >> tests.md

# שילוב עם conditional logic
claude -p "run tests and report" && echo "Success" || echo "Issues found"

שימו לב למבנה: claude -p "הפרומפט שלכם". כמה נקודות חשובות:

• ה-prompt חייב להיות מוקף בגרשיים (כפולות או בודדות). גרשיים כפולות ("...") מאפשרות שימוש במשתנים: claude -p "review $FILENAME"
• אין הגבלה על אורך ה-prompt, אבל prompt ארוך = יותר tokens = יותר עלות
• Claude Code כן יכול לקרוא קבצים מהפרויקט גם ב-Headless — הוא משתמש בכלי Read, Grep, Glob כרגיל
• הפלט הולך ל-stdout. הודעות שגיאה ו-debug הולכות ל-stderr. זה אומר ש-claude -p "..." > output.txt ישמור רק את התוצאה, לא את הודעות השגיאה

דגלים שמשתלבים עם -p

הדגל -p לא עומד לבד — יש לו "חברים" שמרחיבים את הפונקציונליות:

Exit Codes — השפה של האוטומציה

בעולם ה-CLI, exit codes (קודי יציאה) הם הדרך שבה תוכניות מדווחות על הצלחה או כישלון. כל תוכנית שמסיימת מחזירה מספר — וזה מה שסקריפטים משתמשים בו כדי לקבל החלטות. Claude Code מחזיר:

• 0 — הצלחה. Claude קיבל את ה-prompt, עיבד, והחזיר תשובה תקינה
• Non-zero (1, 2, וכו׳) — כישלון. אפשרויות: API key לא תקין, שגיאת רשת, rate limit, prompt שנחסם, בעיה פנימית

למה זה חשוב? כי בסקריפטים אתם משתמשים ב-exit codes כדי לקבל החלטות אוטומטיות:

# אם Claude מצליח — המשך. אם נכשל — עצור והתריע
claude -p "run all tests and report results" --bare && echo "All good" || {
    echo "[ERROR] Claude failed — check API key and connectivity" >&2
    exit 1
}

# בדיקת exit code מפורשת
claude -p "validate config.json" --bare
if [ $? -ne 0 ]; then
    echo "Validation failed!"
    # שלח email, webhook, Slack message...
fi

הדגל --bare — מהירות מקסימלית ל-CI/CD

הדגל --bare הוכנס בגרסה 2.1.81 (מרץ 2026) ועוצב במיוחד לאוטומציה. הוא חייב לשמש יחד עם -p — אי אפשר להשתמש בו במצב אינטראקטיבי:

claude -p "your prompt here" --bare

מה הרעיון? כשאתם מריצים claude -p רגיל, Claude Code עובר תהליך initialization שלם: טוען Hooks, מפעיל Language Server, מסנכרן Plugins, סורק Skills directories, קורא/כותב Auto-Memory. כל אלה חשובים במצב אינטראקטיבי — אבל בסקריפט שרץ 100 פעמים ביום, כל אלה הם overhead מיותר.

מה --bare מדלג עליו ומה לא

שימו לב לנקודה הקריטית: CLAUDE.md עדיין נטען גם במצב --bare. הוראות הפרויקט שלכם חלות גם באוטומציה. זה חשוב — אם הגדרתם ב-CLAUDE.md כללים כמו "always use TypeScript", "never modify the /prod directory", או "use Israeli date format" — הכללים האלה בתוקף גם ב---bare. זה by design: Anthropic רוצים שהסטנדרטים של הפרויקט שלכם ישמרו גם באוטומציה.

אימות: --bare דורש ANTHROPIC_API_KEY

הגבלה חשובה: במצב --bare, אימות OAuth/Keychain לא זמין. חייבים להשתמש באחת מהאפשרויות:

• ANTHROPIC_API_KEY כמשתנה סביבה — הדרך הנפוצה ביותר
• סקריפט apiKeyHelper שמחזיר מפתח טרי — לסביבות Enterprise עם key rotation

זה הגיוני — ב-CI/CD ובסקריפטים אוטומטיים, אין מי שיאשר OAuth login אינטראקטיבי.

מתי להשתמש ב---bare ומתי לא

לא כל הרצה Headless צריכה --bare. יש מקרים שבהם אתם רוצים שה-Hooks ירוצו:

• כן --bare: CI/CD pipelines, cron jobs, סקריפטים שרצים עשרות פעמים ביום, Docker containers, embedded one-off calls
• לא --bare: אוטומציות שצריכות את ה-Hooks שלכם (למשל: auto-format hook אחרי כל עריכה), או שצריכות plugins (למשל: MCP server לגישה ל-database)

JSON Output — פלט מובנה לאוטומציה

כברירת מחדל, -p מחזיר טקסט חופשי — כמו שהייתם קוראים בשיחה אינטראקטיבית. אבל לאוטומציה אתם צריכים פלט מובנה (structured) שקוד יכול לפרסר (לפרק). טקסט חופשי הוא שביר — Claude יכול לשנות קצת את הפורמט ולשבור לכם את כל ה-parsing. JSON, לעומת זאת, הוא פורמט מובנה עם שדות מוגדרים.

כאן נכנס הדגל --output-format json:

claude -p "list all bugs in this file" --output-format json

הפלט הוא אובייקט JSON עם metadata שימושי:

{
  "result": "הטקסט של התשובה של Claude — התוכן שהייתם מקבלים בלי --output-format json",
  "tokens_used": 1247,
  "cost": 0.0037,
  "model": "claude-opus-4-6",
  "duration": 4.2
}

שימו לב: שדה result מכיל את התוכן. cost מכיל את העלות בדולרים. tokens_used מספר ה-tokens. duration זמן ההרצה בשניות. המידע הזה הוא זהב לניטור ומעקב עלויות.

פירוק JSON ב-Shell עם jq

jq הוא כלי שורת הפקודה הסטנדרטי לעיבוד JSON. אם הוא לא מותקן אצלכם: sudo apt install jq (Linux) או brew install jq (macOS).

# חלצו רק את התוצאה (הטקסט)
claude -p "summarize this code" --output-format json | jq -r '.result'

# חלצו את העלות
COST=$(claude -p "analyze main.py" --output-format json | jq '.cost')
echo "This run cost: \$$COST"

# תנאי על בסיס העלות — עצרו אם ההרצה יקרה מדי
claude -p "deep analysis" --output-format json | jq -e '.cost < 0.10' > /dev/null && echo "Within budget" || echo "OVER BUDGET!"

# חלצו את מספר ה-tokens
claude -p "review code" --output-format json | jq '.tokens_used'

פירוק JSON ב-Python

import subprocess
import json

result = subprocess.run(
    ["claude", "-p", "list all TODO comments in the project", "--output-format", "json"],
    capture_output=True, text=True, timeout=120
)

if result.returncode != 0:
    print(f"Error: {result.stderr}")
else:
    data = json.loads(result.stdout)
    print(f"Result: {data['result']}")
    print(f"Cost: ${data['cost']:.4f}")
    print(f"Tokens: {data['tokens_used']}")
    print(f"Duration: {data['duration']:.1f}s")

פירוק JSON ב-TypeScript / Node.js

import { execFile } from 'child_process';
import { promisify } from 'util';

const execFileAsync = promisify(execFile);

async function runClaude(prompt: string) {
  const { stdout } = await execFileAsync('claude', [
    '-p', prompt, '--output-format', 'json'
  ], { timeout: 120000 });

  const data = JSON.parse(stdout);
  console.log(`Result: ${data.result}`);
  console.log(`Cost: $${data.cost.toFixed(4)}`);
  return data;
}

runClaude('list TODOs in the project');

שתי שכבות JSON — הטריק החזק

טריק חשוב: גם בתוך ה-prompt, אפשר לבקש מ-Claude להחזיר JSON מובנה. ככה מקבלים שתי שכבות של מבנה — ה-wrapper JSON של --output-format json (עם cost, tokens, duration), ובתוכו JSON מובנה שאתם הגדרתם:

# שתי שכבות: wrapper JSON + תוכן JSON
claude -p "scan all .py files for security issues. Return ONLY a JSON array of objects with keys: file, line, severity, message. No explanation, just the JSON array." --output-format json | jq -r '.result' | jq '.'

# דוגמה לפלט הפנימי (שדה result):
# [
#   {"file": "auth.py", "line": 42, "severity": "critical", "message": "SQL injection risk"},
#   {"file": "api.py", "line": 87, "severity": "warning", "message": "Missing input validation"}
# ]

Shell Scripting עם Claude Code

Claude Code משתלב בצורה טבעית בסקריפטים של bash/zsh. חשבו עליו כמו על כל כלי CLI אחר — הוא מקבל קלט (prompt + piped data), נותן פלט (stdout), ומחזיר exit code. אפשר לשרשר אותו עם כלים אחרים בדיוק כמו grep, awk, או curl.

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

דפוס 1: The Validator (המאמת)

Claude בודק משהו ומחזיר verdict — pass/fail, YES/NO, OK/PROBLEM. זה הדפוס הבסיסי ביותר:

#!/bin/bash
set -euo pipefail

# בדיקת אבטחה על PR diff — אם יש בעיה, חסום את ה-deploy
DIFF=$(git diff HEAD~1)
REVIEW=$(echo "$DIFF" | claude -p "review this code diff for security vulnerabilities. If you find CRITICAL issues, start your first line with the word CRITICAL. If everything is safe, start with OK. Then explain." --bare)

FIRST_WORD=$(echo "$REVIEW" | head -1 | cut -d' ' -f1)
if [ "$FIRST_WORD" = "CRITICAL" ]; then
    echo "SECURITY ALERT: Blocking deployment!"
    echo "$REVIEW"
    exit 1
else
    echo "Security check passed."
fi

דפוס 2: The Generator (המייצר) — Claude מייצר תוכן חדש שנשמר לקובץ:

#!/bin/bash
set -euo pipefail
source ~/.claude-env.sh

# יצירת migration SQL
claude -p "generate a PostgreSQL migration SQL for adding a 'status' column (VARCHAR(20), DEFAULT 'active', NOT NULL) to the users table. Output ONLY valid SQL, no explanation, no markdown fences." --bare > migrations/002_add_status.sql

echo "Migration created: migrations/002_add_status.sql"
echo "Content:"
cat migrations/002_add_status.sql

דפוס 3: The Analyzer (המנתח) — Claude מנתח נתונים קיימים ומפיק תובנות:

#!/bin/bash
set -euo pipefail

# סיכום שינויים ל-release notes — בעברית
git log --oneline HEAD~10..HEAD | claude -p "summarize these git commits into release notes. Group by: Features (תכונות חדשות), Bug Fixes (תיקוני באגים), Improvements (שיפורים). Write in Hebrew. Use markdown format." --bare > RELEASE_NOTES.md

echo "Release notes generated!"

דפוס 4: The Decision Maker (מקבל ההחלטות) — Claude מחזיר YES/NO פשוט לתנאי בסקריפט:

#!/bin/bash
set -euo pipefail

# האם הקוד מוכן ל-deploy?
VERDICT=$(claude -p "review the test results in test-output.log. Answer ONLY the single word 'YES' or 'NO': is this safe to deploy to production?" --bare | tr -d '[:space:]')

if [ "$VERDICT" = "YES" ]; then
    echo "AI approved deployment. Proceeding..."
    ./deploy.sh
else
    echo "AI blocked deployment. Manual review required."
    exit 1
fi

Piping Data INTO Claude — הזרמת נתונים

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

# ניתוח לוגים — מצא דפוסי שגיאות
cat error.log | claude -p "analyze these error logs. Group by error type, count occurrences of each, and suggest the fix for the most common error. Hebrew." --bare

# סיכום קובץ קוד
cat src/main.ts | claude -p "explain what this code does in 3 sentences. Hebrew." --bare

# ניתוח תלויות
npm ls --depth=0 2>&1 | claude -p "identify any deprecated or potentially vulnerable packages in this dependency list" --bare

# ניתוח docker containers
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | claude -p "are all containers healthy? Report any issues." --bare

שלד הסקריפט — The Script Skeleton

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

#!/bin/bash
set -euo pipefail  # מצב קפדני: עצור על שגיאות, משתנים לא מוגדרים, pipe failures

# ========== 1. SETUP ==========
source ~/.claude-env.sh  # טען API key ומשתני סביבה
TIMEOUT=120              # timeout בשניות
OUTPUT_DIR="./reports"
DATE=$(date +%Y%m%d-%H%M)
mkdir -p "$OUTPUT_DIR"

# ========== 2. RUN CLAUDE ==========
RESULT=$(timeout $TIMEOUT claude -p "your prompt here" --bare --output-format json 2>"$OUTPUT_DIR/stderr-$DATE.log")
EXIT_CODE=$?

# ========== 3. CHECK EXIT CODE ==========
if [ $EXIT_CODE -ne 0 ]; then
    echo "[ERROR] Claude failed with exit code $EXIT_CODE" >&2
    echo "[ERROR] stderr: $(cat "$OUTPUT_DIR/stderr-$DATE.log")" >&2
    exit 1
fi

# ========== 4. PARSE OUTPUT ==========
CONTENT=$(echo "$RESULT" | jq -r '.result')
COST=$(echo "$RESULT" | jq '.cost')

# ========== 5. ACT ON RESULT ==========
echo "$CONTENT" > "$OUTPUT_DIR/report-$DATE.md"
echo "[INFO] Report generated: $OUTPUT_DIR/report-$DATE.md"
echo "[INFO] Cost: \$$COST"

Batch Processing — עיבוד קבצים במקביל

Batch Processing (עיבוד אצווה) הוא הרצת אותה פעולה על קבוצה שלמה של קבצים. במקום להריץ Claude על כל קובץ ידנית — אתם כותבים סקריפט שעובר על כולם, אחד אחרי השני או כמה במקביל.

עיבוד סדרתי — קובץ אחרי קובץ

הגישה הפשוטה ביותר — for loop:

#!/bin/bash
source ~/.claude-env.sh

# הוספת docstrings לכל קבצי Python בתיקייה
for f in src/*.py; do
    echo "[INFO] Processing: $f"
    claude -p "add comprehensive docstrings to every function and class in this file. Keep all existing code unchanged. Return ONLY the modified file content, nothing else." --bare < "$f" > "${f}.new"

    # וולידציה בסיסית: הקובץ החדש לא ריק
    if [ -s "${f}.new" ]; then
        mv "${f}.new" "$f"
        echo "[DONE] $f — updated successfully"
    else
        rm -f "${f}.new"
        echo "[WARN] $f — empty output, skipped"
    fi
done

עיבוד מקבילי עם xargs

מהיר יותר — מריצים כמה קבצים בו-זמנית:

# 4 קבצים במקביל
find . -name "*.py" -type f | xargs -P 4 -I {} bash -c '
    echo "[INFO] Processing: {}"
    claude -p "add type hints to all function signatures in this file. Return ONLY the file content." --bare -m sonnet < "{}" > "{}.typed"
    if [ -s "{}.typed" ]; then
        mv "{}.typed" "{}"
        echo "[DONE] {}"
    else
        rm -f "{}.typed"
        echo "[WARN] {} — skipped"
    fi
'

/batch — הכלי המובנה של Claude Code

Claude Code מגיע עם skill מובנית בשם /batch שעושה batch processing ברמה אחרת לגמרי. במקום לולאה פשוטה, /batch:

• חוקר את ה-codebase ומבין את המבנה
• מחלק את העבודה ליחידות (עד 30 יחידות מקביליות)
• מפעיל agent עצמאי לכל יחידה, כל אחד ב-git worktree נפרד
• כל agent מריץ tests ופותח Pull Request

מתי להשתמש ב-/batch לעומת לולאה ידנית?

ניהול עלויות — ה-Dry Run Pattern

עיבוד אצווה יכול לעלות כסף ברצינות. 50 קבצים x $0.05 לקובץ = $2.50 (כ-9 ש״ח). 500 קבצים = $25 (כ-90 ש״ח). הנה הדרך הנכונה:

#!/bin/bash
source ~/.claude-env.sh

# שלב 1: DRY RUN — עבדו על 3 קבצים, בדקו איכות + עלות
echo "=== DRY RUN: 3 files ==="
TOTAL_COST=0
for f in $(find src/ -name "*.ts" -type f | head -3); do
    RESULT=$(claude -p "add JSDoc to all exports" --bare --output-format json -m sonnet < "$f")
    COST=$(echo "$RESULT" | jq '.cost // 0')
    TOTAL_COST=$(echo "$TOTAL_COST + $COST" | bc)
    echo "  $f — cost: \$$COST"
done

FILE_COUNT=$(find src/ -name "*.ts" -type f | wc -l)
ESTIMATED=$(echo "$TOTAL_COST / 3 * $FILE_COUNT" | bc -l | head -c 6)
echo "Estimated total cost for $FILE_COUNT files: \$$ESTIMATED"
echo "Proceed? (y/n)"
read -r ANSWER
[ "$ANSWER" = "y" ] || exit 0

# שלב 2: FULL RUN — רק אחרי אישור
echo "=== FULL RUN ==="
# ... (הלולאה המלאה)

Environment Variables והגדרות

ב-Headless mode, משתני סביבה (Environment Variables) הם הדרך העיקרית להגדיר את ההתנהגות של Claude Code. אין ממשק גרפי, אין /config אינטראקטיבי — הכל דרך ENV vars. זה ההבדל בין "יישום שולחני" ל-"כלי שרת".

משתני הסביבה הקריטיים

הירארכיית ההגדרות

קובץ .claude-env.sh — המפתח לסדר

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

#!/bin/bash
# ~/.claude-env.sh — DO NOT COMMIT TO GIT!
# הוסיפו ל-.gitignore!

export ANTHROPIC_API_KEY="sk-ant-api03-your-key-here"
export CLAUDE_MODEL="claude-sonnet-4-6"
export MAX_THINKING_TOKENS="8192"

# הגדרות ספציפיות לפרויקט (אופציונלי)
export CLAUDE_PROJECT="my-saas-app"
export CLAUDE_OUTPUT_DIR="./claude-reports"

ואז בכל סקריפט — שורה אחת:

#!/bin/bash
source ~/.claude-env.sh
# ... מכאן כל הסקריפט ...

apiKeyHelper — לסביבות Enterprise

בחברות גדולות שמחליפות מפתחות API (key rotation), אפשר להגדיר סקריפט שמחזיר מפתח טרי בכל קריאה:

// .claude/settings.json
{
  "apiKeyHelper": "/usr/local/bin/get-claude-key.sh"
}

// get-claude-key.sh — מחזיר מפתח מ-AWS SSM:
#!/bin/bash
aws ssm get-parameter --name "/claude/api-key" --with-decryption \
    --query "Parameter.Value" --output text

Claude Code קורא ל-apiKeyHelper לפני כל הרצה ומקבל מפתח עדכני. ככה אין צורך לעדכן ידנית כשהמפתח מתחלף.

Cron Jobs ותהליכים מתוזמנים

כל מה שלמדנו עד עכשיו — -p, --bare, JSON output, סקריפטים — מקבל ערך אמיתי כשהוא רץ אוטומטית, על לוח זמנים. במקום שתזכרו להריץ סריקת אבטחה כל בוקר — cron job עושה את זה בשבילכם. בכל יום, בכל שעה, בכל שבוע — אתם קובעים.

Cron — הבסיס

cron הוא scheduler מובנה בלינוקס. תחביר: minute hour day month weekday command.

# ערכו את ה-crontab
crontab -e

# סריקת אבטחה יומית ב-08:00
0 8 * * * source /home/user/.claude-env.sh && cd /home/user/myproject && claude -p "scan codebase for new security vulnerabilities" --bare > /home/user/myproject/reports/security-$(date +\%Y\%m\%d).md 2>&1

# סיכום שבועי כל יום ראשון ב-09:00
0 9 * * 0 source /home/user/.claude-env.sh && cd /home/user/myproject && git log --oneline --since="7 days ago" | claude -p "create a weekly dev summary from these commits. Hebrew." --bare > /home/user/myproject/reports/weekly-$(date +\%Y\%m\%d).md 2>&1

# בדיקת TODO items כל יום שלישי ב-10:00
0 10 * * 2 source /home/user/.claude-env.sh && cd /home/user/myproject && claude -p "find all TODO, FIXME, HACK comments in the codebase. Prioritize by urgency." --bare > /home/user/myproject/reports/todos-$(date +\%Y\%m\%d).md 2>&1

systemd Timer — האלטרנטיבה המתקדמת

systemd timers מספקים יתרונות משמעותיים על cron: לוגים מובנים (journalctl), restart policies, תלויות בין שירותים, monitoring מובנה, ותמיכה ב-persistent (אם המחשב היה כבוי בזמן שהמשימה הייתה אמורה לרוץ — היא תרוץ כשהוא יידלק).

# /etc/systemd/system/claude-audit.service
[Unit]
Description=Claude Code Nightly Audit
After=network-online.target

[Service]
Type=oneshot
User=deploy
WorkingDirectory=/home/deploy/project
EnvironmentFile=/home/deploy/.claude-env.sh
ExecStart=/usr/local/bin/claude -p "run comprehensive code quality audit. Check: security, performance, test coverage, documentation completeness. Output markdown." --bare
StandardOutput=append:/var/log/claude-audit.log
StandardError=append:/var/log/claude-audit-error.log
TimeoutStartSec=300

# /etc/systemd/system/claude-audit.timer
[Unit]
Description=Run Claude audit daily at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

# הפעלה ובדיקה
sudo systemctl daemon-reload
sudo systemctl enable --now claude-audit.timer
systemctl list-timers | grep claude
journalctl -u claude-audit.service --since today

דפוס ה-Watchdog — Claude כשומר מערכת

אחד הדפוסים השימושיים ביותר: Claude Code כ-"שומר" שבודק את בריאות המערכת ומתריע רק כשיש בעיה:

#!/bin/bash
# watchdog.sh — רץ כל שעה
source ~/.claude-env.sh

# אסוף מטריקות מהשרת
DISK=$(df -h / | tail -1)
DOCKER=$(docker ps --format "{{.Names}}: {{.Status}}" 2>/dev/null || echo "Docker not available")
LOAD=$(uptime)
MEMORY=$(free -m | head -2)

# שלח ל-Claude לניתוח — שימו לב: Sonnet, לא Opus (חסכון!)
ANALYSIS=$(cat <<EOF | claude -p "analyze these server metrics. If EVERYTHING is fine, respond with just the single word 'OK'. If something is concerning (disk > 85%, memory > 90%, container down, high load), explain the issue and urgency level." --bare -m sonnet
Disk: $DISK
Docker: $DOCKER
Load: $LOAD
Memory: $MEMORY
EOF
)

# התריע רק אם יש בעיה
if [ "$ANALYSIS" != "OK" ]; then
    echo "[ALERT] $(date): $ANALYSIS" >> /var/log/watchdog-alerts.log
    # Slack webhook (החליפו ב-URL שלכם)
    curl -s -X POST "https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \
        -H "Content-Type: application/json" \
        -d "{\"text\": \"Server Alert:\\n$ANALYSIS\"}"
else
    echo "[OK] $(date): All systems normal" >> /var/log/watchdog.log
fi

Idempotency — תכונה קריטית לתזמון

Idempotency (אידמפוטנטיות) פירושה שהרצה של אותו תהליך פעמיים מייצרת את אותה תוצאה. למה זה קריטי ל-cron jobs?

• Cron עלול להריץ job פעמיים (restart, overlap, system clock change)
• Claude הוא non-deterministic — אותו prompt יכול לתת תוצאות שונות
• הפתרון: הוסיפו שכבת validation אחרי Claude — בדקו שהפלט עומד בתבנית הצפויה לפני שפועלים עליו. לדוגמה: אם הפלט צריך להיות JSON, בדקו שהוא JSON תקין. אם הוא צריך להכיל "YES" או "NO" — בדקו שהתשובה מכילה אחד מהם

Git Worktrees במצב Headless

בקורס הקודם למדתם להשתמש ב-Git Worktrees — עותקים נפרדים של הפרויקט שחולקים את אותו repository, כל אחד ב-branch אחר. עכשיו נשלב worktrees עם Headless mode — וזה פותח אפשרויות חדשות לגמרי.

הדגל -w (worktree) עובד יחד עם -p:

# יצירת worktree + הרצת prompt headless
claude -p "implement user authentication with JWT tokens" -w feature-auth --bare

# מה קורה בפועל:
# 1. נוצר git worktree חדש ב-.claude/worktrees/feature-auth/
# 2. נפתח branch חדש בשם feature-auth
# 3. Claude מריץ את ה-prompt בתוך ה-worktree — הקבצים שם נפרדים
# 4. השינויים נמצאים ב-branch feature-auth — לא ב-main שלכם

Pattern: מקביליות מלאה — כמה features במקביל

הכוח האמיתי: הרצת כמה worktree sessions במקביל. כל אחד עובד על feature אחר, ב-branch נפרד, בלי שום התנגשות:

#!/bin/bash
source ~/.claude-env.sh

# רשימת features לפיתוח
FEATURES=("add-search-api" "fix-pagination-bug" "update-readme" "add-dark-mode-toggle")

# הרצה מקבילית — כל feature ב-background
for feature in "${FEATURES[@]}"; do
    echo "[INFO] Starting: $feature"
    claude -p "implement $feature based on the spec in docs/specs/$feature.md. Run tests after changes." \
        -w "$feature" --bare &
done

# חכה שכל ההרצות יסיימו
wait
echo "[DONE] All features implemented in separate branches"

# בדוק את התוצאות — מה כל branch מכיל
for feature in "${FEATURES[@]}"; do
    echo "=== $feature ==="
    git -C ".claude/worktrees/$feature" log --oneline -3
    git -C ".claude/worktrees/$feature" diff --stat HEAD~1 2>/dev/null || echo "  (no changes)"
done

Worktrees ב-CI/CD — הדפוס הנפוץ

הדפוס הנפוץ ביותר ל-worktrees ב-Headless הוא ב-CI/CD pipelines שבהם כמה משימות צריכות לרוץ על אותו repo במקביל בלי להפריע אחת לשנייה. לדוגמה: pipeline שמריץ code review, security scan, ו-test generation במקביל — כל אחד ב-worktree נפרד:

#!/bin/bash
source ~/.claude-env.sh

# שלושה agents במקביל, כל אחד ב-worktree נפרד
claude -p "review code for bugs and style issues" -w review-agent --bare &
claude -p "scan for security vulnerabilities" -w security-agent --bare &
claude -p "generate unit tests for uncovered functions" -w test-agent --bare &

# חכה לכולם
wait

# איחוד תוצאות
echo "=== Code Review ===" > combined-report.md
git -C .claude/worktrees/review-agent show HEAD:review.md >> combined-report.md 2>/dev/null
echo -e "\n=== Security Scan ===" >> combined-report.md
git -C .claude/worktrees/security-agent show HEAD:security.md >> combined-report.md 2>/dev/null
echo -e "\n=== Test Generation ===" >> combined-report.md
git -C .claude/worktrees/test-agent show HEAD:tests.md >> combined-report.md 2>/dev/null

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

Sparse Checkout — למונוריפוס גדולים

אם יש לכם monorepo עם מאות אלפי קבצים, כל worktree לא צריך את כולם. ההגדרה worktree.sparsePaths מאפשרת checkout חלקי — רק הקבצים הרלוונטיים:

// .claude/settings.json
{
  "worktree": {
    "sparsePaths": ["packages/api/", "shared/types/", "package.json", "tsconfig.json"]
  }
}

ניקוי Worktrees

Worktrees תופסים מקום בדיסק. אחרי שסיימתם — נקו:

# ראו worktrees קיימים
git worktree list

# מחקו worktree ספציפי
git worktree remove .claude/worktrees/feature-auth

# ניקוי אוטומטי של worktrees שה-branch שלהם נמחק
git worktree prune

Debugging של הרצות Headless

כשהרצה Headless מייצרת פלט לא צפוי — או לא מייצרת פלט בכלל — אתם צריכים כלי debugging. בלי ממשק אינטראקטיבי זה קצת יותר מאתגר, אבל יש שיטה מסודרת.

The Headless Debug Ladder — 6 שלבי Debugging

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

כשלים נפוצים ב-Headless — הטבלה

תרחיש Debug מהעולם האמיתי — "למה ה-Cron Job שלי מחזיר שטויות?"

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

שלב 1 — בדיקת Exit Code: מוסיפים לוג ל-cron entry:

0 8 * * * /home/user/summary.sh >> /tmp/cron-debug.log 2>&1; echo "EXIT: $?" >> /tmp/cron-debug.log

פותחים את /tmp/cron-debug.log — ורואים EXIT: 0. Claude רץ בהצלחה, אבל הפלט לא מה שציפיתם.

שלב 2 — בדיקת stderr: בודקים את השורות לפני ה-exit code. מגלים: warning: not a git repository.

שלב 3 — הבנת הבעיה: Cron jobs רצים מ-HOME כברירת מחדל, לא מתיקיית הפרויקט! הסקריפט שלכם לא עושה cd לפרויקט. Claude רץ מ-HOME, לא מוצא git repo, ומחזיר תשובה גנרית.

התיקון:

#!/bin/bash
source ~/.claude-env.sh
cd /home/user/myproject || exit 1   # <-- השורה שהייתה חסרה!
git log --oneline --since="1 day ago" | claude -p "summarize these changes. Hebrew." --bare

הלקח: תמיד הוסיפו cd /path/to/project || exit 1 בתחילת כל סקריפט שרץ מ-cron. זו טעות קלאסית שהולכת ונפתרת רק אחרי שקוראים את ה-logs.

הכלי /debug — Post-Mortem אינטראקטיבי

אם הרצה Headless נכשלה ואתם לא מבינים למה — פתחו סשן אינטראקטיבי והריצו את ה-skill המובנית /debug:

# אחרי הרצה headless שנכשלה:
claude
> /debug
# Claude ינתח את ה-debug logs של הסשן הקודם ויסביר מה השתבש

מה /debug עושה מאחורי הקלעים? הוא קורא את קבצי ה-debug log של הסשן האחרון (נמצאים ב-~/.claude/debug/), מנתח את רצף הכלים שהופעלו, מזהה היכן התהליך "נתקע" או "סטה", ומציג הסבר ברור עם הצעת תיקון. חשבו עליו כ-"post-mortem אוטומטי" — במקום שתקראו מאות שורות של logs, Claude עושה את זה בשבילכם.

Pattern: Prompt Test Suite

לפני ששמים prompt באוטומציה שרצה כל יום, בנו "test suite" שמוודא שהפלט תקין:

#!/bin/bash
# test-prompts.sh — הריצו לפני כל deployment של אוטומציה חדשה
source ~/.claude-env.sh
PASS=0; FAIL=0

# Test 1: פלט לא ריק
RESULT=$(claude -p "say hello" --bare 2>/dev/null)
[ -n "$RESULT" ] && { PASS=$((PASS+1)); echo "PASS: Non-empty output"; } || { FAIL=$((FAIL+1)); echo "FAIL: Empty output"; }

# Test 2: JSON output parseable
RESULT=$(claude -p "return the JSON object {\"status\": \"ok\"}" --output-format json 2>/dev/null)
echo "$RESULT" | jq '.' > /dev/null 2>&1 && { PASS=$((PASS+1)); echo "PASS: JSON parseable"; } || { FAIL=$((FAIL+1)); echo "FAIL: Invalid JSON"; }

# Test 3: Exit code 0
claude -p "echo test" --bare > /dev/null 2>&1 && { PASS=$((PASS+1)); echo "PASS: Exit code 0"; } || { FAIL=$((FAIL+1)); echo "FAIL: Non-zero exit"; }

# Test 4: --bare mode works
claude -p "hello" --bare > /dev/null 2>&1 && { PASS=$((PASS+1)); echo "PASS: --bare mode"; } || { FAIL=$((FAIL+1)); echo "FAIL: --bare mode"; }

echo ""
echo "Results: $PASS passed, $FAIL failed out of $((PASS + FAIL))"
[ $FAIL -eq 0 ] && echo "All tests passed!" || echo "Some tests failed — check before deploying."

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