GitHub Actions and CI/CD — אוטומציה ב-CI/CD עם GitHub Actions

Claude Code ב-CI/CD — החזון

CI/CD (Continuous Integration / Continuous Deployment) הוא המקום שבו headless mode באמת זורח. בעולם הישן, CI checks הם בינאריים: הטסטים עוברים או נכשלים, ה-linter מצא שגיאה או לא. אין ניואנסים, אין הקשר, אין הסבר למה משהו בעייתי.

Claude Code משנה את המשוואה: במקום בדיקה בינארית, מקבלים analysis מודע הקשר. Claude קורא את ה-diff, מבין את הלוגיקה העסקית, ומסביר לא רק "יש bug" אלא "זה bug כי ה-authentication middleware לא מכסה את ה-route החדש הזה, וזה חושף endpoint ללא אימות". זה ההבדל בין linter ל-code reviewer מנוסה.

מה שהופך את זה לאפשרי הוא claude-code-action@v1 — ה-GitHub Action הרשמי של Anthropic, שהושק בספטמבר 2025 כחלק מ-Claude Code 2.0. הוא מריץ את כל ה-runtime של Claude Code בתוך GitHub Actions runner רגיל. Claude קורא את ה-repository, מנתח diffs, ומפרסם ממצאים ישירות ב-PR — כולל inline comments על שורות קוד ספציפיות.

אלטרנטיבית, אפשר להשתמש ב-raw claude -p --bare בכל מערכת CI אחרת (Jenkins, GitLab CI, CircleCI, Bitbucket Pipelines) — אבל מפסידים את האינטגרציה עם GitHub (inline comments, PR interaction, @claude mentions).

דוגמאות מייצגות: מה עושים בCI עם Claude

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

• Code review על כל PR: Claude סוקר את ה-diff ומגיב עם ממצאים — הcase הנפוץ ביותר. עובד 24/7, עולה סנטים
• Security audit על pushes ל-main: Claude מחפש פרצות אבטחה בקוד שנכנס ל-production — כולל OWASP Top 10
• Release notes אוטומטיים: Claude קורא commits ו-PRs ומייצר release notes מסודרים בכל release
• Issue-to-PR: מישהו יוצר issue, Claude מיישם את השינוי ופותח Draft PR
• Documentation sync: כשAPI משתנה, Claude מעדכן את ה-docs אוטומטית
• Test generation: כשקוד חדש נכנס בלי tests, Claude מייצר test stubs
• i18n validation: בפרויקטים עם עברית, Claude מוודא שכל string חדש מתורגם
• Dependency review: כש-Dependabot מעדכן package, Claude בודק changelog ומעריך סיכון

כל התרחישים האלה משתמשים באותו building block: claude-code-action@v1 עם prompt מותאם. ההבדל הוא ב-trigger (מה מפעיל), ב-model (כמה "חכם" צריך להיות), וב-prompt (מה Claude צריך לעשות).

התקנת claude-code-action@v1

יש שתי דרכים להתקין את claude-code-action: המהירה (דרך Claude Code עצמו) והידנית. שתיהן מגיעות לאותה תוצאה.

דרך מהירה: /install-github-app

פתחו Claude Code בטרמינל והריצו:

/install-github-app

Claude Code ינחה אתכם צעד אחר צעד: יתקין את ה-GitHub App, יגדיר secrets, ויצור workflow YAML ראשוני. זו הדרך הכי מהירה — פחות מ-5 דקות מהתחלה עד workflow פעיל.

דרך ידנית — שליטה מלאה

אם אתם מעדיפים להבין כל שלב:

1. התקינו את ה-GitHub App: היכנסו ל-github.com/apps/claude והתקינו על ה-repository שלכם. ה-App צריך הרשאות Read & Write על Contents, Issues, ו-Pull Requests.
2. הוסיפו secrets: ב-Settings → Secrets and variables → Actions, הוסיפו:
   • ANTHROPIC_API_KEY — המפתח שלכם מ-Anthropic. זהו ה-secret היחיד שחובה.
3. צרו workflow: צרו קובץ .github/workflows/claude-review.yml עם התוכן הבא:

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

jobs:
  review:
    if: |
      github.event_name == 'pull_request' ||
      (github.event_name == 'issue_comment' &&
       contains(github.event.comment.body, '@claude'))
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6

