סקיל GH Fix CI
gh-fix-ci הוא סקיל לקלוד קוד שמאתר ומתקן בדיקות PR שנכשלות ורצות ב-GitHub Actions. הוא משתמש ב-gh CLI כדי לאתר את הבדיקות הכושלות, שולף את הלוגים של GitHub Actions, מסכם את קטע הכשל, מנסח תוכנית תיקון, ומיישם אותה רק אחרי אישור מפורש. הסקיל מתמקד ב-GitHub Actions בלבד: ספקים חיצוניים כמו Buildkite מסומנים כמחוץ לתחום, ורק כתובת הפרטים שלהם מדווחת. אחרי התיקון הוא ממליץ להריץ מחדש את הבדיקות. בפרויקטי הפיתוח שאני מוביל, CI ירוק הוא תנאי למיזוג, ותיקון מהיר של כשלים שומר על זרימת העבודה. במדריך תקבלו את כל ההנחיות, ארבעה תרחישי שימוש, וצ'קליסט איכות.
פקודת התקנה
npx skills add openai/skills@gh-fix-ci -g -y
ההתקנה מתבצעת דרך מנהל החבילות הרשמי של הסקילים בפקודה אחת. הסקיל הוא קובץ Markdown פתוח עם סקריפט Python, ומופעל כשמבקשים לתקן בדיקות CI שנכשלות. דורש את gh CLI מאומת. אפשר להוריד ולבדוק את הקוד דרך הכפתורים שבראש העמוד.
מה הסקיל כולל?
הסקיל מתעד תיקון בדיקות CI שנכשלות: איתור הבדיקות הכושלות, שליפת לוגים מ-GitHub Actions, סיכום הכשל, ניסוח תוכנית תיקון, יישום אחרי אישור, ובדיקה חוזרת.
קוד הסקיל המלא
---
name: "gh-fix-ci"
description: "Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL."
---
# Gh Pr Checks Plan Fix
## Overview
Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix plan and implement after explicit approval.
- If a plan-oriented skill (for example `create-plan`) is available, use it; otherwise draft a concise plan inline and request approval before implementing.
Prereq: authenticate with the standard GitHub CLI once (for example, run `gh auth login`), then confirm with `gh auth status` (repo + workflow scopes are typically required).
## Inputs
- `repo`: path inside the repo (default `.`)
- `pr`: PR number or URL (optional; defaults to current branch PR)
- `gh` authentication for the repo host
## Quick start
- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
- Add `--json` if you want machine-friendly output for summarization.
## Workflow
1. Verify gh authentication.
- Run `gh auth status` in the repo.
- If unauthenticated, ask the user to run `gh auth login` (ensuring repo + workflow scopes) before proceeding.
2. Resolve the PR.
- Prefer the current branch PR: `gh pr view --json number,url`.
- If the user provides a PR number or URL, use that directly.
3. Inspect failing checks (GitHub Actions only).
- Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
- Add `--json` for machine-friendly output.
- Manual fallback:
- `gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow`
- If a field is rejected, rerun with the available fields reported by `gh`.
- For each failing check, extract the run id from `detailsUrl` and run:
- `gh run view <run_id> --json name,workflowName,conclusion,status,url,event,headBranch,headSha`
- `gh run view <run_id> --log`
- If the run log says it is still in progress, fetch job logs directly:
- `gh api "/repos/<owner>/<repo>/actions/jobs/<job_id>/logs" > "<path>"`
4. Scope non-GitHub Actions checks.
- If `detailsUrl` is not a GitHub Actions run, label it as external and only report the URL.
- Do not attempt Buildkite or other providers; keep the workflow lean.
5. Summarize failures for the user.
- Provide the failing check name, run URL (if any), and a concise log snippet.
- Call out missing logs explicitly.
6. Create a plan.
- Use the `create-plan` skill to draft a concise plan and request approval.
7. Implement after approval.
- Apply the approved plan, summarize diffs/tests, and ask about opening a PR.
8. Recheck status.
- After changes, suggest re-running the relevant tests and `gh pr checks` to confirm.
## Bundled Resources
### scripts/inspect_pr_checks.py
Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet. Exits non-zero when failures remain so it can be used in automation.
Usage examples:
- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"`
- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json`
- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40`
מה זה gh-fix-ci ולמה הסקיל הזה שונה?
gh-fix-ci פותר עבודה מתסכלת: בדיקת CI נכשלת, וצריך לצלול ללוגים הארוכים של GitHub Actions כדי להבין למה. החיפוש בלוגים מייגע, וקל לפספס את קטע הכשל האמיתי. הסקיל מאתר את הבדיקות הכושלות, שולף את הלוגים, ומזקק את קטע הכשל, כך שמבינים מהר מה נשבר.
מה שמייחד אותו הוא התהליך המסודר עם אישור. הסקיל לא קופץ לתקן. הוא מאתר את הבדיקות הכושלות עם gh, שולף את הלוגים של GitHub Actions, מסכם את קטע הכשל וכתובת ההרצה, ואז מנסח תוכנית תיקון. רק אחרי אישור מפורש הוא מיישם, ולבסוף ממליץ להריץ מחדש את הבדיקות לאישור. הוא גם ממוקד: ספקים חיצוניים כמו Buildkite מסומנים כמחוץ לתחום ורק כתובתם מדווחת, כך שהתהליך נשאר רזה.
ההבדל מורגש בזמן ובשליטה. במקום לצלול ללוגים לבד ולתקן באופן עיוור, מקבלים סיכום ברור ותוכנית מאושרת. בשילוב עם סקיל systematic-debugging, אפשר לאתר את שורש הכשל בשיטתיות, וזה צירוף חזק לתיקון CI אמין.
מה gh-fix-ci נותן לקלוד קוד?
הסקיל מוסיף לקלוד יכולת לתקן CI: איתור בדיקות כושלות, שליפת לוגים וסיכום הכשל, תוכנית תיקון עם אישור, ובדיקה חוזרת.
איתור וסיכום הכשל
הסקיל משתמש ב-gh כדי לאתר את הבדיקות הכושלות ב-PR, שולף את הלוגים של GitHub Actions, ומזקק את קטע הכשל הרלוונטי. במקום לצלול בלוגים ארוכים, מקבלים סיכום ממוקד של מה נשבר ואיפה, עם כתובת ההרצה לעיון.
תוכנית תיקון עם אישור
לפני שנוגעים בקוד, הסקיל מנסח תוכנית תיקון תמציתית ומבקש אישור מפורש. כך שומרים שליטה: בודקים שהכיוון נכון לפני שמיישמים. הסקיל לא מתקן באופן עיוור, אלא מציע גישה ומחכה לאור ירוק לפני ביצוע.
מיקוד ב-GitHub Actions
הסקיל ממוקד בבדיקות שרצות ב-GitHub Actions, שם הוא יכול לשלוף לוגים ולתקן. ספקים חיצוניים כמו Buildkite מסומנים כמחוץ לתחום, ורק כתובת הפרטים שלהם מדווחת. כך התהליך נשאר רזה ואמין, בלי לנסות לטפל במה שאי אפשר.
יישום ובדיקה חוזרת
אחרי אישור, הסקיל מיישם את התיקון, מסכם את השינויים והבדיקות, ושואל על פתיחת PR. לבסוף הוא ממליץ להריץ מחדש את הבדיקות הרלוונטיות ואת checks כדי לאשר שהכשל נפתר. כך סוגרים את הלולאה ומוודאים ש-CI חזר לירוק.
ארבע היכולות הופכות את קלוד למתקן CI שיטתי. בעבודות שלי, סיכום ממוקד של קטע הכשל ותוכנית מאושרת חסכו צלילה ארוכה בלוגים והחזירו את ה-CI לירוק מהר.
למי הסקיל הזה מתאים?
מפתחים עם CI שנכשל: זה הקהל המובהק. כשבדיקה אדומה חוסמת מיזוג, צריך להבין מהר למה. הסקיל מאתר את הכשל, מזקק את הלוג, ומציע תיקון מאושר, כך שחוזרים לירוק בלי לצלול שעות בלוגים.
צוותים עם זרימת PR: כשכל מיזוג דורש CI ירוק, כשלים מעכבים את כולם. הסקיל מזרז את האבחון והתיקון, כך שה-PR לא נתקע, והצוות ממשיך לזרום.
מי שמתחזק pipeline: כשלי CI חוזרים דורשים הבנה של השורש. בשילוב עם סקיל implement, אפשר ליישם את התיקון בצורה מסודרת אחרי שהתוכנית אושרה.
בוני אוטומציות CI: pipeline אמין הוא הבסיס. גם בעבודות אוטומציה שלי, תיקון מהיר של כשלים שומר על תהליך שרץ חלק, בלי בדיקות אדומות שתוקעות הכל.
מי שלא בקיא ב-GitHub Actions: הלוגים של Actions מאיימים למי שלא רגיל בהם. הסקיל מזקק מהם את העיקר ומסביר את הכשל, כך שגם בלי היכרות עמוקה אפשר להבין מה נשבר ולתקן.
מי שפחות יתאים: מי שה-CI שלו רץ בספק חיצוני כמו Buildkite ימצא שהסקיל מסמן אותו כמחוץ לתחום. הוא מבריק דווקא בבדיקות שרצות ב-GitHub Actions.
איך gh-fix-ci עזר לי בפרויקטים אמיתיים
כשל שזוקק מתוך לוג ארוך
בדיקה נכשלה והלוג היה ענק. במקום לצלול בו, הסקיל איתר את הבדיקה הכושלת, שלף את הלוג, וזיקק את קטע הכשל. הבנתי תוך שניות מה נשבר ואיפה, עם קישור להרצה. החיפוש המייגע בלוגים נחסך לגמרי.
תיקון שעבר דרך אישור
הסקיל לא קפץ לתקן. הוא ניסח תוכנית תיקון תמציתית וביקש אישור. סקרתי את הכיוון, אישרתי, ורק אז הוא יישם. שמרתי שליטה מלאה על מה משתנה, ולא קיבלתי תיקון עיוור שאולי לא היה מטפל בבעיה הנכונה.
חזרה לירוק עם בדיקה חוזרת
אחרי שהסקיל יישם את התיקון, הוא המליץ להריץ מחדש את הבדיקות ואת checks. הרצתי, וה-CI חזר לירוק. במקום לקוות שהתיקון עבד, סגרתי את הלולאה ואישרתי שהכשל נפתר באמת לפני שהמשכתי למיזוג.
בדיקה חיצונית שסומנה נכון
אחת הבדיקות רצה בספק חיצוני, לא ב-GitHub Actions. הסקיל סימן אותה כמחוץ לתחום ורק דיווח את כתובת הפרטים, במקום לנסות לטפל בה. התהליך נשאר רזה וממוקד, והתמקדתי בבדיקות שאפשר היה לתקן באמת.
ארבעת המקרים מראים שתיקון CI מסודר חוסך זמן ושומר שליטה. כשהכשל מזוקק מהלוג, התיקון עובר אישור, ובדיקה חוזרת מאשרת, חוזרים לירוק מהר בלי לצלול שעות בלוגים ובלי לתקן באופן עיוור.
סיכום
סקיל gh-fix-ci הוא כלי מצוין לכל מי שעובד עם CI ב-GitHub Actions. הוא מאתר בדיקות שנכשלות, שולף לוגים ומזקק את קטע הכשל, מנסח תוכנית תיקון לאישור, מיישם, ובודק מחדש שה-CI חזר לירוק.
אם אתם מתחילים, בפעם הבאה שבדיקת CI תיכשל, בקשו מקלוד לאבחן ולתקן עם הסקיל. תראו כמה מהר מזוקק קטע הכשל מתוך הלוג. משם, חזרה לירוק הופכת מהירה ומבוקרת.
בפוסטים הבאים אמשיך לסקור את הסקילים החזקים ביותר לפיתוח ול-DevOps. האתר של דביר נעמן מרכז את כל הכלים, השיטות והליווי שאני מציע לעסקים שרוצים נוכחות דיגיטלית מנצחת עם בינה מלאכותית.
שיתוף הסקיל
שאלות ותשובות
מה זה בעצם הסקיל gh-fix-ci?
זה סקיל לקלוד קוד שמאתר ומתקן בדיקות PR שנכשלות ורצות ב-GitHub Actions. הוא משתמש ב-gh CLI כדי לאתר את הבדיקות הכושלות, שולף את הלוגים, מסכם את קטע הכשל, מנסח תוכנית תיקון, ומיישם אותה רק אחרי אישור מפורש. לבסוף הוא ממליץ להריץ מחדש את הבדיקות כדי לאשר שהכשל נפתר.
איך הסקיל חוסך לי זמן בלוגים?
הלוגים של GitHub Actions ארוכים, וקל לאבד בהם את קטע הכשל האמיתי. הסקיל מאתר את הבדיקות הכושלות, שולף את הלוגים אוטומטית, ומזקק מהם את קטע הכשל הרלוונטי עם כתובת ההרצה. במקום לגלול שורות רבות, מקבלים סיכום ממוקד של מה נשבר ואיפה, תוך שניות.
איך מתקינים את הסקיל בקלוד קוד?
בפקודה אחת דרך מנהל החבילות הרשמי של הסקילים, כפי שמופיע בקופסת ההתקנה למעלה. הסקיל הוא קובץ Markdown פתוח עם סקריפט Python, ודורש את gh CLI מאומת. אחרי ההתקנה בקשו לתקן בדיקת CI שנכשלת, והסקיל יאתר אותה, יסכם את הכשל ויציע תוכנית.
האם הסקיל מתקן אוטומטית בלי לשאול?
לא. הסקיל מנסח תוכנית תיקון תמציתית ומבקש אישור מפורש לפני שהוא מיישם. כך אתם שומרים שליטה מלאה: בודקים שהכיוון נכון לפני שמשהו משתנה. רק אחרי האישור הוא מבצע את התיקון, מסכם את השינויים, ושואל אם לפתוח PR. אין תיקון עיוור בלי הסכמתכם.
מה צריך כדי שהסקיל יעבוד?
צריך את gh CLI מאומת מול המאגר. מתחברים פעם אחת עם gh auth login, בדרך כלל עם הרשאות repo ו-workflow, ומוודאים עם gh auth status. הסקיל עצמו לא מכיל מפתחות או סיסמאות; הוא נשען על ההתחברות הסטנדרטית שלכם ל-GitHub. כך הגישה ללוגים ולבדיקות מאובטחת ובשליטתכם.
האם הסקיל עובד עם כל מערכת CI?
הוא ממוקד ב-GitHub Actions, שם הוא יכול לשלוף לוגים, לזקק כשלים ולתקן. בדיקות שרצות בספקים חיצוניים, כמו Buildkite, מסומנות כמחוץ לתחום, והסקיל רק מדווח את כתובת הפרטים שלהן. המיקוד הזה שומר על התהליך רזה ואמין, במקום לנסות לטפל במערכות שהוא לא יכול לקרוא.
מה קורה אחרי שהתיקון יושם?
הסקיל מסכם את השינויים והבדיקות, שואל אם לפתוח PR, וממליץ להריץ מחדש את הבדיקות הרלוונטיות ואת checks. כך סוגרים את הלולאה ומאשרים שהכשל נפתר באמת לפני המיזוג. במקום לקוות שהתיקון עבד, מקבלים אישור ממשי שה-CI חזר לירוק.
האם הסקיל מתאים גם למי שלא בקיא ב-GitHub Actions?
בהחלט. הלוגים של Actions יכולים להיות מאיימים למי שלא רגיל בהם, והסקיל מזקק מהם את העיקר ומסביר את הכשל בשפה ברורה. כך גם בלי היכרות עמוקה עם Actions אפשר להבין מה נשבר, לקבל תוכנית תיקון, ולחזור לירוק, עם שליטה מלאה דרך שלב האישור.