git:20261013.6631e06 to git:20261014.0f16275

- Watch the latest GitHub Actions run for the current ref incrementally. As individual jobs fail, surface them so the agent can fix the underlying issues and **push each fix immediately with `[no ci]`**. When the run reaches a terminal state, if any mid-run fixes landed push one final empty commit (no `[no ci]`) to retrigger with everything baked in.

- **Which runs there are to watch.** Every workflow is triggered by a push or a dispatch, so if the project's CI doesn't run on feature-branch pushes, this skill has no subject until something is dispatched. Typically:

- - a **push-triggered run** on the branch, where the project's CI is configured that way;

- - an **on-demand dispatch** — but `/test-on-gh` (if hydrated) already blocks for its result, so reach for this mainly to re-attach to a dispatch you left running (e.g. a fresh session picking up a branch);

- - a **scheduled/nightly run** — usually watched from the trunk, and a red one is a tracking issue rather than a branch to fix;

- If there is no run for the current ref, say so and stop — don't push an empty commit hoping to conjure one.

- This skill acts **autonomously mid-run**: no user-confirmation gate before applying fixes, and it pushes those fixes itself.

- (`[no ci]` here is GitHub's own commit-message skip marker, unrelated to `/finalize`'s `no vet` flag despite `no ci` being one of that flag's accepted spellings.)

- A workflow with `concurrency: cancel-in-progress: true` cancels its in-flight run when you push to the same ref. A commit whose message contains `[no ci]` does not schedule a new workflow run, so the concurrency cancellation never fires. (On a ref where a push schedules nothing anyway, the marker simply has nothing left to suppress.)

- - The operator usually watches the branch from a different machine than the agent's VM — pushing makes the work visible in real time.

- - The diff is the record of what the agent did; "in working tree only" leaves no trace.

- Repeatedly call `scripts/ci-watch-tick.sh` as a synchronous `Bash` with a generous timeout (e.g. 120000ms). The script handles its own sleep via the `MUTHUR_INTERVAL` env var (default 60s) and tracks "time since last tick" in `.git/ci-watch-state.json` — so if you spent 3 minutes fixing the previous batch, the next tick skips its sleep and snapshots immediately.

- - `0` — the tick succeeded. Inspect the final printed line (`overall=<status>/<conclusion>`) to disambiguate:

- - `overall=in_progress/-` (or any non-`completed` status) — run still in progress, no new failures this tick.

- - `10` — run still in progress, but one or more jobs failed terminally since the previous tick. The script prints logs for each newly-failed job (deduped across ticks via the state file).

- - For each newly-failed job, locate the source files referenced by the failure, propose a concrete fix, and **apply it directly** to the working tree. Do not ask the user — mid-run autonomy is the point of this skill.

- - **Commit and push the fix with `[no ci]` in the commit subject.** One commit per logical fix is fine; batching multiple fixes from a single tick into one commit is also fine. Example: `git commit -m "fix: address flaky timeout on the upload path [no ci]"` then `git push`. Do NOT run `./scripts/vet.sh` between ticks — that's deferred to the terminal step.

- The tick prints the last 200 lines of each failed job's log inline and tees the complete log under `.git/ci-watch-logs/` — read the full file when the excerpt cuts off the actual error.

- - No mid-run fixes were pushed → report green and resume the enclosing context (current task, etc.).

- - Mid-run fixes WERE pushed but the run still passed (rare) → report green, list the accumulated fix commits, surface them to the user. They're already on the remote; no further action needed.

- After reporting green (both sub-cases): **end the turn** so the session reads as idle, not pinned as "working" — don't start a background process. Tell the operator they can run **`/check-merge`** when they return to see whether the branch's merge target moved out from under it or the PR landed. (`/check-merge` is stateless, so it's ready to run any time — there's nothing to record here first.)

- - **Fixes pushed AND no unaddressed failures** → run `./scripts/vet.sh` to verify the accumulated branch is clean. If green, re-dispatch (`/test-on-gh` with the same selectors, if hydrated) or, on a lane where a push does schedule a run, push a single empty commit to schedule a fresh run with all the fixes baked in — e.g. `git commit --allow-empty -m "ci: retrigger with accumulated fixes from run <url>"`. **The retrigger commit message must NOT contain the literal skip marker (the `[no ci]` / `[skip ci]` characters) anywhere — not even in prose like "after [no ci] fixes".** GitHub scans the whole message and will skip the run, so the retrigger silently does nothing (symptom: `ci-watch-tick` reports "No CI run found for HEAD …"). Refer to it as "the skip marker" or "skip-marked commits" instead of writing the characters. Skill ends. Does NOT auto-re-invoke (risks an infinite loop on persistent infra failures); the user can chain `/watch-ci` again if they want.

- - **Fixes pushed BUT unaddressed failures remain** → run `./scripts/vet.sh` to verify the partial fixes. Surface the unaddressed failures with proposed fixes or questions for each. The user decides whether to push the retrigger empty commit + address the rest manually, or hand off elsewhere. Skill ends without retriggering.

- - **No mid-run fixes ever applied** (run failed non-actionably — flake, infra, an environment issue the agent couldn't act on) → report the failure, name what made it non-actionable, and stop. Don't push a retrigger hoping a flake clears; say plainly that the run failed for a reason this skill can't fix and let the operator decide.