/running-tend

name: running-tend
description: Worktrunk-specific guidance for tend CI workflows. Adds codecov polling, Rust test commands, labels, and review criteria on top of the generic tend-* skills. Use when operating in CI.
metadata:
  internal: true

Worktrunk Tend CI

Project-specific guidance for tend workflows running on worktrunk (a Rust CLI for managing git worktrees). The generic skills (`tend-running-in-ci`, `tend-review`, `tend-triage`, etc.) provide the workflow framework; this skill adds worktrunk conventions.

Filing issues in other repos

Standing exception granted: file directly in agent-equipped targets (per **Filing Issues in Other Repos** in the bundled `running-in-ci` skill) without asking permission here first. The default rule (open an issue here asking permission first) still applies when the target shows no agent signals.

Codecov Monitoring

After required CI checks pass, poll `codecov/patch` — it is mandatory despite being marked non-required:

for i in $(seq 1 5); do
  CODECOV=$(gh pr checks <number> 2>&1 | grep 'codecov/patch' || true)
  if echo "$CODECOV" | grep -q 'pass'; then
    echo "codecov/patch passed"; exit 0
  elif echo "$CODECOV" | grep -q 'fail'; then
    echo "codecov/patch FAILED"; exit 1
  fi
  sleep 60
done

If codecov fails **locally**, investigate with `task coverage` and `cargo llvm-cov report --show-missing-lines | grep <file>`.

Investigating codecov failures in CI

`task` and `cargo-llvm-cov` are not installed in the `claude-setup` action. Don't try to `cargo install` them in the sandbox — past attempts at source-compiling installs cascaded into bash-tool interrupts that blocked even `pwd` and `echo`. (Pre-built single-script installers like Determinate Nix's are fine — see **Weekly Maintenance: MSRV & Toolchain** for the one we use. The block is specifically about long-running cargo compiles.) Instead, query Codecov directly, following `tests/CLAUDE.md` → **Coverage Investigation** for the endpoints and their traps.

If the Codecov API markers aren't enough, download the `code-coverage-report` artifact from the PR head's `coverage` workflow run — it contains a `cobertura.xml` with per-line hit counts:

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
# Find the coverage run on the PR head SHA:
CI_RUN=$(gh api "repos/$REPO/commits/<sha>/check-runs" --jq '.check_runs[] | select(.name == "code-coverage") | .details_url | capture("runs/(?<id>[0-9]+)") | .id')
# List artifacts, then download the coverage one:
gh api "repos/$REPO/actions/runs/$CI_RUN/artifacts" --jq '.artifacts[] | {name, id}'
gh api "repos/$REPO/actions/artifacts/<id>/zip" > /tmp/coverage.zip
unzip -q /tmp/coverage.zip -d /tmp/coverage

Test Commands

cargo run -- hook pre-merge --yes   # full suite + lints
cargo test --lib --bins             # unit tests only
cargo test --test integration       # integration tests only

CI runs on Linux, Windows, and macOS.

Session Log Paths

Artifact paths: `-home-runner-work-worktrunk-worktrunk/<session-id>.jsonl`

Labels

• `automated-fix` — fix PRs from triage and ci-fix workflows
• `nightly-cleanup` — nightly sweep issues and PRs

CI Fix: Prefer Rerun for Transient Infrastructure Failures

Before opening a `fix/ci-*` PR, classify the failure:

• **Transient infrastructure** (link-check timeouts, apt-get flakes, GitHub

outages, runner disk issues, codecov upload blips) — do **not** create a PR. The maintainer will rerun CI. Comment on the run or exit silently; a permanent config change for a one-off timeout is churn the maintainer will close.

• **Flaky test** (known-flaky or first-seen PTY/shell test) — try to fix it.
• **Real regression** — proceed with a fix PR.

**Non-required ≠ transient.** A non-required job (e.g. `collect affected coverage`, `affected tests (linux, advisory)`) can fail from a real regression. The required/non-required distinction is about merge-blocking, not about how the failure is classified. If a deterministic build error (`error[E...]`, "binary not found", "ambiguous candidates", missing target) repeats across consecutive runs of the same shape, it's a real regression even when the job is advisory. Reserve "transient" for non-deterministic causes: `BrokenPipe`, `connection reset`, runner disk full, GitHub API timeouts, host-availability blips.

**Lychee link-check timeouts are always transient** unless the same URL has failed on at least two separate runs within the last few days. The check runs as the `link-check` job in the `nightly` workflow. `.config/lychee.toml` already sets `max_retries = 6` and lists known-unreliable hosts; one timeout is not enough evidence to extend that list. Signals you have a transient failure, not a broken link:

• The previous run on the same or a nearby commit passed.
• Only `[TIMEOUT]` is reported (not `404`/`403`/`410`).
• The URL is reachable from a local `curl`.

When in doubt, post a comment on the failed run summarizing the diagnosis and wait — don't open a PR.

Applying GitHub Suggestions

Apply the literal suggestion only — change the lines it covers, nothing more. If surrounding lines also need updating, note that in your reply.

PR Review: Don't Self-Dismiss Over Unrelated Test Flakes

If a clearly-unrelated test fails after you've already approved a PR, leave the approval in place and post a comment noting the flake. Do **not** dismiss your own approval to "gate" on a rerun.

GitHub blocks both `gh run rerun --failed` and per-job rerun (`POST /repos/{owner}/{repo}/actions/jobs/{id}/rerun`) with HTTP 403 while *any* job in the same workflow run is still `in_progress`. The non-required `benchmarks` job routinely runs 80+ minutes after `test (linux|macos|windows)` finish, so dismiss-then-wait-then-rerun cascades into a long session for no benefit — the maintainer can rerun the failed job directly once `benchmarks` clears, or merge regardless if the failure is clearly a flake.

The code