ה-workflow הזה עושה שני דברים: (1) מריץ review אוטומטי על כל PR חדש או מעודכן, ו-(2) מגיב כשמישהו כותב @claude בתגובה ל-PR. ה-fetch-depth: 0 חשוב — בלעדיו, Claude לא יכול לקרוא את ההיסטוריה של הrepo.

Authentication methods

claude-code-action תומך במספר שיטות אימות:

לרוב המפתחים, ANTHROPIC_API_KEY מספיק. שיטות Bedrock/Vertex/Foundry רלוונטיות לארגונים גדולים עם cloud provider agreements.

בדיקת ההתקנה

1. צרו branch חדש עם שינוי קטן (אפילו הוספת תגובה בקובץ)
2. פתחו PR
3. חכו 30-60 שניות
4. Claude יפרסם תגובה עם ממצאי ה-review

אם Claude לא מגיב תוך 2 דקות — בדקו ב-Actions tab שה-workflow הופעל. אם הוא הופעל אבל נכשל — בדקו את ה-logs. הסיבות הנפוצות ביותר:

@claude Mentions — אינטראקציה מ-PR

בנוסף ל-review אוטומטי, claude-code-action מגיב כשמישהו כותב @claude בתגובה ל-PR. זה שימושי כשreviewer אנושי רוצה לשאול שאלה ספציפית:

@claude Is this change backward compatible?
@claude Can you suggest a more efficient algorithm for this function?
@claude Check if this migration is reversible

Claude קורא את ההקשר של ה-PR (diff, files, conversation history) ומגיב בתגובה. זה הופך אותו לחבר צוות זמין — כמו Senior Developer שאפשר לשאול שאלות 24/7.

תרחיש נפוץ: reviewer אנושי שואל "@claude what's the performance impact of this change?" — Claude מנתח את השינוי, מחפש potential bottlenecks, ומגיב בתוך 30 שניות. ה-reviewer מקבל תשובה מבוססת ניתוח קוד, לא ניחוש. זה במיוחד שימושי כשה-reviewer לא מכיר חלק מסוים מה-codebase — Claude כן מכיר כי הוא קורא הכל.

עוד דוגמאות לשימוש ב-@claude:

• @claude explain the purpose of this function to a junior developer
• @claude write unit tests for the new endpoint added in this PR
• @claude check if this change is backward compatible with v1 API
• @claude translate the error messages in this PR to Hebrew

Progress Tracking

מגרסה 1.x של claude-code-action, יש progress indicators — תוך כדי שClaude עובד, אפשר לראות ב-PR אינדיקציה שהוא מנתח את הקוד. זה חשוב כי ב-repos גדולים, הanalysis יכול לקחת 30-90 שניות, ובלי אינדיקציה, developers לא יודעים אם Claude עדיין עובד או תקוע.

Automated Code Review על PRs

זהו ה-use case הראשי וגם הכי קל להתחיל איתו: כל PR שנפתח מקבל סקירת קוד מ-Claude לפני ש-reviewers אנושיים מסתכלים עליו. Claude מנתח את ה-diff, מבין את ההקשר של ה-codebase, ומפרסם ממצאים כתגובות — כולל inline comments על שורות ספציפיות.

מה Claude בודק

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

התאמה אישית דרך CLAUDE.md

הדרך הכי טובה למקד את ה-review היא דרך CLAUDE.md. Claude קורא אותו לפני שמנתח את ה-diff:

# ב-CLAUDE.md של הפרויקט
## CI/CD Context
When reviewing PRs in CI:
- Focus on security and correctness only
- Ignore style issues (we have eslint for that)
- Flag any changes to authentication or authorization code as HIGH priority
- Check for Hebrew string handling (RTL, Unicode)
- Verify error messages are user-friendly in both Hebrew and English
- If a database migration is missing for schema changes, flag as CRITICAL

Inline comments vs Summary

Claude מפרסם שני סוגי תגובות ב-PR:

• Inline comments: תגובות על שורות ספציפיות ב-diff — "שורה 42: הoperator צריך להיות === ולא =, זה assignment במקום comparison"
• Summary comment: תגובה כללית בראש ה-PR עם סיכום כל הממצאים מסודר לפי severity (CRITICAL, HIGH, MEDIUM, LOW)

Inline comments שימושיים יותר כי הם מצביעים בדיוק על הבעיה. ה-developer לא צריך לחפש — הוא רואה את התגובה ליד השורה הרלוונטית.

