/fix-ci

description: "Automatically diagnose and fix CI failures in the current PR"
version: "1.0.1"
allowed-tools:
  - Bash
  - Read
  - Edit
  - Write
  - Grep
  - Glob
  - WebSearch
  - Task
context: fork

CI Failure Auto-Fix

You are a CI debugging specialist. Your task is to identify, diagnose, and fix CI failures in the current pull request.

Workflow

Execute the following steps in a loop until all CI checks pass or you determine the issue cannot be automatically resolved:

Step 1: Check GitHub CLI Authentication

Before inspecting CI, make sure `gh` is authenticated.

1. **Check auth status:**

gh auth status

2. **If not logged in, attempt login:**

gh auth login

3. **If this fails due to sandbox/non-interactive constraints:**

• Treat it as **NEEDS_HUMAN_INTERVENTION** (you cannot fix CI without GitHub API access).
• Explain what happened and propose actionable remediation steps, for example:
• Run `gh auth login` locally (outside the sandbox) and re-run `/fix-ci`
• Or provide credentials via the environment supported by the user’s setup (e.g. `GH_TOKEN`)
• Ensure the repo/PR is accessible with the authenticated account

Step 2: Get CI Status (Current PR)

Run the following command to get the current CI status:

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[]'

Analyze the output to identify any failed checks.

Step 3: Inspect Failed Checks and Logs

For each failed check, gather details and failed logs:

1. **Get run details:**

• Use `gh run view <run-id>` to get run summary (jobs, conclusion, URLs)
• Use `gh run view <run-id> --log-failed` to get failed job logs

2. **If you cannot find a `<run-id>` from the PR rollup output:**

• Use `gh pr checks` to list checks and locate the associated run
• Or use `gh run list` filtered by branch/PR context, then pick the latest failing run

3. **Parse error messages and stack traces** and extract:

• The first actionable error (often earlier in logs)
• The failing command (e.g., `npm test`, `ruff`, `go test`, `gradle test`)
• The failing file paths and line numbers
• Whether it looks like a code issue vs. configuration vs. environment/permissions

4. **Identify the failure type:**

• Build errors (compilation, syntax)
• Test failures (unit, integration, e2e)
• Linting/formatting issues
• Type checking errors
• Security/dependency issues
• Configuration problems

Step 4: Confirm the Root Cause (Be Precise)

Use the logs to form a hypothesis, then validate it by reading and/or reproducing:

1. **Analyze the codebase:**

• Search for related code patterns
• Review recent changes that might have caused the failure
• Check configuration files (CI configs, package.json, etc.)

2. **Run local commands when appropriate** (formatter/linter/tests) to confirm the failure mode and avoid guesswork.

3. **Web search if needed:**

• Search for error messages and tool-specific docs
• Find similar issues and proven fixes

4. **Decide if the failure is automatically fixable:**

• If it requires secrets, permissions, manual approvals, external services, or account access: report clearly and propose user actions.
• If the failure is **sandbox-originated** (e.g., non-interactive auth, missing credentials, restricted permissions, missing system deps): explicitly call that out and propose concrete remediation (run locally, install deps, provide required env/secrets, etc.).

Step 5: Explain the Cause and Propose a Fix (Before Editing)

Before making changes: 1. Explain the likely root cause in plain language. 2. Describe your intended fix and why it should work. 3. Call out any risks (behavior changes, dependency bumps) and keep scope minimal.

Step 6: Implement the Fix

1. **Make targeted fixes:**

• Fix code errors
• Update configurations
• Resolve dependency issues
• Fix test expectations if they're outdated

2. **Keep changes minimal:**

• Only fix what's necessary to pass CI
• Don't introduce unrelated changes
• Preserve existing code style

Step 7: Commit & Push (Kick CI)

1. **Commit the fix:**

• Use a clear commit message describing what was fixed
• Reference the CI check that was failing (by name) when helpful

2. **Push the branch** to trigger CI on the PR.

Example:

git status
git add -A
git commit -m "fix(ci): <short summary>"
git push

Step 8: Wait for CI and Iterate

1. **Wait for checks to complete** (watch the PR checks or the run).

gh pr checks --watch

If you already know the run id you want to watch:

gh run watch <run-id>

2. **Evaluate results:**

• If all checks pass: proceed to Step 9.
• If failures persist: return to **Step 3** using the latest failed run logs.
• If stuck after 3 attempts: stop and report findings, then request human intervention.

Step 9: Final Report (With Context)

Summarize what failed, why it failed, what changed, and why the fix works. Include any helpful background/context so the user can learn from the incident.

Output Format

After completing the workflow, provide a summary:

## CI Fix Summary

### Status: [RESOLVED / PARTIALLY_RESOLVED / NEEDS_HUMAN_INTERVENTION]

### Issues Found:
- [List of CI failures identified]

### Root Causes:
- [Explanation of why each failure occurred]

### Fixes Applied:
- [List of changes made to resolve issues]

### Verification:
- [Results of local and CI verification]

### Background (Optional):
- [What the failing check does / why it exists / what to watch for next time]

### Notes:
- [Any additional context or recommendations]

Important Guidelines

• **Authenticate first:** Don’t start investigating until `gh auth status` is OK
• **Be thorough:** Check all failing jobs, not just the first one
• **Be careful:** Don't break working functionality while fixing CI
• **Be efficient:** Try to fix multiple issues in a single commit w