Checking CI in libxmtp

Raw CI output is the most expensive thing an agent can read. A single unfiltered job log is 10-12k tokens, and every token stays in context for the rest of the session. Use these recipes instead.

Status of a PR

dev/nix-shell 'just ci-status 4096'

Failures first with job URLs, then one summary line:

FAILED:
  test-node-sdk / Test (node-sdk) shard 2  https://github.com/.../job/103436317046
RUNNING: 1 job(s)
SUMMARY: 38 ok, 3 failed, 6 skipped, 1 running

Duplicates are collapsed to the latest attempt per job, so a re-run does not show up twice.

Why a job failed

Take the job id from the ci-status URL:

dev/nix-shell 'just ci-failures 103436317046'

Returns only failure markers - test names, assertions, panics, rustc errors, the failing recipe. Works for Rust and JS jobs. Typically 5-10 lines.

If the job records annotations, they are cheaper still and include file and line:

dev/nix-shell 'just ci-annotations 103435038571'

Run timing and specific log lines

dev/ci/metrics measures runs: wall time, runner minutes by runner class, the slowest steps, and the change class. For a merge run it also says whether the PR's last run tested the same tree and whether the test outputs were fetched.

dev/nix-shell 'python3.11 -B dev/ci/metrics runs --branch main --event push --limit 5'
dev/nix-shell "python3.11 -B dev/ci/metrics marker 115531426546 'will be fetched'"

marker prints only the log lines that match the pattern.

Waiting

Block. Do not poll.

gh run watch <run-id> --exit-status

A sleep-and-recheck loop costs one full-context model call per tick. In the 2026-09-10 session, 286 such polls consumed roughly 37M input tokens, and 40-65% of what they returned was unchanged "queued" or "in progress" text.

If you must loop, back off: 60s, then 120s, then 300s.

Rules

• Never run gh api .../logs without a filter. That is the 10-12k token read these recipes exist to replace.
• Never open a browser for CI. Everything is in gh; the Blacksmith UI shows nothing just ci-annotations does not.
• Check the plan's ## Findings section before investigating a failure. This test is flaky here and has been re-diagnosed several times by different agents: testCanStreamGroupMessages.
• Record the verdict in ## Findings when you finish, so the next agent does not repeat the work.
• "Re-run failed jobs" tests the same old merge commit again. When the fix landed on the base branch after that commit, rebase the PR branch and push. Do not re-run.
• Under gh stack, each PR's checks run on a merge commit that contains the trunk and every PR below it. github.base_ref is the trunk, and GITHUB_BASE_REF is empty inside a reusable workflow. A script that must compare a PR with its own base uses the merge commit's first parent (HEAD^1). Test it on refs/pull/<n>/merge before you push.