Claude Code ב-GitHub Actions: ביקורת קוד אוטומטית בכל PR

מאת צוות מדיה דיל · 08.08.2026 · AI · 9 דק׳

איך מתקינים את Claude Code ב-GitHub Actions כדי לקבל ביקורת קוד אוטומטית, טיפול ב-issues ומענה ל-@claude ישירות בתוך ה-pull requests, בלי לחכות ל-reviewer פנוי.

כל מנהל פיתוח מכיר את הרגע הזה: PR נפתח בשעה שמונה בבוקר, המפתח שכתב אותו כבר עבר לטאסק הבא, וה-reviewer היחיד שמבין את המודול הזה בחופשה. שעתיים הופכות ליום, יום הופך לשלושה, וה-PR פשוט מזדקן בתור. באותו זמן, issue חדש נפתח עם תיאור באג מבולבל, ואף אחד לא ממש יודע אם הוא כפול, קריטי, או סתם misunderstanding. זו לא בעיה של כישרון או משמעת - זו בעיה של bandwidth אנושי מוגבל שצריך להיפרס על כל PR, כל commit, כל issue, כל הזמן. Claude Code ב-GitHub Actions נבנה בדיוק בשביל הפער הזה: להזרים סוכן AI לתוך ה-CI/CD pipeline שלכם כדי שחלק מהעבודה הזאת תקרה אוטומטית, בלי לחכות לבן אדם פנוי.

מה זה האינטגרציה ואיזו בעיה היא פותרת

Claude Code GitHub Actions היא GitHub Action שמריצה את Claude Code בתוך ה-workflows של הריפו שלכם. במקום להריץ אותו רק מהטרמינל המקומי, אתם מתקינים אותו כשלב ב-CI, והוא רץ אוטומטית על אירועים ב-GitHub - פתיחת PR, תגובה עם תיוג, פתיחת issue, ואפילו לפי לוח זמנים קבוע. שני מצבי הפעלה עומדים בבסיס האינטגרציה: מצב אינטראקטיבי, שבו Claude ממתין לאזכור @claude בתגובה על PR או issue ומגיב לבקשה הספציפית שם, ומצב אוטומציה, שבו נותנים ל-workflow קלט prompt קבוע מראש והוא רץ בלי לחכות לאזכור בכלל - למשל דוח יומי או ריצת בדיקה על כל PR חדש.

הבעיה שזה פותר היא לא "להחליף reviewer אנושי" אלא לצמצם את הזמן שבו PR או issue יושבים בלי שום תגובה. Claude יכול לנתח קוד, לענות על שאלות, לתקן באג לפי תיאור בתגובה, ואפילו לדחוף commits חדשים - הכל כתגובה לאירוע ב-GitHub, בלי שמישהו יצטרך לפתוח IDE. מי שכבר מכיר את העבודה עם Claude Code בסביבת הפיתוח המקומית יזהה כאן את אותו מנוע, רק שהוא רץ עכשיו בתוך runner של GitHub Actions במקום על המחשב שלכם.

חשוב להבחין בין שני מוצרים דומים בשם: יש את Code Review - סקירה אוטומטית שרצה על כל PR בלי צורך לכתוב workflow בכלל, ויש את האינטגרציה שבה עוסק המאמר הזה - claude-code-action, שאותה מגדירים בעצמכם עם קובצי workflow בריפו. האחרונה נותנת שליטה מלאה על הטריגרים, הפרומפט, המודל וההרשאות, ולכן היא המתאימה כשרוצים להתאים את ההתנהגות בדיוק לתהליך העבודה של הצוות.

איך מתקינים את זה

יש שתי דרכי התקנה, ושתיהן דורשות הרשאות admin על הריפו.

התקנה מהירה עם /install-github-app

אם כבר עובדים עם Claude Code מקומית, הדרך הפשוטה ביותר היא לפתוח את claude בתוך תיקיית הריפו ולהריץ את הפקודה /install-github-app. לפני כן צריך להתקין את GitHub CLI ולהתחבר אליו עם gh auth login - Claude Code בודק את זה ומתריע אם חסר. הפקודה מתקינה עבורכם את ה-GitHub App של Claude, מגדירה secret לאימות (אם כבר יש מפתח API הוא ישתמש בו, אחרת תבחרו בין יצירת טוקן ארוך-טווח מהמנוי או הזנת מפתח API), ולבסוף דוחפת branch עם קובצי ה-workflow שבחרתם ופותחת בדפדפן PR מוכן ליצירה. אחרי מיזוג ה-PR, האזכור @claude כבר עובד בריפו.