Path filtering — חיסכון קריטי

ב-repos גדולים, אין טעם שClaude ינתח package-lock.json עם 5,000 שורות שהשתנו. הוסיפו path filter:

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'src/**'
      - 'lib/**'
      - '!**/*.test.ts'        # אל תסקור קבצי טסט
      - '!**/package-lock.json' # התעלם מ-lock files
      - '!**/*.generated.*'     # התעלם מקוד שנוצר אוטומטית

Path filtering חוסך 80% מהעלות ב-repos עם הרבה generated code או dependency files, ובנוסף משפר את איכות ה-review — Claude מתמקד בקוד שבאמת חשוב.

Prompt engineering לreview טוב יותר

ה-prompt שנותנים ל-Claude משפיע ישירות על איכות ה-review. כמה עקרונות:

• ספציפיות: "review this code" → "review this code for SQL injection, XSS, and missing input validation" — prompt ספציפי נותן ממצאים ממוקדים
• פורמט פלט: בקשו severity rating (CRITICAL/HIGH/MEDIUM/LOW) כדי שה-developer ידע במה לטפל קודם
• הקשר: ספרו ל-Claude על הפרויקט — "This is a fintech application handling ILS payments" משנה את סדר העדיפויות
• קהל יעד: "We have junior developers on the team — flag anything that might be confusing" — Claude יתאים את רמת הפירוט

דוגמה לprompt מותאם שנותן תוצאות מעולות:

prompt: |
  You are reviewing code for a Hebrew education platform.
  The codebase handles: user auth, content management, and payments in ILS.

  Review this PR diff and provide:
  1. SECURITY: Any vulnerabilities (especially in auth and payment code)
  2. CORRECTNESS: Logic bugs and edge cases
  3. HEBREW/RTL: Issues with Hebrew text handling, RTL layout, or Unicode

  For each finding:
  - Quote the exact line
  - Explain the issue in 1-2 sentences
  - Suggest a fix
  - Rate severity: CRITICAL / HIGH / MEDIUM / LOW

  At the end, give an overall verdict: APPROVE / REQUEST_CHANGES / COMMENT_ONLY

Prompt כזה נותן review שהוא ממוקד, actionable, ומותאם לפרויקט שלכם — לא review גנרי שמתייחס לstyle.

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

jobs:
  review:
    if: |
      github.event_name == 'pull_request' ||
      (github.event_name == 'issue_comment' &&
       contains(github.event.comment.body, '@claude'))
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6

Security Audits ב-CI

Code review כללי הוא נהדר, אבל לעתים צריכים workflow מוקדש אבטחה בלבד — ממוקד, מעמיק, שרץ עם Opus (המודל החזק ביותר). Anthropic גם מציעים action ייעודי: anthropics/claude-code-security-review שמותאם במיוחד לסקירות אבטחה.

Workflow לsecurity audit

name: Security Audit
on:
  push:
    branches: [main]
  pull_request:
    paths:
      - 'src/auth/**'
      - 'src/api/**'
      - 'src/middleware/**'

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-opus-4
          prompt: |
            Act as a senior security engineer. Review this diff for:
            1. SQL injection risks
            2. XSS vulnerabilities
            3. Authentication and authorization flaws
            4. Insecure data handling (exposed PII, unencrypted sensitive data)
            5. Missing input validation
            6. Insecure dependencies

            For each finding, rate severity: CRITICAL / HIGH / MEDIUM / LOW
            If any CRITICAL finding, start your response with "SECURITY ALERT"

שימו לב לשני דברים חשובים: (1) ה-security audit רץ על push ל-main (לא על כל PR) כי Opus יקר יותר. על PRs, הוא רץ רק כשמשנים קבצי auth/api/middleware. (2) ה-prompt מבקש severity rating ומגדיר trigger word ("SECURITY ALERT") שנשתמש בו ל-security gate.

OWASP Top 10 — מה Claude בודק

ה-prompt למעלה מכוון ל-OWASP Top 10, רשימת 10 הפרצות הנפוצות ביותר ביישומי ווב. הנה מה שClaude מחפש:

Claude לא רק מזהה patterns — הוא מבין הקשר. למשל, SQL injection ב-query שלא מקבל user input הוא סיכון נמוך יותר מ-SQL injection ב-search endpoint ציבורי. Claude מתעדף בהתאם.

שילוב עם כלים קיימים

