agent merged an upgrade at 3am with a red required check because its config didn't mark that check as required
Fixes agents merging over red checks because the required-checks list lived only in the agent's config, not in the repo's branch protection. Use when a merge happened with a failing check. Key trigger: the red check is absent from the branch protection required list.
TL;DR: Mark every safety-gating check as required in the repo's branch protection rule, and make the agent read the required-checks list from the repo instead of its own config. The agent merged because its local config did not list the check - but the repo's required list is the source of truth. Audit branch protection now; the agent's config is advisory, the repo's is law.
agent merged an upgrade at 3am with a red required check because its config didn't mark that check as required- Inspect the branch protection rule for the target branch and list the required status checks. Expected: the red check is NOT in the required list - that is the bug.
- Check the merge commit and which checks were red or pending at merge time. Expected: confirms the agent merged over a failing check.
- Add the check, plus every other safety-gating check, to the required list. Expected: the required list now covers tests, security scan, and upgrade verification.
- Change the agent to query required checks from the repo before merging, and to refuse the merge if any required check is red or pending. Expected: a dry run shows the agent blocking on a red required check.
- Backfill: assess what the red check was protecting against and remediate if the merged upgrade is bad. Expected: the off-hours merge is either validated or reverted.
Use this when
- An agent merged over a red or pending check
- Required checks are configured in the agent but not in the repo
- You need merge-gate hygiene for automated merges
- An off-hours merge slipped past a failing gate
Not for this skill when
- The check is legitimately informational (linters, coverage deltas)
- A human overrode with a recorded justification - that is a process decision
- The check is flaky - fix the flake, different skill
Variant phrasings
- Agent merged with failing check
- Required check not enforced
- Merged PR with red CI
- Agent's required list disagreed with the repo's
Why it happens
There were two sources of truth for "required": the agent's config file and the repo's branch protection rule. The agent consulted only its own, which was missing the check, so its merge precondition passed. The hosting platform would have blocked the merge if the check had been marked required there - the agent got through via a path (elevated permissions or a misconfigured rule) that did not enforce it.
Edge cases
- Matrix job names change per run - the required list needs prefix matching, not exact names
- Required checks do not apply to admins unless "include administrators" is set - set it
- The agent's credentials must not carry bypass permission, or the gate does not apply to it either
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_lXVRdMjKb9k-hc5BYnfBeA
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.