התקנה ידנית

למי שלא מריץ Claude Code מקומית, או פשוט רוצה שליטה מלאה על קבצי ה-workflow, יש מסלול ידני בשלושה צעדים:

התקנת ה-GitHub App - מתקינים את Claude GitHub App על הריפו. האפליקציה מבקשת הרשאות Contents, Issues ו-Pull requests בקריאה וכתיבה, שהן ההרשאות שה-action בפועל צריך.
הוספת secret לאימות - מוסיפים לריפו את ANTHROPIC_API_KEY (מפתח API מ-Claude Console) או CLAUDE_CODE_OAUTH_TOKEN (טוקן שנוצר עם הפקודה claude setup-token ומשתמש במנוי Pro, Max, Team או Enterprise).
העתקת קובץ ה-workflow - מעתיקים את הקובץ examples/claude.yml מהריפו הרשמי של הפרויקט לתוך .github/workflows/. הקובץ עובד כפי שהוא - Claude מגיב בכל פעם שמישהו מזכיר @claude בתגובה על issue או PR.

לפריסה ברמת ארגון שלם, מתקינים את ה-GitHub App פעם אחת ברמת הארגון (על כל הריפואים או רשימה נבחרת), שומרים את ה-secret כ-organization-level secret כדי שלא כל ריפו יצטרך עותק משלו, ומוסיפים את קובץ ה-workflow לכל ריפו רלוונטי - או מגדירים אותו כ-reusable workflow אחד שכל ריפו קורא אליו. כדאי במקרה כזה להשתמש דווקא במפתח API ולא בטוקן OAuth, כי טוקן OAuth קשור למנוי האישי של מי שהריץ את claude setup-token. מי שרוצה להימנע מאחסון secret ארוך-טווח לגמרי יכול לאמת דרך workload identity federation - ה-action מחליף את ה-GitHub OIDC token של ה-workflow בגישה ל-Claude API דרך Claude Console service account.

טריגרים ודוגמאות workflow

הטריגר הבסיסי ביותר הוא אזכור @claude בתגובה על issue או PR. ה-workflow הבא מריץ את Claude במצב אינטראקטיבי, כך שהוא מגיב בכל פעם שמישהו מתייג אותו בתגובה על issue או pull request:

on: issue_comment מסוג created, ו-pull_request_review_comment מסוג created
תנאי if שבודק שהתגובה מכילה @claude, כדי שה-runner לא יעלה סתם על כל תגובה
הרשאות ל-job: contents, pull-requests, issues בכתיבה, ו-id-token ו-actions בקריאה
שלב checkout כדי לתת ל-Claude עותק מקומי של הריפו לעבוד עליו
שלב anthropics/claude-code-action@v1 עם ה-secret של ה-API key

לאחר שה-workflow מוגדר, אפשר לכתוב בתגובה משהו כמו "@claude implement this feature based on the issue description" או "@claude fix the TypeError in the user dashboard component" - Claude יגיב בתגובה על אותו PR או issue ויעדכן אותה תוך כדי עבודה.

הרצת ביקורת קוד עם prompt קבוע

כשנותנים ל-action קלט prompt, הוא עובר למצב אוטומציה ורץ בלי לחכות לאזכור בכלל - למשל על כל פתיחה או עדכון של PR. אפשר להריץ בו skill מוכן, כמו plugin ה-code-review הרשמי, על pull_request מסוג opened ו-synchronize. במקרה כזה Claude כותב את הממצאים ל-workflow run log במקום לפרסם אותם כתגובה על ה-PR, כך שהצוות פותח את ה-Actions tab כדי לקרוא אותם. שימו לב: בריפואים ציבוריים GitHub חוסם secrets מ-PRs שמגיעים מ-fork, כך שהביקורת האוטומטית רצה רק על PRs מ-branches באותו ריפו.

הרצה לפי לוח זמנים

אותו מנגנון עובד גם עם טריגר schedule ב-cron, למשל דוח יומי בשעה תשע בבוקר UTC שמסכם commits ו-issues פתוחים. כשנותנים ל-Claude prompt כטקסט חופשי הוא לא מקבל גישה ל-shell או ל-GitHub API עד שמעניקים לו את הכלים דרך --allowedTools ב-claude_args, ולכן בדוגמת ה-cron מוסיפים גישה לכלי MCP ספציפיים כמו mcp__github__list_commits ו-mcp__github__list_issues כדי שיוכל לקרוא נתונים בלי checkout בכלל. שווה לציין ש-GitHub מריץ workflows מתוזמנים רק מה-branch הראשי, ובריפואים ציבוריים מכבה את הלוח זמנים אחרי 60 יום בלי פעילות בריפו.

