I Asked for the Review to Be Written Down. The Lockfile Part Wasn't.

The best line in the best review I've read here was "The lockfile adds or removes no package names, so there are no new dependencies." An agent wrote it in a comment on a Dependabot bump (Dependabot is GitHub's update bot), the lockfile being the file that pins the exact version of every library, including the ones nobody typed. In my last post on it I asked somebody to turn that comment into a script. Five days later, PR #2283 merged. I asked for a script and got a script and a Skill (a packaged set of agent instructions). I'm thrilled. Then I read it.

Until then the repo's merge script (scripts/github/merge-pr.ts, the one agents merge through) refused every Dependabot PR, so a human had to merge them. dependabotBumpRefusal now lets one through, but only if it comes from this repo, touches only package.json and pnpm-lock.yaml, and every changed line of package.json is one library moving to another version within the same major version. A library still below 1.0 gets stricter treatment, since there a minor bump counts as a major: 0.4 to 0.5 is the risky kind of step. I wouldn't have thought of that. The rest of the checklist lives in the Skill, dependabot-sweep: checks green, release notes show nothing breaking for us, no new direct dependency, nothing at 0.x. The merge call itself still sends the PR's latest commit ID, so a push after the review fails the merge instead of sneaking in. I'd admired that too, and it was already there.

The first customer arrived fast. Dependabot opened PR #2285, a patch bump of vitest (the test runner) from 5.0.4 to 5.0.5, at 09:55 UTC, under two minutes after #2283 merged at 09:53. At 10:09:19 an agent session started to run the Skill. It posted its verdict at 10:09:44 and merged at 10:09:54. Its log gives 73 seconds for the whole session. The verdict reads the release notes, finds only bug fixes, and says none of them "touches how we use vitest".

Now the anxious math. The line I admired isn't in the script. The script looks at the lockfile's file name and nothing else. For #2285 that left 24 added and 24 removed lines of pnpm-lock.yaml unread, beside the one pair in package.json that it did parse. Most of those lines are plain: vitest's sibling packages moving to 5.0.5 with it. But a lockfile is exactly where a bump would show a stranger arriving, and nothing mechanical looks. The PR #2283 description says so itself: "The lockfile's contents aren't parsed, so an indirect dependency's major would pass" (an indirect dependency being a library your libraries pull in, which you never typed), leaving it to the gate (the repo's automated checks) and the release-notes review. The Skill's wording is narrower than that comment's too: "no new dependencies" there, no new direct dependency here. So a review that checked everything by hand, once, is now a procedure that checks what the script can see, plus whatever a 73-second read of release notes catches. I'd have clicked the green button on #2285 as well. Is that better, or just faster than me?