ci-fix-monitor

name	ci-fix-monitor
audience	swarm-plugin
description	Monitor CI on a PR, diagnose failures, fix them, and re-push until green. Covers reading CI logs, classifying failure types (check-title, package-check, test failures, lint), determining the correct fix, and re-pushing.

CI Fix & Monitor Protocol

Activates when the user asks to monitor CI, fix CI failures, or resolve red checks on a PR.

Environment note — tool availability

This skill was originally written for desktop Claude Code (Windows) with gh CLI. In the remote execution / GitHub MCP environment, use the equivalent MCP tools instead:

| Capability needed | gh CLI | Example remote-MCP shape (resolve the real names via ToolSearch) | |---|---| | gh pr checks <number> | mcp__github__pull_request_read method get_check_runs | | gh pr view <number> --json checks | mcp__github__pull_request_read method get_check_runs | | gh run view <run-id> --job <job-id> --log | mcp__github__get_job_logs with job_id and return_content: true | | gh pr edit --title | mcp__github__update_pull_request with title | | gh pr view --json mergeable | mcp__github__pull_request_read method get |

MCP tool names are injected by the runtime harness and are NOT stable across environments. Treat the right-hand column as an example SHAPE only: resolve the actual tools by CAPABILITY (PR read with check-run support, job-log read, PR update) via ToolSearch before first use in a session — never assume a specific mcp__github__* name exists (issue #2131 finding 9).

Step 1 — Fetch current status

Fetch all check runs for the PR head commit. If all green: report success and stop.

Step 2 — Classify each failure

Failure type	Root cause pattern	Fix action
check-title	PR title lacks <type>(<scope>): prefix	Update title via PR edit
package-check	npm tarball validation failed (source/build/package-manifest problem)	Fix source/build/manifest — see section below. Not generated-file drift.
branch behind main	Branch is behind main; main had a release commit; CI uses merge-commit checkout	Rebase onto main, force-push — see section below
lint/quality: format	Code style violations (long lines, spacing)	bunx biome format --write <files> then commit
lint/quality: lint	Lint rule violations (noExplicitAny, etc.)	bunx biome check --write <files> or fix manually
unit test	Test failures	Read log, fix code, commit
integration	Integration failures	Read log, check if pre-existing on main
macOS unit test	Cross-platform file I/O race (atomic write-then-read returns null on macOS)	See "macOS file I/O fixes" below
security	SAST/secret findings	Read log, fix or suppress with justification
smoke	Smoke test failures	Read log, check if environment-specific

macOS file I/O fixes (cross-platform atomic write)

macOS/APFS has different filesystem timing than Linux ext4. fs.renameSync can complete before the data is visible to subsequent reads. The most common manifestation is unit (macos-latest) failing on tests that write-then-read atomic files (e.g., curator atomic write > writeCuratorSummary > after write, readCuratorSummary reads file back successfully), while the same tests pass on ubuntu-latest and windows-latest.

Canonical patterns: See file:.opencode/skills/writing-tests/SKILL.md § Cross-Platform Requirements → "macOS rename-visibility race" for the full three-layer fix pattern (bunWrite + ENOENT retry + Node FileHandle.sync() not fsync()). This skill is a triage pointer; the canonical technical reference lives in writing-tests so it survives any regeneration of this generated/ file.

Related security test pattern: if the CI failure involves a long task ID or path, the security test ADVERSARIAL: Command Services Attack Vectors > Attack Vector 1: Malformed Arguments > EVIDENCE: extremely long task ID (buffer overflow) - ACCEPTED by regex but no crash requires a path length guard BEFORE validateSwarmPath in src/evidence/manager.ts:loadEvidence. See file:.opencode/skills/engineering-conventions/SKILL.md for the evidence file flow that this gate check triggers on macOS CI.

Step 3 — Diagnose with logs

For every failed check, fetch the full log content. Fetch only the tail (last 80–100 lines) unless the error is near the start.

Read the log carefully before concluding root cause. Distinguish between:

• a failure introduced by this PR,
• a pre-existing failure on main (verify by checking main's last CI run for the same check), and
• a failure caused by the CI environment or branch drift.

Step 4 — Fix

check-title

No commit needed. Update the PR title.

package-check failure

package-check validates the npm tarball (npm pack + tarball contents). A failure is a source/build/package-manifest problem, not generated-file drift. dist/ is generated and NOT committed — do not stage it. Run bun run build locally only when you need the bundle to verify the failure:

bun run build
node --input-type=module -e "await import('./dist/index.js'); console.log('dist import OK')"

Fix the underlying source/build/package.json files manifest issue, then commit the source fix (not dist/) and push.

branch behind main (version drift)

Identifying this case: A version string differs (version: "X.Y.Z" changed to a higher version) because main had a release commit after the branch was cut, and GitHub Actions checks out the merge-commit for CI. Rebase onto main to pick up the release commit.

Fix:

git fetch origin main
git rebase origin/main       # fast-forward the branch onto the release commit
# If the rebase halts with conflicts, run `git rebase --abort` and escalate
# to the user — do not attempt to resolve a conflicted rebase automatically.
git push --force-with-lease origin <branch>   # force-push is required after rebase

--force-with-lease is safe here: it refuses to overwrite commits that appeared on the remote after your last fetch. After the rebase, the local branch has diverged from remote history — a regular push will be rejected.

• Do NOT stage or commit dist/ — it is generated and NOT committed; there is no committed-dist drift check
• After a rebase, a force-push is required and expected — do not try a regular push

lint/quality: format violations

Biome format violations (line too long, spacing, bracket style) — these can appear when a code change introduces a line that exceeds Biome's print-width. Auto-fix only the changed files to minimize noise:

bunx biome format --write src/path/to/changed-file.ts
bun test src/path/to/changed-file.test.ts   # verify tests still pass after format
git add <files>
git commit -m "style: apply Biome formatting"
git push origin <branch>

Do NOT run bunx biome format --write . on the entire repo unless instructed — this can introduce formatting changes in unrelated files and bloat the diff.

lint/quality: lint rule violations

bunx biome check --write <specific-file>
# or fix manually if --write does not handle the rule

integration failures

Check whether the same check failed on main's last CI run before treating it as PR-introduced. If pre-existing: document the finding and skip. If introduced by this PR: collect the full failure log, the test name, and the first error line, then delegate to a coder with that evidence.

security (SAST/secret findings)

Fetch the full log. If it is a secret/credential finding: confirm the file and line, remove or rotate the credential, and commit the fix. If it is a SAST code-quality finding: collect the rule ID, file, and line, then delegate to a coder. Do NOT suppress findings without an explicit justification comment approved by the user.

unit test / smoke failures

Delegate to coder with specific failure details (test name, assertion, first error line). See execute skill.

Step 5 — Push and monitor

After pushing, subscribe to PR activity (if in webhook/MCP context) and wait for the next CI event rather than polling. Do not push a second time until the CI result from the first push is confirmed.

If no CI event arrives after a reasonable wait (e.g., checks are still queued and stalled), re-fetch check status manually via get_check_runs and report the stall state to the user rather than waiting indefinitely.

Step 6 — Verify all green

Do NOT declare victory until ALL required checks pass. A check in skipped state is acceptable only if the same check was skipped on the base branch (i.e. the workflow gates on a path filter). Confirm this explicitly.

Standalone retry bound

When this skill is invoked directly (not composed via swarm-ci-monitor's own 5-iteration counter), cap fix-push cycles at 5 iterations. If the PR is still not green after 5 fix-push cycles, stop and escalate to the user with the last failing check and a short log excerpt rather than looping indefinitely.