כל הדוגמאות האלה מבוססות על אותו מנגנון אירועים שמפעיל כל automation אחר ב-GitHub - למי שרוצה רקע רחב יותר על חיבור GitHub API לתהליכי CI/CD, יש הרחבה נפרדת במדריך על אוטומציית CI/CD עם GitHub API.

הרשאות ואבטחה - מה חשוב לבדוק לפני שמפעילים

ה-GitHub App של Claude משותף לכמה פיצ'רים - claude-code-action, Code Review, ו-auto-fix ל-PRs מ-Claude Code on the web - ולכן סט ההרשאות שהוא מבקש רחב מהמינימום שה-action הזה בפועל צריך. בהתקנה מלאה מקבלים גישת קריאה וכתיבה ל-Actions, Checks, Contents, Discussions, Issues, Pull requests, Repository hooks ו-Workflows, וגישת קריאה בלבד ל-Members ו-Metadata. GitHub לא מאפשר לאשר רק תת-קבוצה - זו כל החבילה או כלום. לארגון שדורש בדיוק את ההרשאות שה-action משתמש בהן (Contents, Issues, Pull requests) ולא יותר, אפשר ליצור GitHub App מותאם אישית במקום - אבל אז Code Review ו-auto-fix כבר לא יעבדו, כי הם דורשים דווקא את האפליקציה הרשמית.

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

הרשאת כתיבה - באירועי issue ו-PR, למי שהפעיל את הטריגר חייבת להיות הרשאת כתיבה על הריפו. כדי לאפשר משתמשים ספציפיים בלי הרשאת כתיבה, מגדירים allowed_non_write_users ומעבירים github_token משלכם. אירועים שאין להם משתמש כמפעיל, כמו טריגר schedule, פטורים מהבדיקה הזאת.
בדיקת "אדם אמיתי" - בכל אירוע, ה-action דוחה actor שהוא בוט אלא אם הוא מופיע ברשימת allowed_bots, כדי שבוטים לא יפעילו את Claude בלולאה אינסופית. גם ריצות מתוזמנות עוברות את הבדיקה הזאת, כי GitHub משייך אותן למשתמש שערך לאחרונה את לוח הזמנים ב-cron.

כמה כללי אצבע שכדאי לאמץ: לעולם לא לכתוב API key או OAuth token ישירות בקוד - תמיד כ-GitHub Secret ולהפנות אליו עם ${{ secrets.ANTHROPIC_API_KEY }}; להעניק ל-workflow רק את ההרשאות שהוא באמת צריך ולא יותר; ותמיד לבדוק את השינויים של Claude לפני מיזוג, גם כשה-workflow רץ אוטומטית. כדאי גם לשים לב שאם מעבירים github_token: ${{ secrets.GITHUB_TOKEN }}, GitHub לא מפעיל workflows נוספים על commits שנוצרו איתו - אם רוצים ש-CI ירוץ על commits של Claude, צריך להסיר את השורה הזו כדי שה-action יאמת כ-GitHub App, או להעביר טוקן מותאם אחר.

שכבת ההרשאות הזו משלימה תרגול שכבר מוכר למי שמריץ Claude Code כ-skills או פקודות מותאמות - עקרון ה"לתת בדיוק את מה שצריך ולא יותר" חוזר גם במדריך על skills ו-commands מותאמים אישית ב-Claude Code.

תרחיש אמיתי: צוות פיתוח בינוני שמפעיל את זה בפועל

נניח צוות של שמונה מפתחים שעובד על מוצר SaaS עם קצב שחרור גבוה. לפני האינטגרציה, כל PR חיכה בממוצע חצי יום עד שreviewer פנוי הגיב, ו-issues נכנסו לתור בלי סיווג ברור בין "קריטי" ל"nice to have". אחרי שהתקינו את claude-code-action עם שני workflows - האחד למצב אינטראקטיבי שמגיב לאזכורי @claude, והשני לביקורת אוטומטית שרצה על כל PR חדש - זרימת העבודה נראית כך: מפתח פותח PR, ה-workflow של הביקורת רץ מיד ומייצר ממצאים ראשוניים ב-run log לפי plugin ה-code-review; אם יש שאלה או בקשה נקודתית, מישהו בצוות מגיב עם "@claude תסביר למה הפונקציה הזו לא מטפלת ב-null" והתשובה מגיעה תוך דקות כתגובה על אותו PR; ובבוקר, workflow מתוזמן מייצר סיכום קצר של commits ו-issues פתוחים מהיממה האחרונה, כך שה-lead רואה תמונת מצב בלי לפתוח עשרות טאבים.

