Diagnoses and fixes failed CI checks on pull requests.
Install
mkdir -p .claude/skills/fix-ci-nickolashkraus && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12798" && unzip -o skill.zip -d .claude/skills/fix-ci-nickolashkraus && rm skill.zipInstalls to .claude/skills/fix-ci-nickolashkraus
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Fixes CI failures on a pull request by fetching check results, diagnosing the issues, and applying fixes.Key capabilities
- →Determine the pull request number
- →Wait for all CI checks to complete
- →Assess the results of CI checks
- →Fetch failure details from CI logs
- →Apply fixes for failed CI checks
- →Assess and address review bot comments
How it works
This skill systematically identifies and resolves CI failures and bot comments on a pull request by checking status, analyzing logs, and applying fixes.
Inputs & outputs
When to use fix-ci
- →Fix broken CI
- →Debug pull request failures
About this skill
You are fixing CI failures on a pull request. Follow every step in order.
Step 1: Determine the pull request
Parse the user-provided skill input for flags and an optional PR number:
--in-place: Fix bot comments directly on this branch (no stacked PR).--re-review [all | unresolved]: Re-review bot comments.all(default) re-reviews every comment regardless of resolution or reply status.unresolvedre-reviews only comments that have not been resolved via the GitHub UI, ignoring reply status.
Remove both flags before continuing.
If a PR number was passed, use it. Otherwise, detect the current branch and find its open PR:
gh pr view --json number,headRefName --jq '.number'
If no PR is found, stop and tell the user.
Step 2: Wait for all checks to complete
List all checks on the PR:
gh pr checks <pr-number>
Classify every check as pass, fail, or pending.
- If any checks are pending, wait 30 seconds and re-check. Always wait for all checks to complete before moving on, even external checks (e.g., Cloud Build, Sentry, third-party scanners).
- Don't fake the handoff. If you start a background wait (
Monitor,ScheduleWakeup, a recurring Codex run, or anyrun_in_backgroundtask), you must register a concrete resumption (cron, scheduled wakeup, or loop tick) in the same turn. Don't end the turn relying on the user to re-prompt. "I'll let the monitor continue running" or "waiting for monitor to notify me" are not valid handoffs unless paired with a registered resumption. - Once all checks have completed, continue to Step 3.
Step 3: Assess results
- If any checks have failed, continue to Step 4.
- If all checks pass, skip to Step 5 to assess bot comments.
IMPORTANT: Never create an empty commit to "Retry CI". Instead, read the logs to diagnose the failure and, if the failure is transient or infrastructure-related, re-run the specific check:
- GitHub Actions:
gh run rerun <run-id> --failed. - External check (e.g., Google Cloud Build):
gh run rerundoes not apply. First try GitHub's check-run rerequest:gh api -X POST repos/{owner}/{repo}/check-runs/<check-run-id>/rerequest. If that returns 404 (the app does not support rerequest), fall back to the provider's native retry. For Cloud Build:curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" https://cloudbuild.googleapis.com/v1/projects/<project>/builds/<build-id>:retry(gcloud builds triggers rundoes not work for GitHub PR triggers).
IMPORTANT: Every check must pass, including non-required ones. A non-blocking failure is still a failure and must be cleared, not documented around.
IMPORTANT: Never close and reopen a PR to retrigger CI. It rewrites timestamps, fires PR-lifecycle webhooks with side effects, and leaves the original failed check as a stuck record (a new run is created under a different name, so it does not replace the old one). If the retry paths above fail, diagnose and fix the root cause. Do not force-push or push empty commits as workarounds.
Step 4: Get failure details and fix
For each failed check, fetch its logs:
gh run view <run-id> --log-failed
If the log is too large, fetch logs for the specific failed job:
gh run view <run-id> --log-failed --job <job-id>
Read the logs carefully. Identify the root cause of each failure (e.g., lint error, type error, test failure, formatting issue).
For each failure:
- Read the relevant source files to understand context.
- Apply the fix directly. Do not just describe what needs to change.
- If the fix requires running a command (e.g.,
npm run format,ruff .), run it.
Step 5: Assess review bot comments
Collect bot comments from both sources:
-
PR review comments (inline comments on diffs):
gh api repos/{owner}/{repo}/pulls/<pr-number>/comments --paginate -
Review-level comments (comments attached to reviews): List all reviews, filter for bot authors, then fetch each review's comments:
gh api repos/{owner}/{repo}/pulls/<pr-number>/reviews --paginate \ --jq '.[] | select( .user.login == "sentry[bot]" or .user.login == "cursor[bot]" or .user.login == "copilot[bot]" or .user.type == "Bot" ) | .id'Then for each review ID:
gh api repos/{owner}/{repo}/pulls/<pr-number>/reviews/<review-id>/comments
Filter for comments left by review bots (Copilot, Cursor Bugbot, Sentry, or similar).
Filter comments by resolution status
How comments are filtered depends on the --re-review flag:
- No flag (default): Skip comments that are resolved or that
nickolashkraushas already replied to. Check the comment's reply thread for any comment where.user.login == "nickolashkraus". --re-review all: Act on all bot comments regardless of resolution or reply status.--re-review unresolved: Skip resolved comments, but ignore reply status. This is for the workflow where you review findings in the GitHub UI, resolve the ones you want to skip, then re-run to fix the rest.
If no actionable bot comments remain and all checks pass, go to Step 7.
If --in-place was NOT set
If there are actionable bot comments and --in-place was not passed, delegate
to $fix-bot-reviews <pr-number> (pass through --re-review <value> if it was
set). This creates a stacked fix PR for the bot comment fixes. Skip to Step
7 after $fix-bot-reviews completes.
If --in-place was set
For each remaining unresolved comment, assess whether it is legitimate and fix in-place on the current branch.
Bias toward fixing. If the suggestion is plausible, fix it. Only dismiss a comment if it is clearly wrong:
- The bot misread the code or misunderstood the logic.
- The suggestion would break existing behavior.
- The suggestion contradicts project conventions.
- The suggestion contradicts the product or feature specification.
For each comment:
-
Legitimate issue (default): Read the relevant source files to understand context, then apply the fix directly.
-
Clearly illegitimate: Reply with a brief explanation of why the suggestion does not apply:
gh api repos/{owner}/{repo}/pulls/<pr-number>/comments \ -f body='<reply>' -F in_reply_to=<comment-id>
Evidence in replies
When replying to a bot comment (whether fixing or dismissing), include an Evidence section if there is existing source documentation (e.g., Stripe docs, API specs, framework guides) that substantiates the decision. Use the format:
**Evidence**:
- Brief factual statement.
- [Page title (Source)](https://...)
Do not fabricate an evidence section when no external documentation is relevant.
Step 6: Verify, commit, and push
Run the same CI commands locally to confirm the fixes work. Use the project's
test/lint/build commands as identified from the CI logs or project
configuration (e.g., Makefile, package.json, pyproject.toml).
If any command still fails, go back to Step 4. Do not push between fix iterations.
Once all local verification passes (CI fixes and bot comment fixes), commit and push in a single push. Always create a new commit rather than amending and force-pushing, so that review history and prior CI runs are preserved. Then go back to Step 2 and wait for all checks to complete before taking further action. Keep iterating until every check passes and all bot comments are addressed.
Follow the commit rules from ~/.codex/rules/git.md:
- Subject line: 50 characters or less, capitalized, imperative mood, no period.
- Body: Explain what bot comments were addressed and why.
- No co-authored-by or signature lines.
Step 7: Summarize
List each CI failure and review bot comment, and what you did to fix or resolve each one.
If any bot comments were addressed (fixed or dismissed), post a summary comment
on the PR using tables. Number findings sequentially (F-01, F-02, ... for
fixed; D-01, D-02, ... for dismissed). Use each bot comment's html_url for
the link column. The Fix column should contain:
- A linked commit SHA (e.g.,
abc1234) if the fix was applied in-place. - A link to the fix PR if the fix was delegated to
$fix-bot-reviews.
gh pr comment <pr-number> --body "$(cat <<'EOF'
## Bot Review Findings
### Fixed
| # | Comment | Description | Fix |
| ---- | ------------------ | ------------- | ----------------------- |
| F-01 | [→](<comment-url>) | <description> | [`<sha>`](<commit-url>) |
| F-02 | [→](<comment-url>) | <description> | [`<sha>`](<commit-url>) |
### Dismissed
| # | Comment | Description | Reason |
| ---- | ------------------ | ------------- | -------- |
| D-01 | [→](<comment-url>) | <description> | <reason> |
| D-02 | [→](<comment-url>) | <description> | <reason> |
EOF
)"
Omit a section if it has no entries. If there are zero findings (nothing fixed or dismissed), post:
gh pr comment <pr-number> --body '## Bot Review Findings
✅ No actionable findings.'
This summary is in addition to the individual replies already posted on each bot comment thread.
~/.codex/rules/meta-learning.md
When not to use it
- →When creating an empty commit to retry CI
- →When closing and reopening a PR to retrigger CI
- →When force-pushing or pushing empty commits as workarounds
Limitations
- →Does not support creating empty commits to retry CI
- →Does not support closing and reopening a PR to retrigger CI
- →Does not support force-pushing or pushing empty commits as workarounds
How it compares
This workflow provides a structured, iterative process for fixing CI and bot comments, ensuring all checks pass and comments are addressed before completion, unlike manual, ad-hoc troubleshooting.
Compared to similar skills
fix-ci side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| fix-ci (this skill) | 0 | 3mo | Review | Advanced |
| dependency-auditor | 1 | 9mo | Review | Beginner |
| tech-debt | 1 | 2mo | Review | Beginner |
| code-audit | 0 | 1mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by nickolashkraus
View all by nickolashkraus →You might also like
dependency-auditor
alirezarezvani
Check dependencies for known vulnerabilities using npm audit, pip-audit, etc. Use when package.json or requirements.txt changes, or before deployments. Alerts on vulnerable dependencies. Triggers on dependency file changes, deployment prep, security mentions.
tech-debt
vm0-ai
Technical debt management - scan codebase for bad smells and create tracking issues
code-audit
mei28
Automated code review tool that analyzes code quality, detects bugs, identifies security vulnerabilities, and suggests improvements based on industry best practices
dependency-analyzer
InugamiDev
Dependency tree analysis, version conflict resolution, update planning, and bundle size optimization
verifier
oleyna80
Pre-merge quality gate. Use to verify code is ready to ship: route contracts (status, Content-Type, body), TypeScript, tests, CSP/CSRF headers, schema alignment, secret leak scan. Issues structured READY or BLOCKED verdict with file:line evidence. Read-only. Для верификации, проверки перед мержем, и
fix-security-vulnerability
getsentry
Analyze and propose fixes for Dependabot security alerts