agent-glovebox: Skill for Claude Code

Responding to a red check

The doctrine

A red check is a bug you have not diagnosed yet. Treat every failure as real and caused by the change in front of you until a read of the actual log proves otherwise. These dismissals are forbidden as opening assumptions: "infrastructure flake," "timeout," "unrelated," "pre-existing," "already broken on the base branch," "passes on my machine," "only fails on another OS/platform," "load," "transient," "not what I was asked." Each is a conclusion you must earn. "Flaky"/"external" is provable only by reading the log AND demonstrating the root cause is non-deterministic and outside the repo. A timeout/download/racy failure is a real defect (a test too slow or racy under parallelism, a missing retry/backoff), yours to fix at the root.

"Flake" is NEVER a license to ignore, skip, mute, xfail, or merely re-run a failure. Proving something is a flake does not close it, it OBLIGATES a root-cause fix (make the test deterministic, add the missing retry/backoff/timeout budget, pin the unstable input). Even when it is pre-existing and unrelated to your change, fix it in its own fix(test):/fix(ci): commit — "it was already flaky" is not an exemption.

A red that reaches a SECOND round is itself a defect in the red-fixing process. One round closes a red: the round that diagnoses it also pushes its fix, or pushes a branch update (a commit, or one PR-body lead sentence) saying exactly why one round cannot — a fix only CI hardware can validate, an external service down. When a red reaches round two without that recorded reason, first name why round one's response failed — a fix built on an unverified belief about a dependency, a log read that stopped at the symptom, a "flake" left without its root-cause fix — then fix THAT in the same session: sharpen this skill, the babysit-prs skill, or the babysitting code under .github/scripts/, so the class lands first-round.

Deduplicate before you fix, on whatever names the defect — the failing test's exact name, the red check's name, or the file the fix lands in — and search the ISSUE list as well as the PR list, because a multi-PR flake sweep is tracked by an issue and no PR search finds it. mcp__github__search_issues and mcp__github__search_pull_requests, both with owner/repo set and fields: ["number","state","title"] to drop the body and labels. gh pr list --search is GraphQL and 403s in a web session, and the REST search/issues path is blocked there as well, so the MCP tools are the only route that works on both surfaces. An OPEN tracking issue owns the item: add your row to it by EDITING it, and do not file a second issue. Then read the PR state: an OPEN match is the one case you hand back, as one line naming that PR and no fresh investigation; a MERGED one means you re-run the test against current origin/main before touching anything; a CLOSED one covers nothing, so the fix is yours.