התוצאה בפועל היא לא "פחות reviewers" אלא זמן תגובה קצר משמעותית לכל PR או issue, במיוחד באזורי זמן שבהם אף מפתח לא ער. הצוות עדיין קורא ומאשר כל שינוי בעצמו - Claude לא ממזג PR-ים לבד - אבל השלב שבו PR פשוט "מחכה בשקט" כמעט נעלם. הגדרת CLAUDE.md ברמת הריפו, עם כללי סגנון קוד וקריטריוני review ספציפיים לפרויקט, עוזרת ל-Claude לפעול לפי אותם סטנדרטים שהצוות כבר מיישם ידנית - כך שהממצאים שהוא כותב לא סותרים את הקונבנציות הפנימיות.

שאלות נפוצות

מה ההבדל בין claude-code-action לבין Code Review?

Code Review היא ביקורת אוטומטית שרצה על כל PR בלי צורך לכתוב או לתחזק קובץ workflow בכלל. claude-code-action, שבה עוסק המאמר הזה, היא ה-action שמגדירים בעצמכם עם קבצי workflow משלכם - נותן שליטה מלאה על הטריגרים, הפרומפט, המודל וההרשאות, אבל דורש תחזוקה של קובץ ה-YAML.

איך Claude מגיב לתגובה שמזכירה אותו?

כשה-workflow לא מגדיר קלט prompt, ה-action עובד במצב אינטראקטיבי וממתין לביטוי הטריגר, כברירת מחדל @claude, בתגובה על issue או PR, בביקורת PR, או בגוף או כותרת של issue חדש. התוצאה מתפרסמת כתגובה על אותו issue או PR ומתעדכנת תוך כדי העבודה.

איזה secret צריך להגדיר בריפו כדי שזה יעבוד?

או ANTHROPIC_API_KEY - מפתח API מ-Claude Console - או CLAUDE_CODE_OAUTH_TOKEN, טוקן שנוצר עם הפקודה claude setup-token ומשתמש במנוי Pro, Max, Team או Enterprise. בקובץ ה-workflow מעבירים אותו לפרמטר anthropic_api_key או claude_code_oauth_token בהתאמה.

למה Claude לא מגיב כשמתייגים אותו בתגובה?

הבדיקות הנפוצות: לוודא שה-GitHub App מותקן על הריפו, שה-workflows מופעלים בריפו, שה-secret עם המפתח או הטוקן קיים, שהתגובה מכילה @claude כמילה שלמה ולא /claude או @claude-bot, ושלמשתמש שכתב את התגובה יש הרשאת כתיבה על הריפו.

האם אפשר להריץ את זה גם דרך Amazon Bedrock או Google Cloud?

כן. במקום לקרוא ל-Claude API ישירות עם מפתח API או טוקן OAuth, אפשר להגדיר use_bedrock, use_vertex או use_foundry כדי לנתב את ה-inference דרך Amazon Bedrock, Google Cloud's Agent Platform או Microsoft Foundry בהתאמה. בכל שלושת המקרים מתאמתים דרך OIDC identity federation, כך שלא שומרים credentials קבועים בריפו.

למה CI לא רץ אוטומטית על commits שClaude דוחף?

GitHub לא מפעיל workflows על commits שנוצרו עם ה-GITHUB_TOKEN הדיפולטיבי. אם מעבירים github_token: ${{ secrets.GITHUB_TOKEN }} לפרמטר של ה-action, צריך להסיר אותו כדי שהוא יאמת כ-GitHub App במקום, או להעביר טוקן מותאם אישית אחר - ואז לוודא שטריגרי ה-CI כוללים את האירועים שה-push של Claude מייצר, כמו push או pull_request.

אם אתם רוצים להטמיע את claude-code-action בצורה שמתאימה בדיוק לתהליך העבודה של הצוות שלכם - מבחירת הטריגרים הנכונים ועד הגדרת הרשאות מדויקות ו-CLAUDE.md שמשקף את סטנדרט הקוד שלכם - צוות מדיה דיל ישמח לעזור. דברו איתנו בוואטסאפ.

תגיות: Claude Code GitHub Actions · ביקורת קוד אוטומטית · CI CD אוטומציה · claude-code-action · GitHub App · אוטומציה בפיתוח תוכנה · code review אוטומטי

← חזרה לבלוג · צור קשר