Claude לא מחליף כלי security scanning — הוא משלים אותם. הנה דפוס חזק: הריצו npm audit או pip-audit קודם, ואז תנו ל-Claude לפרש את התוצאות ולתעדף:

      - name: Run npm audit
        run: npm audit --json > audit-results.json || true

      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            I've run npm audit. Results are in audit-results.json.
            Read the results and:
            1. Prioritize vulnerabilities by actual risk to our application
            2. Filter out false positives (dev-only deps that don't ship to production)
            3. Suggest specific fix actions for the top 3 issues

Security Gate — חסימת merge אוטומטית

ה-"Security Gate" הוא הדפוס שחוסם merge כשClaude מזהה פרצה CRITICAL:

      - name: Check for critical findings
        run: |
          REVIEW=$(gh pr view ${{ github.event.pull_request.number }} \
              --json comments --jq '.comments[-1].body')
          if echo "$REVIEW" | grep -q "SECURITY ALERT"; then
            echo "::error::Critical security finding detected!"
            exit 1
          fi

ברגע שה-step נכשל, GitHub מסמן את ה-check כ-failed. אם הגדרתם Branch Protection Rules (Settings → Branches → Require status checks) — ה-merge חסום אוטומטית עד שהבעיה מתוקנת.

הגדרת Branch Protection

כדי שה-security gate באמת יחסום merge, צריך להפעיל Branch Protection:

1. Settings → Branches → Add branch protection rule
2. Branch name pattern: main
3. סמנו "Require status checks to pass before merging"
4. חפשו את שם ה-job מה-workflow (למשל "security")
5. הוסיפו אותו כ-required check

מעכשיו, אף PR לא יכול להתמרג' ל-main בלי שה-security audit יעבור. זה שכבת הגנה חזקה שמונעת פרצות להגיע ל-production.

מתי להריץ security audit?

Security audit עם Opus עולה $0.50-2.00 להרצה. אם מריצים על כל PR — זה יקר. הגישה המומלצת:

Release Notes אוטומטיים

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

Workflow לrelease notes

name: Release Notes
on:
  push:
    tags: ['v*']

jobs:
  release-notes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get commits since last tag
        id: commits
        run: |
          PREV_TAG=$(git describe --tags --abbrev=0 HEAD^ 2>/dev/null || echo "")
          if [ -z "$PREV_TAG" ]; then
            COMMITS=$(git log --oneline)
          else
            COMMITS=$(git log --oneline $PREV_TAG..HEAD)
          fi
          echo "commits<> $GITHUB_OUTPUT
          echo "$COMMITS" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6
          prompt: |
            Generate release notes from these commits:
            ${{ steps.commits.outputs.commits }}

            Organize by: New Features, Improvements, Bug Fixes, Breaking Changes.
            Use clear, non-technical language where possible.
            Generate in both English and Hebrew.

העשרת notes עם PR data

Commits לבד נותנים תמונה חלקית. הוסיפו גם נתוני PRs שמורגו:

      - name: Enrich with PR data
        run: |
          gh pr list --state merged --base main --json title,body,labels \
              --jq '.[] | "PR: \(.title)\nLabels: \(.labels | map(.name) | join(", "))"' \
              > pr-data.txt

      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Generate release notes using both the commit log and PR descriptions.
            Commits: ${{ steps.commits.outputs.commits }}
            PR data is in pr-data.txt - read it.
            Prioritize: what matters to users, not internal refactoring.

Multi-language release notes

עבור פרויקטים עם קהל ישראלי, Claude יכול לייצר release notes בעברית ובאנגלית:

prompt: |
  Generate release notes in TWO sections:
  ## English
  [English release notes here]

  ## עברית
  [Hebrew release notes here - natural Hebrew, not a word-for-word translation]

Claude מייצר עברית טבעית, לא תרגום מילולי. זה חוסך את הצורך בתרגום נפרד ומבטיח שה-release notes בעברית קוראות טבעי. חשוב: הוסיפו הנחיה "not a word-for-word translation" כי אחרת Claude עלול לתרגם מילולית.

יצירת GitHub Release אוטומטית

אפשר גם ליצור GitHub Release מלא אוטומטית (לא רק notes):

      - name: Create Release
        run: |
          NOTES=$(claude -p "Generate release notes from: $(git log --oneline $PREV_TAG..HEAD)" --bare)
          gh release create ${{ github.ref_name }} \
              --title "Release ${{ github.ref_name }}" \
              --notes "$NOTES" \
              --generate-notes

ה-flag --generate-notes מוסיף גם את ה-auto-generated notes של GitHub, כך שמקבלים שילוב של notes אוטומטיים + notes של Claude.

Semantic versioning automation

Claude יכול גם להציע את ה-version הבא:

      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Current version: ${{ github.ref_name }}
            Based on these changes, suggest the next version:
            - MAJOR: breaking changes
            - MINOR: new features
            - PATCH: bug fixes only
            Respond with just the version number (e.g., v1.2.3)

Issue-to-PR Automation

ה-dream workflow: מישהו יוצר GitHub issue שמתאר באג או feature, Claude קורא את ה-issue, מנתח את ה-codebase, מייצר branch, מיישם את השינויים, מריץ tests, ופותח PR. הכל אוטומטית.

Setup

name: Issue to PR
on:
  issues:
    types: [labeled]

jobs:
  implement:
    if: contains(github.event.label.name, 'claude-auto')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6
          trigger: 'issue'

ה-trigger: כשמישהו מוסיף label claude-auto ל-issue, ה-workflow נדלק. Claude קורא את תיאור ה-issue, מנתח את ה-codebase, ופותח Draft PR עם השינויים.

מה עובד ומה לא

דפוס ה-Draft PR: Claude תמיד פותח כ-Draft PR — בן אדם חייב לאשר ולהפוך ל-Ready for Review. זו רשת ביטחון קריטית. בלי זה, קוד שClaude כתב יכול להגיע ל-production בלי review אנושי.

Issues בעברית

Claude מבין עברית מצוין. אפשר לכתוב issues בעברית ו-Claude יייצר PR עם קוד באנגלית ותיאור דו-לשוני:

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

צפוי: הטופס אמור להיפתח כ-modal

Claude יקרא את ה-issue בעברית, ינתח את ה-codebase, ימצא את ה-bug (כנראה event handler שלא עובד על touch events), ויפתח PR עם התיקון — כולל תיאור PR בשתי השפות.

בניית אמון הדרגתית

אל תתחילו עם Issue-to-PR על features מורכבים. הגישה המומלצת:

1. שבוע 1: התחילו עם "good first issue" — באגים קטנים עם reproduction steps ברורים
2. שבוע 2: הרחיבו ל-documentation updates ותיקוני typos
3. שבוע 3: נסו features קטנים (הוספת field לטופס, שינוי text)
4. שבוע 4: הערכת ROI — כמה PRs הצליחו? כמה נזרקו? שווה?

ככל שצוברים אמון, אפשר להרחיב את ה-scope. אבל תמיד — Draft PR + human review + tests passing לפני merge.

CLAUDE.md ב-CI Pipelines

CLAUDE.md הוא ה-single source of truth להתנהגות של Claude — וזה תקף גם ב-CI. כשClaude רץ ב-GitHub Actions, הוא קורא את CLAUDE.md מה-repository ומתנהג לפיו. זה אומר שהצוות שלכם יכול לשלוט בהתנהגות של ה-AI reviewer דרך commit לrepo — בלי לשנות workflow YAML.

סעיפים ספציפיים ל-CI

# ב-CLAUDE.md
## CI/CD Context
When running in CI (detected by CI=true environment variable):
- Focus on security and correctness only
- Do not suggest style changes (we have eslint)
- Default to safe choices when uncertain
- Skip interactive prompts
- Flag changes to database schemas that lack a migration
- Check for breaking changes in public APIs

ה-rules directory — הנחיות מותנות

CLAUDE.md מכיל הנחיות כלליות. לפעמים צריכים הנחיות שמופעלות רק כשClaude קורא סוג מסוים של קבצים. ליצור הנחיות מותנות ב-.claude/rules/:

# .claude/rules/ci-review.md
---
description: Rules for automated CI code review
globs:
  - "src/**/*.ts"
  - "src/**/*.tsx"
---

When reviewing TypeScript code:
- Verify all function parameters have explicit types
- Check for proper error handling (no uncaught promises)
- Verify that new API endpoints have input validation
- Check for proper null/undefined handling

# .claude/rules/ci-security.md
---
description: Security review rules activated for auth code
globs:
  - "src/auth/**"
  - "src/api/**"
---

When reviewing security-sensitive code:
- Verify all endpoints require authentication
- Check for proper RBAC (Role-Based Access Control)
- Verify sensitive data is not logged
- Check for SQL injection in raw queries
- Verify bcrypt/argon2 for password hashing

הקבצים האלה נטענים אוטומטית כשClaude קורא קבצים שתואמים את ה-globs. זה אומר שreview של קוד auth מקבל הנחיות אבטחה אוטומטית — בלי שתצטרכו לציין את זה ב-workflow YAML.

Environment-aware instructions

אפשר גם להוסיף הנחיות שמופעלות רק ב-CI (ולא בשימוש אינטראקטיבי):

# ב-CLAUDE.md
## CI-Only Rules
If the environment variable CI=true (which GitHub Actions sets automatically):
- Never ask for confirmation — make safe choices automatically
- Log all decisions to the PR comment
- If uncertain about a finding, mark it as "POSSIBLE" instead of hiding it
- Include cost/token info in the summary

GitHub Actions מגדיר אוטומטית CI=true, כך שClaude יכול לזהות שהוא רץ ב-CI ולהתנהג בהתאם. זה שימושי כשרוצים שClaude יהיה "יותר explicit" ב-CI (כי אין בן אדם שמסתכל בזמן אמת) אבל "יותר חוסך" באינטראקטיבי.

שיתוף הגדרות בצוות

CLAUDE.md ו-.claude/rules/ הם קבצים רגילים ב-repo — כל שינוי שם עובר PR review ומגיע לכל המפתחים. זה אומר שהצוות שלכם שולט בהתנהגות של ה-AI reviewer דרך קוד, לא דרך הגדרות חיצוניות. אם מישהו רוצה לשנות את מה שClaude בודק — הוא פותח PR שמשנה את CLAUDE.md, הצוות מאשר, וההנחיות החדשות נכנסות לתוקף מיידית בכל CI run.

דפוס ה-Iterative Improvement

ה-workflow הכי אפקטיבי לשיפור CLAUDE.md:

1. Claude נותן review עם false positive (ממצא לא רלוונטי)
2. Developer מזהה ומתעד — "Claude keeps flagging console.log as security issue in test files"
3. שינוי CLAUDE.md: "Do not flag console.log in test files (**/*.test.ts)"
4. PR + review: הצוות מאשר את השינוי
5. מעכשיו: Claude לא מדווח על console.log בtests

אחרי כמה שבועות של iterations, CLAUDE.md שלכם הופך לאמין מאוד — Claude בודק בדיוק מה שחשוב לפרויקט שלכם ומתעלם מדברים שאינם רלוונטיים. זה כמו "לאמן" reviewer חדש, רק שהlogs שלו (CLAUDE.md) שקופים לכל הצוות.

Workflows מותאמים אישית — מעבר ל-Code Review

Code review ו-security audit הם רק ההתחלה. הנה עוד תרחישים שבהם Claude Code ב-CI מביא ערך:

Documentation sync

על כל merge ל-main, Claude בודק אם קוד ה-API השתנה ומעדכן docs:

prompt: "Check if any API endpoints changed in this commit. If yes, update the corresponding docs in docs/api/. Create a PR with the doc updates."

Changelog maintenance

Claude מוסיף שורה ל-CHANGELOG.md לפי ה-PR description:

prompt: "Read the PR description and add an entry to CHANGELOG.md under 'Unreleased'. Format: '- [TYPE] description'. TYPE = Added/Changed/Fixed/Removed."

i18n validation — חשוב לפרויקטים עם עברית

Claude בודק שכל מחרוזת חדשה שפונה למשתמש מתורגמת:

prompt: "Check if any new user-facing strings were added. Verify they exist in locales/he.json with Hebrew translations. Flag any missing translations."

Test generation

כשקוד חדש נכנס בלי טסטים, Claude מייצר stubs:

prompt: "For each new function in this PR that lacks tests, generate a test file with the basic structure: describe block, test cases for happy path and edge cases."

Dependency update review

כש-Dependabot פותח PR, Claude בודק changelog ומעריך סיכון:

prompt: "This PR updates a dependency. Fetch the changelog. Assess: (1) breaking changes? (2) security fixes? (3) risk level for our codebase. Recommend: merge / review manually / skip."

Migration validation

Claude בודק שmigrations חדשות בטוחות:

prompt: "Review the database migration files in this PR. Check: (1) Is it reversible? (2) Does it lock large tables? (3) Is there data loss risk? (4) Is there a corresponding down migration?"

Performance regression detection

אם יש לכם benchmark suite, Claude יכול לנתח את התוצאות:

prompt: "Read benchmark-results.json (current) and benchmark-baseline.json (main). Flag any test that regressed by more than 10%. Explain possible causes for each regression."

דוגמה מלאה: workflow משולב

הנה workflow שמשלב code review, documentation check, ו-test coverage בjob אחד:

name: Claude Full Review
on:
  pull_request:
    types: [opened, synchronize]
    paths: ['src/**']

jobs:
  full-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run tests with coverage
        run: npm test -- --coverage --coverageReporters=json-summary

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6
          prompt: |
            Perform a comprehensive review:

            1. CODE REVIEW: Check for bugs, security issues, and edge cases in the diff
            2. TEST COVERAGE: Read coverage/coverage-summary.json.
               Flag any new code with less than 80% coverage
            3. DOCUMENTATION: If any public API changed, verify docs are updated
            4. MIGRATION CHECK: If any schema files changed,
               verify a corresponding migration exists

            Format your response with clear ## headers for each section.
            Rate each section: PASS / NEEDS_WORK / FAIL

עם workflow אחד וprompt מובנה, אתם מקבלים review מקיף שכולל 4 סוגי בדיקות שונות — מה שבדרך כלל דורש 4 כלים נפרדים.

name: My Custom Workflow
on:
  # שנו את ה-trigger לפי הצורך:
  # push: { branches: [main] }
  # pull_request: { types: [opened] }
  # schedule: [{ cron: '0 8 * * 1' }]  # כל יום שני ב-8 בבוקר
  pull_request:
    types: [opened, synchronize]

jobs:
  custom-task:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6
          # שנו את ה-prompt:
          direct_prompt: |
            YOUR TASK HERE.
            Format output with ## headers.

שליטה בעלויות CI

CI runs יכולים להפוך ליקרים מהר אם לא מתכננים. 50 PRs בשבוע כפול $0.30 לPR = $60 בחודש רק ל-reviews. מוסיפים security audits עם Opus? המספרים מטפסים. חובה לתכנן מראש.

Model selection strategy

כלל הזהב: השתמשו במודל הזול ביותר שנותן תוצאות מספיק טובות. Sonnet מצטיין ב-90% מהreviews. Opus רק ל-security.

טקטיקות חיסכון

• Path filtering: רק קבצים שהשתנו, לא package-lock.json (חוסך 80%+)
• Tiered review: Haiku ל-basic checks, Sonnet ל-full review, Opus ל-security בלבד
• Caching: אם אותם קבצים לא השתנו מאז review אחרון — דלגו
• MAX_THINKING_TOKENS=8192: ב-CI, רוב המשימות לא צריכות deep thinking
• Budget alerts: עקבו אחרי עלויות, הגדירו alert ב-80% מהתקציב החודשי
• Conditional triggers: security audit רק על PRs שמשנים קוד רגיש — לא על README fixes

מעקב עלויות בפועל

אפשר להוסיף step ל-workflow שמתעד את העלות:

      - name: Log cost
        if: always()
        run: |
          echo "$(date),claude-review,${{ github.event.pull_request.number }},$COST" \
              >> $GITHUB_WORKSPACE/ci-costs.csv
          # לחלופין: שלחו webhook עם נתוני העלות
          # curl -s "$COST_WEBHOOK" -d '{"workflow":"review","cost":"$COST"}'

ברמה בסיסית יותר, אפשר פשוט לבדוק את ה-Anthropic Console שמראה usage per API key, ולהגדיר spending limits:

• היכנסו ל-console.anthropic.com
• Settings → Billing → Usage
• ראו usage breakdown לפי יום, שבוע, חודש
• הגדירו spending limit כדי שה-API key יפסיק לעבוד אם חורגים מתקציב

טיפ: Conditional model selection

אפשר לבחור model דינמית בתוך ה-workflow, לפי סוג השינויים:

      - name: Choose model
        id: model
        run: |
          if git diff --name-only ${{ github.event.pull_request.base.sha }} | grep -qE "^src/(auth|security|crypto)/"; then
            echo "model=claude-opus-4" >> $GITHUB_OUTPUT
            echo "Using Opus for security-sensitive changes"
          else
            echo "model=claude-sonnet-4-6" >> $GITHUB_OUTPUT
            echo "Using Sonnet for standard review"
          fi

      - uses: anthropics/claude-code-action@v1
        with:
          model: ${{ steps.model.outputs.model }}

כך שינויים ב-auth/ מקבלים Opus אוטומטית, וכל השאר — Sonnet. חיסכון חכם שלא מתפשר על אבטחה.

התאמה למערכות CI אחרות

לא כולם משתמשים ב-GitHub. החדשות הטובות: claude -p --bare עובד בכל מערכת CI שתומכת בהרצת shell commands — וזה כולן.

דוגמה: GitLab CI

# .gitlab-ci.yml
code-review:
  stage: review
  image: node:20
  script:
    - npm install -g @anthropic-ai/claude-code
    - git diff origin/main...HEAD | claude -p "review this code change for bugs and security issues" --bare
  variables:
    ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

דוגמה: Jenkins

// Jenkinsfile
pipeline {
    agent { docker { image 'node:20' } }
    environment {
        ANTHROPIC_API_KEY = credentials('anthropic-api-key')
    }
    stages {
        stage('Claude Review') {
            steps {
                sh 'npm install -g @anthropic-ai/claude-code'
                sh '''
                    git diff origin/main...HEAD | \
                    claude -p "review this code change" --bare \
                    > review-output.txt
                '''
                archiveArtifacts 'review-output.txt'
            }
        }
    }
}

דוגמה: CircleCI

# .circleci/config.yml
version: 2.1
jobs:
  claude-review:
    docker:
      - image: node:20
    steps:
      - checkout
      - run:
          name: Install Claude Code
          command: npm install -g @anthropic-ai/claude-code
      - run:
          name: Run review
          command: |
            git diff origin/main...HEAD | \
            claude -p "review this code for security and correctness" --bare

הדפוס האוניברסלי

בכל מערכת CI, הדפוס זהה:

1. התקינו Claude Code (npm install -g @anthropic-ai/claude-code)
2. הגדירו ANTHROPIC_API_KEY כ-secret/environment variable
3. הריצו claude -p "your prompt" --bare
4. פרסקו את הפלט ופעלו בהתאם (שמרו, העבירו, התנו)

ה-point החשוב: כל מערכת CI תומכת ב-"run a shell command". ו-claude -p --bare הוא בדיוק shell command. אתם לא צריכים integration מיוחדת — אתם צריכים רק להתקין ולהריץ. ההשקעה הכי גדולה היא לא בtechnical setup אלא ב-prompt engineering — לכתוב prompts שנותנים תוצאות מועילות.

היתרון של claude-code-action@v1: inline comments, PR interaction, @claude mentions, progress indicators. אם אתם ב-GitHub — השתמשו ב-action. אם לא — ה-CLI עובד מעולה עם כל מערכת CI.

Docker עם Claude Code מותקן מראש

ב-CI systems שמשתמשים ב-Docker, אפשר ליצור image שכבר מותקן עם Claude Code:

# Dockerfile.claude-ci
FROM node:20-slim
RUN npm install -g @anthropic-ai/claude-code
# Add your project's dependencies
COPY package*.json ./
RUN npm ci

זה חוסך את זמן ההתקנה בכל CI run — במקום להתקין Claude Code כל פעם (שלוקח 10-20 שניות), ה-image מוכן. שימושי במיוחד ב-Jenkins ו-CircleCI שבהם Docker images הם הדרך המומלצת.

הגבלת כלים ב-CI — security best practice

כשClaude רץ ב-CI, הוא יכול לעשות הכל שClaude Code רגיל יכול — לקרוא קבצים, להריץ פקודות, לכתוב קבצים. ב-CI, כדאי להגביל את הכלים:

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          allowed_tools: "Read,Grep,Glob"  # קריאה בלבד — לא Write, Edit, Bash

הגבלת כלים ל-Read/Grep/Glob אומרת שClaude יכול לנתח קוד ולהגיב, אבל לא יכול לשנות קבצים, להריץ פקודות, או לגשת לרשת. זו הגנה חשובה — במיוחד על repos ציבוריים שבהם תוקפים יכולים לפתוח PR עם prompt injection שמנסה להשתמש ב-Claude כנקודת תורפה.

שגרת עבודה — CI/CD

אם אתם עושים רק דבר אחד מהפרק הזה

בדוק את עצמך

סיכום הפרק

צ׳קליסט סיום