What I do
- Standardize the CI recovery loop: inspect failed run -> fix -> verify -> commit/push -> watch rerun.
- Prefer
ghCLI for run discovery/log extraction and PTY-based watch for long-running status streams. - Keep fixes minimal and tied to concrete failing commands from logs.
- For long-running watch mode, prefer the
@babysitteragent (for example via/gha_babysit). - Keep git submission predictable by routing commit/push steps through the
gitter-commitskill and@gitteragent.
When to use me
Use this when:
- The user asks to "fix CI" or "make GitHub Actions green".
- A push run failed and we need iterative repair.
- We need a predictable handoff/checklist for repeated GHA triage.
Workflow
- List recent runs
gh run list --branch <branch> --limit 10
- Inspect failure details
gh run view <run-id> --log-failed
- Patch root cause
- Fix only what is required by the failing logs.
- Verify locally
- Run targeted local checks relevant to the failure path.
- Commit + push
- Use the
gitter-commitskill and@gitteragent for staging/commit/push steps. - Prefer submitting only CI-related work touched in this loop; accidental WIP in a push is acceptable, but avoidable in most cases.
- Use a focused commit message describing the failure class and fix intent.
- Use the
- Watch rerun with PTY
gh run watch <new-run-id>in PTY to avoid timeout and keep live output.
- Repeat until green
- Iterate log -> fix -> push -> watch until all required jobs pass.
Guardrails
- Do not guess root cause without failed logs.
- Avoid broad refactors while recovering CI unless explicitly requested.
- If repeated failures point to secrets, permissions, or external outage, escalate with a clear blocker note.
- If code changes are required during a watch flow, route implementation to
@.opencode/agents/developer_jr.mdor@.opencode/agents/developer_senior.md. - Do not do ad-hoc git submission from babysit flow when
gitter-commit/@gittercan be used.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.