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

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

CI/CD — ראשי תיבות של Continuous Integration ו-Continuous Deployment — הוא התהליך שבו כל שינוי בקוד עובר אוטומטית בדיקות, בנייה, ופריסה. כל מפתח מכיר את הרצף: אתה דוחף קוד, הבדיקות רצות, ואם הכל ירוק — הקוד עובר הלאה. זה מה שעושה GitHub Actions, GitLab CI, Jenkins, CircleCI, ומערכות CI/CD אחרות.

אבל יש בעיה מהותית: הבדיקות המסורתיות הן בינאריות. הטסט עובר או נכשל. הלינטר מוצא שגיאת תחביר או לא. SAST (כלי סריקת אבטחה סטטי) מזהה Pattern מוכר או לא. אין "חוות דעת". אין הבנת הקשר עסקי. אין שיקול דעת. זה כמו לשים שומר בכניסה לבנק עם רשימת 10 חוקים מודפסת — הוא יבדוק אותם בקפידה, אבל לא יבחין בהתנהגות חשודה שלא כתובה ברשימה.

Claude Code ב-CI/CD משנה את המשחק: במקום בדיקות בינאריות בלבד, אתם מוסיפים שכבה של בינה מלאכותית שמבינה הקשר. Claude קורא את ה-Diff, מבין מה הקוד עושה ולמה, מזהה באגים פוטנציאליים שלא נמצאים ברשימת כללים, מציע שיפורים מבוססי ניסיון, ואפילו כותב קוד או תיעוד בעצמו — הכל אוטומטית, על כל PR, 24/7.

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

הנה מה שנהיה אפשרי כש-Claude Code רץ בצנרת:

• Code Review שמבין Business Logic: לא רק "שורה 42 ארוכה מדי" — אלא "הפונקציה הזו לא מטפלת במקרה שהמשתמש ישראלי ומשלם בש"ח — צריך לטפל בהמרת מטבע לפני שמירה ל-DB"
• סריקות אבטחה שמסבירות למה: לא רק "SQL Injection detected" — אלא "הפרמטר user_id מגיע ישירות מ-req.params בלי סניטיזציה. תוקף יכול לשלוח ערך זדוני ולגשת לנתונים של משתמשים אחרים"
• Release Notes ידידותיים: במקום רשימת commits טכנית (fix: resolve auth bug #1234), מקבלים תיאור ברור: "תוקנה בעיה שלפעמים גרמה למשתמשים להתנתק באמצע פעולה"
• Issue → PR אוטומטי: מישהו מדווח על באג בעברית, Claude מנתח את הבעיה, מאתר את הקוד הרלוונטי, כותב Fix, מריץ טסטים, ופותח Draft PR — בלי התערבות אנושית
• בדיקת תרגומים: על כל PR, Claude מוודא שכל String חדש שמוצג למשתמש קיים גם בקובץ התרגום העברי

מה Claude Code ב-CI לא עושה

חשוב להבין גם את המגבלות. Claude Code ב-CI לא מחליף:

• Unit Tests: Claude יכול לזהות קוד בלי טסטים ואפילו לכתוב טסטים, אבל הוא לא מריץ אותם (ה-CI runner מריץ). טסטים אוטומטיים שעוברים הם עדיין הבסיס
• Type Checking: TypeScript compiler או mypy תופסים שגיאות טיפוס דטרמיניסטית — Claude לא צריך לעשות את זה
• Linting ו-Formatting: ESLint, Prettier, Black — כלים אלה דטרמיניסטיים ומהירים. אל תבזבזו טוקנים על בדיקות שהם עושים טוב יותר
• Review אנושי: Claude לא מבין את ההקשר העסקי המלא, את החזון של המוצר, או את הפוליטיקה הצוותית. הוא כלי שמשלים את הבודק האנושי, לא מחליף אותו

המודל הנכון: כלים מסורתיים (Linter + Tests + SAST) מטפלים בשכבה הדטרמיניסטית. Claude מוסיף את השכבה ההיוריסטית — הבנה, הקשר, שיקול דעת. האדם מוסיף את השכבה העסקית — האם השינוי הזה נכון מבחינת המוצר?

משוואת הערך — מתי CI עם Claude משתלם

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

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

הפעולה הרשמית של Anthropic נקראת claude-code-action@v1 (הנתיב המלא: anthropics/claude-code-action@v1). היא זמינה ב-GitHub Marketplace, מתוחזקת על ידי Anthropic, ומספקת אינטגרציה עמוקה עם GitHub — כולל תגובות על PRs, הגבה על issues, inline comments על שורות קוד ספציפיות, ותמיכה ב-@claude mention.

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

מסלול 1 — המהיר (מומלץ)

מתוך Claude Code, בסשן אינטראקטיבי, הריצו:

/install-github-app

הפקודה הזו מאתחלת אוטומטית GitHub App, מייצרת Private Key, מגדירה את כל ההרשאות הנדרשות, ומנחה אתכם צעד אחרי צעד. בסוף התהליך, תקבלו APP_ID ו-APP_PRIVATE_KEY שצריך להוסיף כ-Secrets ב-Repository. זה המסלול הכי מהיר — דקות ספורות מהתחלה ועד Workflow עובד.

מסלול 2 — ידני

אם אתם צריכים שליטה מלאה (או שהארגון שלכם דורש אישורים על כל App), עקבו אחרי הצעדים:

1. היכנסו ל-GitHub → Settings → Developer Settings → GitHub Apps → New GitHub App
2. תנו שם לאפליקציה (לדוגמה: claude-code-review-myteam). השם חייב להיות ייחודי בכל GitHub
3. הגדירו הרשאות (Permissions): Read and Write על Pull Requests, Issues, ו-Contents. Read בלבד על Metadata
4. ב-Webhook: אפשר להשאיר לא פעיל (ה-Action מטפל בעצמו)
5. צרו Private Key (לחצו Generate a private key) — יירד קובץ PEM. שמרו אותו במקום בטוח
6. רשמו את ה-App ID מדף הסקירה של ה-App (מספר בן 6-7 ספרות)
7. לכו ל-Install App → בחרו את ה-Repository או ה-Organization שרוצים

הגדרת Secrets ב-Repository

בכל מסלול, חייבים להגדיר 3 Secrets ב-Repository שלכם ב-GitHub. ככה:

איך מוסיפים Secret: Repository → Settings → Secrets and variables → Actions → New repository secret. מדביקים את הערך (למפתח PEM — מדביקים את כל תוכן הקובץ, כולל שורות ה-BEGIN ו-END).

קובץ ה-Workflow הבסיסי

אחרי שה-Secrets מוגדרים, צריך ליצור את קובץ ה-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
    permissions:
      contents: read
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          app_id: ${{ secrets.APP_ID }}
          app_private_key: ${{ secrets.APP_PRIVATE_KEY }}

בואו נפרק מה כל חלק עושה:

• on: pull_request — ה-Workflow מופעל כשנפתח PR חדש (opened) או שדוחפים commits חדשים ל-PR קיים (synchronize)
• on: issue_comment — ה-Workflow מופעל כשמישהו כותב תגובה. ה-if בשורה הבאה מסנן רק תגובות שמכילות @claude
• permissions — מגדיר מה ל-Job מותר לעשות: לקרוא קוד (contents: read), לכתוב תגובות על PRs, ולכתוב על Issues
• fetch-depth: 0 — מוריד את כל ההיסטוריה של ה-repository (לא רק ה-commit האחרון) — חיוני כדי ש-Claude יוכל לחשב Diff
• anthropics/claude-code-action@v1 — ה-Action הרשמי שמפעיל את Claude Code עם ה-Secrets שהגדרנו

בדיקה שההתקנה עובדת

אחרי שפתחתם PR ראשון, בדקו שלושה דברים:

1. Claude הגיב: צריכה להיות תגובה מ-Claude על ה-PR עם ממצאי ה-Review. אם אין — בדקו ב-Actions Tab
2. @claude עובד: כתבו תגובה "@claude summarize this PR in Hebrew" ובדקו ש-Claude מגיב
3. Actions Tab ירוק: לכו ל-Actions → ובדקו שה-run סיים בהצלחה (סימן V ירוק)

אם משהו לא עובד — הבעיות הנפוצות:

טיפ לדיבאג: ב-Actions Tab, לחצו על ה-run שנכשל, פתחו את הלוגים של כל Step. שגיאת השורש תופיע שם — בדרך כלל ברורה למדי.

Code Review אוטומטי על PRs

Code Review הוא ה-Use Case הקלאסי ומה שרוב הצוותים מתחילים איתו. הרעיון פשוט: על כל PR, Claude קורא את ה-Diff (השינויים), מנתח את הקוד בהקשר של שאר ה-codebase, ומפרסם תגובה מסודרת עם ממצאים מדורגים לפי חומרה — CRITICAL, WARNING, ו-SUGGESTION.

מה Claude בודק בברירת מחדל

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

• איכות קוד (Code Quality): שכפול קוד, פונקציות ארוכות מדי, naming לא ברור, חוסר עקביות בדפוסים
• באגים פוטנציאליים: Race conditions, null/undefined references, off-by-one errors, logic errors
• אבטחה: SQL/NoSQL injection, XSS, חשיפת מידע רגיש, חוסר אימות
• ביצועים (Performance): N+1 queries, לולאות מיותרות, memory leaks, חוסר caching
• כיסוי טסטים: קוד חדש בלי טסטים, edge cases חסרים, מבנה טסטים לקוי
• תיעוד: פונקציות ציבוריות בלי documentation, API endpoints חסרי תיאור

אבל הכוח האמיתי הוא בהתאמה אישית — לגרום ל-Claude לבדוק מה שחשוב לכם, ולהתעלם ממה שכלים אחרים כבר מטפלים בו.

התאמה אישית עם CLAUDE.md

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

## CI/CD Context

When reviewing PRs in CI:

### Focus areas:
- Security: SQL injection, XSS, secret leaks, auth bypass
- Error handling: all async functions must have try/catch
- Hebrew strings: RTL issues, Unicode handling, translation coverage
- API contracts: breaking changes to public endpoints must be flagged

### Skip (handled by other tools):
- Formatting (Prettier handles this)
- Import order (ESLint rule)
- CSS property order

### Severity classification:
- CRITICAL: secrets in code, SQL injection, auth bypass, data loss risk
- WARNING: missing error handling, missing tests, N+1 queries
- SUGGESTION: performance improvements, readability, naming

### Response format:
- Summary in Hebrew
- Specific findings with file:line reference
- Code suggestion for each finding when possible

שימו לב לרמת הפירוט: אנחנו אומרים ל-Claude בדיוק מה לבדוק, מה לדלג (כי כלים אחרים כבר מטפלים), איך לדרג ממצאים, ובאיזה פורמט לכתוב. זה יוצר review עקבי — כל PR מקבל את אותה רמת בדיקה, בלי תלות במצב הרוח של reviewer אנושי.

Inline Comments — הערות על שורות ספציפיות

אחד הפיצ׳רים החזקים של claude-code-action: Claude לא רק כותב תגובה כללית על ה-PR. הוא מגיב על שורות ספציפיות ב-Diff, בדיוק כמו Reviewer אנושי. כשהוא מזהה בעיה בשורה 42, הוא פותח Inline Comment בדיוק שם, עם הסבר מפורט והצעת קוד מתוקן.

// Line 42 - src/api/users.js
// CRITICAL: SQL Injection vulnerability
//
// The user_id parameter comes directly from req.params
// without validation or sanitization.
//
// Before (vulnerable):
db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)
//
// After (safe):
db.query('SELECT * FROM users WHERE id = $1', [req.params.id])

