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.