fix-and-retry

name	fix-and-retry
description	Diagnose a failing CI run, apply the code fix, commit it, push, and watch the re-run until it passes or fails -- the full fix-and-retry loop in one shot. Use after a pipeline fails and the user says "fix it and retry", "fix the CI and push", or "make CI green". Do NOT use for a read-only investigation that stops at a recommendation (use diagnose-ci); do NOT use for a routine commit unrelated to a CI failure (use ship).
allowed-tools	Bash(git *), Bash(gh *), Read, Grep, Glob, Edit
user-invocable	true

Fix and Retry

Diagnose CI failure, fix it, and re-ship.

Steps

1. Diagnose: Follow the diagnose-ci workflow:

   • gh run list --status=failure --limit 1 --json databaseId,name,headBranch to find the latest failure
   • gh run view <id> --log-failed to get error logs
   • Identify root cause and affected files

2. Fix: Apply the fix to the codebase. Read the affected file(s), make the edit, and verify the fix makes sense.

3. Commit: Create a conventional commit for the fix (e.g., fix(ci): correct workflow syntax). Use a HEREDOC for the message.

4. Push: Before pushing, capture the pre-push run id (gh run list --branch $(git branch --show-current) --limit 1 --json databaseId -q '.[0].databaseId'). Then git push.

5. Watch: Poll for a NEWER run, not the previous failed one. Match the new run by the pushed commit's headSha (git rev-parse HEAD) -- e.g. gh run list --branch $(git branch --show-current) --limit 5 --json databaseId,headSha,status,conclusion and pick the run whose headSha equals the new HEAD (and whose id differs from the captured pre-push id). Poll every 15s (max 5 minutes) until that run completes. This prevents the watcher from latching onto the previous failed run before the new run is registered.

6. Report: Show whether the re-run passed or failed. If it failed again, show the new error.

Rules

• Only fix issues you can confidently diagnose from the logs. If the cause is unclear, report the diagnosis and ask the user rather than guessing.
• Never force push or amend the previous commit.
• If the fix requires secrets, env vars, or manual GitHub settings changes, explain what's needed instead of attempting it.

Gotchas

• A new CI run is not registered the instant you push. Capture the pre-push run id (step 4) and poll for a run whose headSha matches the newly pushed HEAD before reading status. If you watch --limit 1 blindly, the watcher can latch onto the previous failed run and report a false failure.