// Line 78 - src/services/orders.js
// WARNING: N+1 Query Problem
//
// This loop fires a separate DB query for each order.
// 100 orders = 100 queries instead of 1.
//
// Consider using a batch query:
const allItems = await db.query(
  'SELECT * FROM items WHERE order_id = ANY($1)',
  [orderIds]
)

טיפול ב-PRs גדולים — Path Filtering

PR עם 500+ שורות שהשתנו הוא אתגר כפול: (1) Claude צריך הרבה טוקנים כדי לקרוא את כל ה-Diff, והעלות עולה. (2) PR גדול בדרך כלל כולל קבצים שלא צריכים review — כמו package-lock.json (אלפי שורות אוטומטיות), קבצי build, ותמונות. הפתרון — Path Filtering:

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    app_id: ${{ secrets.APP_ID }}
    app_private_key: ${{ secrets.APP_PRIVATE_KEY }}
    # Focus only on source code
    paths: |
      src/**
      lib/**
      !**/*.generated.ts
      !**/package-lock.json
      !**/*.min.js

עם Path Filtering, Claude מתמקד רק בקבצים שחשובים. ב-PR של 20 קבצים שהשתנו, אולי רק 5 הם source code אמיתי. זה חותך עלויות ב-75% וגם מייצר ממצאים רלוונטיים יותר — בלי רעש מ-lockfiles וקבצי build.

דפוס ה-Review Cascade — כשClaude רץ ראשון

הדפוס הכי אפקטיבי לצוותים הוא מה שנקרא Review Cascade — תהליך מדורג:

1. שלב 1 — בדיקות אוטומטיות: Linter, Type Checker, Unit Tests — בינאריים, מהירים, חינם
2. שלב 2 — Claude Review: בודק את מה שהכלים לא תופסים — לוגיקה, אבטחה, ביצועים. עלות: סנטים
3. שלב 3 — Review אנושי: הבודק האנושי מקבל PR "מנוקה" — כל הבעיות הפשוטות כבר נתפסו. הוא יכול להתמקד בשאלות גדולות: "האם האדריכלות נכונה?", "האם זה מתאים לרודמאפ?"

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

סריקות אבטחה בצנרת

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

למה Workflow נפרד לאבטחה — שלוש סיבות

1. מודל חזק יותר: לסריקת אבטחה כדאי להשתמש ב-Opus 4.6 (המודל החכם ביותר). עלות הפספוס של חולשת אבטחה — פריצה, דליפת מידע, קנסות — גבוהה הרבה יותר מהפרש עלות הטוקנים בין Sonnet ל-Opus
2. תזמון שונה: Review רץ על כל PR. סריקת אבטחה ייעודית רצה על Push ל-main ועל PRs שנוגעים בקבצים רגישים (auth, API, middleware, DB)
3. פלט שונה: Review נותן הערות. סריקת אבטחה נותנת ציון חומרה שיכול לחסום מיזוג דרך Security Gate

קובץ Workflow — Security Audit

name: Claude Security Audit

on:
  push:
    branches: [main, release/*]
  pull_request:
    paths:
      - 'src/auth/**'
      - 'src/api/**'
      - 'src/middleware/**'
      - 'src/db/**'

jobs:
  security-audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      security-events: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run dependency audit
        run: npm audit --json > npm-audit.json 2>/dev/null || true

      - uses: anthropics/claude-code-action@v1
        id: security
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          app_id: ${{ secrets.APP_ID }}
          app_private_key: ${{ secrets.APP_PRIVATE_KEY }}
          model: claude-opus-4-6
          prompt: |
            You are a senior application security engineer.
            Review this diff and codebase context for:

            1. OWASP Top 10 (injection, broken auth, XSS, SSRF)
            2. Secrets or API keys committed to code
            3. Unvalidated or unsanitized user input
            4. Insecure defaults or misconfigurations
            5. Missing input validation, rate limiting, CSRF
            6. Data exposure (PII logged, sensitive data in responses)

            Also review npm-audit.json for dependency risks.

            Rate each finding: CRITICAL / HIGH / MEDIUM / LOW.
            If ANY CRITICAL finding, start response with "SECURITY_BLOCK".

      - name: Check for critical findings
        if: always()
        run: |
          RESPONSE="${{ steps.security.outputs.response }}"
          if echo "$RESPONSE" | grep -q "SECURITY_BLOCK"; then
            echo "::error::CRITICAL security finding — merge blocked"
            exit 1
          fi
          echo "No critical security findings"

מה חכם כאן:

• תזמון כפול: כל Push ל-main (תמיד), ועל PRs רק בנתיבים רגישים (auth, API, middleware, DB)
• שילוב כלים: npm audit רץ קודם, תוצאות עוברות ל-Claude לפרשנות ותעדוף
• Opus 4.6: המודל החכם ביותר — על אבטחה לא חוסכים
• Security Gate: אם Claude מוצא חולשה קריטית, "SECURITY_BLOCK" מופיע ו-exit 1 חוסם Merge

שילוב עם כלי SAST מסורתיים

Claude לא מחליף Snyk, SonarQube, או Trivy — הוא משלים אותם. הדפוס העוצמתי ביותר הוא לרוץ SAST קודם ולהעביר תוצאות ל-Claude לפרשנות:

      - name: Run Snyk
        run: npx snyk test --json > snyk-results.json || true

      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review snyk-results.json. For each vulnerability:
            1. Is it actually exploitable in our codebase?
            2. Realistic impact?
            3. Recommended fix with code example?
            4. Priority: fix now / this sprint / can wait

SAST מוצא דפוסים. Claude מבין אם הדפוס מסוכן בהקשר שלכם. Snyk יגיד "vulnerability in lodash 4.17.20". Claude יבדוק אם אתם משתמשים בפונקציה הפגיעה ויגיד "כן, קריטי — אתם קוראים ל-_.template עם user input" או "לא דחוף — הפגיעות ב-_.merge שאתם לא קוראים". זה חוסך שעות של triage ידני על רשימות CVE ארוכות.

Release Notes אוטומטיים

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

Claude הופך את זה לאוטומטי: כשדוחפים Tag חדש (v2.1.0), ה-Workflow קורא היסטוריית Git מאז ה-Tag הקודם, שולף PRs שמוזגו, מעביר ל-Claude, ומקבל Release Notes מסודרים ובשפה אנושית.

קובץ ה-Workflow

name: Generate Release Notes

on:
  push:
    tags:
      - 'v*'

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

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

      - name: Get merged PRs
        id: prs
        run: |
          PREV_TAG=$(git describe --abbrev=0 --tags HEAD^ 2>/dev/null || echo "")
          DATE=$(git log -1 --format=%ci $PREV_TAG 2>/dev/null || echo '2020-01-01')
          PRS=$(gh pr list --state merged --search "merged:>=$DATE" \
            --json title,number \
            --jq '.[] | "- #\(.number) \(.title)"' 2>/dev/null || echo "")
          echo "prs<<EOF" >> $GITHUB_OUTPUT
          echo "$PRS" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - uses: anthropics/claude-code-action@v1
        id: notes
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          app_id: ${{ secrets.APP_ID }}
          app_private_key: ${{ secrets.APP_PRIVATE_KEY }}
          prompt: |
            Generate release notes for ${{ github.ref_name }}.

            Commits: ${{ steps.changes.outputs.changes }}
            PRs: ${{ steps.prs.outputs.prs }}

            Format:
            ## What's New
            ## Improvements
            ## Bug Fixes
            ## Breaking Changes (only if applicable)

            Rules: clear language, group related changes, bilingual
            (English + Hebrew for each item).

      - name: Create GitHub Release
        run: |
          gh release create ${{ github.ref_name }} \
            --title "Release ${{ github.ref_name }}" \
            --notes "${{ steps.notes.outputs.response }}"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

מה מיוחד: ה-Workflow שולף גם commits וגם PRs. כותרות PRs תיאוריות יותר מ-commit messages ונותנות ל-Claude הקשר עשיר יותר ליצירת Release Notes איכותיים.

Semantic Versioning אוטומטי

אפשר לבקש מ-Claude להמליץ על מספר הגרסה הבא. הוסיפו ל-Prompt:

Also recommend semantic version:
- MAJOR (x.0.0): breaking changes requiring user action
- MINOR (0.x.0): new features, backwards-compatible
- PATCH (0.0.x): bug fixes only
Current: v2.0.3. What should the next version be and why?

Claude ינתח את השינויים ויגיד למשל: "This is a MINOR release (v2.1.0) — includes 2 new features (search API, webhook support) with no breaking changes." כמובן שההמלצה צריכה אישור אנושי — אבל היא חוסכת את הדיון הצוותי של "זה major או minor?".

Release Notes בעברית ובאנגלית

בפרויקטים ישראליים, Release Notes דו-לשוניים הם יתרון גדול. הוסיפו ל-Prompt: Include both English and Hebrew for each item. Claude ייצר כל סעיף פעמיים — פעם באנגלית לצוות הטכני ופעם בעברית למנהלי מוצר ובעלי עניין.

## What's New / חדש
- Search API endpoint for products / API חיפוש מוצרים חדש
  Allows filtering by category, price, and availability
  מאפשר סינון לפי קטגוריה, מחיר, וזמינות

## Bug Fixes / תיקוני באגים
- Fixed login timeout on slow connections / תוקנה בעיית timeout בהתחברות
  Users on mobile networks experienced 30s timeouts, now set to 60s
  משתמשים ברשתות סלולריות חוו timeout של 30 שניות, עכשיו 60 שניות

Issue-to-PR — מ-Issue ל-Pull Request

הדפוס שמרגיש כמו קסם: מישהו פותח Issue, מוסיף Label ספציפי, Claude מנתח, כותב קוד, מריץ טסטים, ופותח Draft PR. ובעברית: אפשר לכתוב Issues בעברית ("הכפתור 'הוסף לעגלה' לא עובד בדף המוצר") ו-Claude יבין, ימצא קוד, יתקן, ויפתח PR עם תיאור באנגלית.

קובץ ה-Workflow

name: Issue to PR

on:
  issues:
    types: [labeled]

jobs:
  auto-implement:
    if: contains(github.event.label.name, 'claude-auto')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          app_id: ${{ secrets.APP_ID }}
          app_private_key: ${{ secrets.APP_PRIVATE_KEY }}
          prompt: |
            Implement the change described in issue
            #${{ github.event.issue.number }}:
            Title: ${{ github.event.issue.title }}
            Body: ${{ github.event.issue.body }}

            Steps:
            1. Analyze codebase to find relevant code
            2. Create branch: auto/${{ github.event.issue.number }}
            3. Implement with clean, tested code
            4. Run existing tests
            5. Open Draft PR referencing the issue

            If too complex or ambiguous, comment on the issue
            asking for clarification instead of implementing.
            Always open as Draft PR. Include tests.

ה-Workflow מופעל רק עם Label claude-auto. שליטה מלאה — לא כל Issue יגרום ליצירת PR. רק Issues שהצוות מסמן במפורש כמתאימים לאוטומציה.

מה עובד ומה לא

מצוין עבור:

• תיקוני באגים ברורים: "הכפתור X לא עובד כשלוחצים פעמיים" — Claude מוצא הבעיה ומתקן
• משימות מוגדרות: "הוסיפו validation למייל בטופס הרשמה" — ברור מה צריך
• עדכוני תצורה: "שנו timeout מ-30 ל-60 שניות" — פשוט וחד-משמעי
• Good first issue: משימות קטנות שמתאימות ל-contributors חדשים

לא מתאים ל:

• פיצ׳רים מורכבים שדורשים תכנון אדריכלי וראייה רחבה
• Issues עמומים — "הביצועים לא טובים" (מה בדיוק? איפה? לפי איזה מדד?)
• שינויים בחוויית משתמש שדורשים שיקול דעת עיצובי
• Refactoring נרחב שמשפיע על מודולים רבים

Issues בעברית

יתרון מפתיע: אפשר לכתוב Issues בעברית מלאה. Claude מבין עברית ויכול לנתח Issue שכתוב "הכפתור 'הוסף לעגלה' בדף המוצר לא מגיב ללחיצה כשהמשתמש כבר הוסיף 3 פריטים" — הוא ימצא את הקוד הרלוונטי, יתקן, ויפתח PR עם תיאור באנגלית (או בעברית, אם תגדירו ב-CLAUDE.md). זה מאפשר גם לאנשים שלא טכניים לפתוח Issues שClaude יטפל בהם.

Issue-to-PR — הגדרות בטיחות

כמה הגדרות בטיחות שמומלץ להוסיף:

• Label ספציפי: רק claude-auto מפעיל את ה-Workflow. אל תשתמשו ב-Labels כלליים כמו "bug" — לא כל באג מתאים לאוטומציה
• Branch Protection: ודאו שה-main branch דורש PR review לפני merge — ככה גם אם Claude פותח PR, הוא לא יכול למזג לבד
• הגבלת scope: בקשו מ-Claude ב-Prompt שאם ה-Issue מורכב מדי, הוא יגיב על ה-Issue במקום לנסות לפתור — "If the issue requires changes to more than 3 files or architectural decisions, comment asking for clarification instead of implementing"

CLAUDE.md בסביבת CI

בקורסים הקודמים למדנו ש-CLAUDE.md הוא קובץ ההוראות של Claude — הזיכרון המתמשך. חדשות טובות: הוא עובד גם ב-CI. כש-claude-code-action רץ, הוא טוען CLAUDE.md מה-Repository אוטומטית. הוראות שנכתבות פעם אחת משפיעות על כל ריצת CI.

מבנה מומלץ

# Project: My SaaS App

## Project Context (Always)
- Node.js 20 + TypeScript + React 19
- PostgreSQL with Prisma ORM
- Hebrew-first (RTL, Unicode)
- Deployed to Vercel

## Coding Standards (Always)
- JSDoc on all exported functions
- Error handling with AppError class
- Hebrew strings via i18n only
- Tests for all business logic

## CI/CD Context
When reviewing PRs in CI:
- Focus: security, error handling, Hebrew coverage
- Skip: formatting (Prettier), imports (ESLint)
- Severity: CRITICAL / WARNING / SUGGESTION
- Be concise in CI — findings only

## Security Requirements
- CRITICAL: any secret or API key in code
- CRITICAL: unvalidated user input reaching DB
- HIGH: missing rate limiting on public endpoints
- HIGH: missing auth on protected routes

כללים מותנים — .claude/rules/

קבצי .md ב-.claude/rules/ נטענים אוטומטית. YAML frontmatter מגביל מתי:

# .claude/rules/ci-auth-review.md
---
activation:
  context: ci
  paths:
    - src/auth/**
    - src/api/middleware/**
---

When reviewing authentication code:
- JWT: verify expiry check and signature validation
- Passwords: bcrypt with cost >= 12 (not MD5/SHA)
- Sessions: httpOnly + sameSite + secure cookie flags
- Login: rate limit max 5 attempts/minute

הכלל נטען רק ב-CI ורק לנתיבי auth/middleware. חוסך טוקנים ומייצר ממצאים ממוקדים.

סביבה-מודעת — Environment-Aware

ב-GitHub Actions, משתנה הסביבה CI=true קיים אוטומטית. אפשר לנצל את זה ב-CLAUDE.md כדי ש-Claude יתנהג אחרת ב-CI לעומת סשן אינטראקטיבי:

## Environment Behavior
If running in CI (CI=true):
- Do NOT ask interactive questions — default to safe choices
- Output structured findings with severity labels
- Be concise — findings and recommendations only, no tutorials
- Always include file path and line number with each finding
- Default to blocking on CRITICAL findings

למה זה חשוב? כי ב-CI אין מי שיענה על שאלות. אם Claude מבקש "Should I also check the test files?" — אין מי שיגיד כן. הוא צריך לפעול באופן עצמאי ולהחזיר תוצאות מובנות.

שיתוף CLAUDE.md בצוות

הכי חשוב: ה-CLAUDE.md חייב להיות ב-Git. כשהוא committed ל-Repository, כל מפתח וכל ריצת CI מקבלים את אותן הוראות. זה מבטיח עקביות — Claude בודק את אותם הדברים לכולם, ולא משנה מי פתח את ה-PR או מאיזה branch.

טיפ: צרפו את .claude/rules/ גם ל-Git. מפתחים חדשים שמצטרפים לצוות מקבלים אוטומטית את כל הכללים שלמדתם מניסיון.

Workflows מותאמים אישית

Review, אבטחה, Release Notes — ההתחלה. Claude ב-CI יכול הרבה יותר. הנה 5 דפוסים מעשיים:

1. Documentation Sync

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

name: Sync API Docs
on:
  push:
    branches: [main]
    paths: ['src/api/**']
jobs:
  sync-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          app_id: ${{ secrets.APP_ID }}
          app_private_key: ${{ secrets.APP_PRIVATE_KEY }}
          prompt: |
            API routes changed. Update docs/api/ to match:
            - description, method, URL, parameters, response, errors
            - Match existing style. Open PR with updates.

2. i18n Validation — בדיקת תרגומים

קריטי לפרויקטים ישראליים. Claude מוודא שכל String חדש קיים בעברית ובאנגלית:

prompt: |
  Scan changed files for new user-facing strings.
  Check each exists in locales/he.json and locales/en.json.
  Report missing translations with file path and string text.

3. Dependency Review

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

prompt: |
  For each updated package: read changelog, assess risk
  (LOW=patch, MEDIUM=minor, HIGH=major/breaking),
  flag security changes, recommend merge strategy.

4. Test Generation

קוד חדש בלי טסטים? Claude מייצר test stubs:

prompt: |
  For new functions without tests, generate meaningful
  test cases (happy path + edge cases). Follow existing
  test patterns. Open separate PR with tests.

5. Migration Safety

Claude בודק שמיגרציות DB בטוחות ו-reversible:

prompt: |
  Review migration files for: data loss risk,
  missing rollback, long-running ops on large tables,
  breaking changes to existing queries.

טיפ: איטרציה על Prompts

ה-Prompt הוא הלב של כל Workflow מותאם. בפעם הראשונה, הוא כנראה לא יהיה מושלם. התהליך המומלץ:

1. כתבו Prompt ראשוני — מה שנראה לכם הגיוני
2. הריצו על PR אמיתי — בדקו מה Claude מחזיר
3. שפרו: אם Claude מפספס — הוסיפו הנחיות. אם הוא נותן יותר מדי — צמצמו
4. חזרו עוד 2-3 סיבובים עד שהתוצאות מדויקות

זה בדיוק כמו לכתוב Test Cases — אתם צריכים לדעת מה אתם מצפים לקבל כדי לדעת אם התוצאה טובה.

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

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

Tiered Review — מודל לכל משימה

5 טכניקות חיסכון שעובדות

1. Path Filtering (הכי אפקטיבי): סרקו רק קבצי source code. ב-PR ממוצע, 40-60% מהשינויים הם lock files, configs, וקבצים שנוצרו אוטומטית שלא צריכים review. Path Filtering חותך עלויות ב-50-75% מיידית
2. MAX_THINKING_TOKENS=8192: הגדירו את משתנה הסביבה הזה ב-CI. רוב משימות CI לא דורשות חשיבה עמוקה — Claude יכול לתת תשובה ישירה. זה חותך את עלות הטוקנים של extended thinking
3. --bare flag: חוסך 2-5 שניות startup per invocation. לא חוסך טוקנים, אבל ב-GitHub Actions Minutes זמן = כסף. על 100+ ריצות בשבוע — זה מצטבר
4. Skip Logic: אם אותם קבצים לא השתנו מאז ה-Review האחרון — דלגו על הריצה. אפשר לממש עם cache של SHA hashes ותנאי if ב-Workflow
5. Budget Alerts: היכנסו ל-Anthropic Console → Usage → הגדירו התראה ב-80% מהתקציב החודשי. ככה תדעו לפני שנגמר הכסף ולא תתעוררו מופתעים

דוגמה לחישוב ריאלי

נניח סטארטאפ ישראלי קטן עם 4 מפתחים:

$62 בחודש — כ-220 ש"ח (לפי שער של 3.6 ש"ח/$) — עבור Code Review + Security Audit + Release Notes + i18n Validation על כל PR ועל כל push. לשם השוואה: שכר שעתי ממוצע של מפתח Full Stack בישראל (2026) הוא 180-280 ש"ח לשעה. אם Claude חוסך אפילו שעה אחת בשבוע של review אנושי (ובדרך כלל הוא חוסך יותר) — ה-ROI חיובי מאוד. סטארטאפ ישראלי אופייני עם 4-6 מפתחים יחסוך 4-8 שעות review בשבוע, שזה 720-2,240 ש"ח/שבוע בערך — לעומת 55 ש"ח/שבוע עלות Claude.

שימו לב שהמספרים נכונים למרץ 2026. Anthropic משנים מחירים מעת לעת — בדרך כלל למטה. מחירי Sonnet ירדו פי 5 בשנה האחרונה. כדאי לבדוק מחירים עדכניים ב-console.anthropic.com/pricing כשאתם מחשבים תקציב. וזכרו שגם GitHub Actions Minutes עולים — ראו את ההערה למטה.

CI/CD מעבר ל-GitHub — GitLab, Jenkins ואחרים

הדפוס האוניברסלי עובד בכל מערכת CI שתומכת ב-Shell:

claude -p "review this diff for security issues" --bare

GitLab CI

# .gitlab-ci.yml
claude-review:
  stage: test
  image: node:20
  before_script:
    - npm install -g @anthropic-ai/claude-code
  script:
    - git diff origin/main...HEAD | claude -p "Review this diff. CRITICAL/WARNING/SUGGESTION format." --bare
  variables:
    ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Jenkins

pipeline {
    agent any
    environment {
        ANTHROPIC_API_KEY = credentials('anthropic-api-key')
    }
    stages {
        stage('Claude Review') {
            when { changeRequest() }
            steps {
                sh '''
                    npm install -g @anthropic-ai/claude-code
                    git diff origin/main...HEAD | \
                    claude -p "Review for quality and security" --bare \
                    > claude-review.txt
                '''
                archiveArtifacts artifacts: 'claude-review.txt'
            }
        }
    }
}

CircleCI

jobs:
  claude-review:
    docker:
      - image: node:20
    steps:
      - checkout
      - run: npm install -g @anthropic-ai/claude-code
      - run: git diff origin/main...HEAD | claude -p "Review this diff" --bare

Azure DevOps

steps:
  - task: Bash@3
    displayName: 'Claude Review'
    inputs:
      targetType: 'inline'
      script: |
        npm install -g @anthropic-ai/claude-code
        git diff origin/main...HEAD | claude -p "Review" --bare
    env:
      ANTHROPIC_API_KEY: $(ANTHROPIC_API_KEY)

הדפוס האוניברסלי — מה שמשותף לכולם

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

1. התקינו Claude Code: npm install -g @anthropic-ai/claude-code
2. הגדירו API Key: דרך Secrets/Credentials של המערכת
3. חשבו Diff: git diff origin/main...HEAD
4. שלחו ל-Claude: echo "$DIFF" | claude -p "Review this" --bare
5. תפסו פלט: שמרו כ-artifact, שלחו כ-comment, או בדקו exit code

זה עובד בכל מקום. ההבדל בין מערכות הוא רק תחביר ההגדרות (YAML ב-GitHub/GitLab, Groovy ב-Jenkins, JSON ב-Azure) ואיך מנהלים Secrets. הלוגיקה זהה.

claude-code-action vs CLI — השוואה

הערה על Bedrock ו-Vertex

אם הארגון שלכם משתמש ב-AWS Bedrock או Google Vertex AI במקום ב-API הישיר של Anthropic — הגדירו את משתני הסביבה המתאימים:

• AWS Bedrock: CLAUDE_CODE_USE_BEDROCK=1 + AWS credentials (IAM role recommended)
• Google Vertex: CLAUDE_CODE_USE_VERTEX=1 + Google Cloud credentials

claude-code-action@v1 תומך בשני הפרוביידרים. פשוט החליפו anthropic_api_key ב-credentials המתאימים. היתרון: billing דרך חשבון הענן הקיים שלכם, compliance מובנה, ואולי מחירים מוזלים אם יש לכם הסכם enterprise עם AWS או Google.

דוגמה מהשטח: שיפור הדרגתי של CLAUDE.md

שבוע 1: מגדירים CLAUDE.md בסיסי. Claude נותן review שכולל הרבה הערות על formatting — אבל יש לכם Prettier שמטפל בזה. תוסיפו לסעיף Skip: "formatting (Prettier handles this)".

שבוע 2: Claude מסמן SQL injection על כל שימוש ב-Prisma ORM — אבל Prisma כבר מטפל בפרמטריזציה. תוסיפו: "Prisma ORM handles parameterization — only flag raw SQL queries (prisma.$queryRaw)."

שבוע 3: Claude לא תופס שאתם שוכחים תמיד auth middleware על routes חדשים. תוסיפו: "CRITICAL: Every new API route in src/api/ MUST have authMiddleware. Flag any route without it."

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