- Home
- Skills
- Shipshitdev
- Library
- Gh Fix Ci
gh-fix-ci_skill
- Python
5
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill shipshitdev/library --skill gh-fix-ci- plugin.json333 B
- SKILL.md1.1 KB
Overview
This skill diagnoses failing GitHub Actions checks on a pull request, pulls relevant logs, summarizes the failure context, and prepares a proposed fix plan. After you approve the plan, it can implement code changes and open a follow-up commit or PR. External CI (non-GitHub Actions) is reported as out of scope with a details URL.
How this skill works
It verifies GH CLI authentication, locates the PR, and lists associated checks using gh commands. For GitHub Actions failures it fetches run or job logs, extracts root-cause details and impacted files, then drafts a concise fix plan. It asks for user approval before making any code edits and will report external CI checks as out of scope with their details URL.
When to use it
- A PR’s GitHub Actions checks are failing and you want a diagnosis and fix plan.
- You need a concise summary of failing job logs and impacted files.
- You want automated edits after reviewing and approving a repair plan.
- You prefer the tool to fetch GH Actions logs rather than manually searching runs.
- You need clear distinction between GitHub Actions and external CI failures.
Best practices
- Ensure gh is authenticated (gh auth status -h github.com) before starting.
- Provide the PR URL if the skill cannot auto-detect the target PR.
- Do not request rerunning CI unless you explicitly want it re-run.
- Keep tests and changes isolated to a minimal set of files to simplify review.
- Review the proposed plan carefully before approving automated code changes.
Example use cases
- Unit tests failing on a feature branch — fetch logs, identify failing tests, propose code or test fixes.
- Build or compilation errors — locate failing step, summarize missing deps or config, propose edits to build scripts or Dockerfiles.
- Lint or formatting failures — extract linter output and create fixes or formatting commits.
- Intermittent or flaky tests — gather logs from multiple runs and propose stability or timeout adjustments.
- Dependency upgrade causing breakage — identify stacktrace, propose version pin or code adjustments.
FAQ
Yes — but only after you explicitly approve the proposed fix plan. Changes are committed or opened as a PR per your instruction.
Will it rerun CI or re-trigger workflows?
No — it will not rerun CI by default. It reports logs and makes code changes; rerunning workflows requires an explicit request from you.