Triage Dependabot pull requests by tracing each update upstream

Hiroki Kondo has a Claude Code skill investigate every open Dependabot PR on karasu and recommend merge, hold or reject; three rounds in a week handled 24 npm updates with a human making each call.

Done withClaude CodeinGitHubNPM· Oct 18, 2026

What they did

Hiroki Kondo builds karasu, an architecture modelling language, without writing its code by hand: everything goes through Claude Code. Dependabot PRs are not merged as they arrive. Running a skill from hane, Kondo's own Claude Code plugin, makes the agent collect every open Dependabot PR and trace each one upstream: release notes, the code diff between tags, changes of publisher or repository owner, install-time scripts, lockfile dependency edges, known advisories and how recently the version was published. It writes the findings into a design doc with a merge, hold or reject recommendation per PR, and once Kondo decides, it merges and closes them and turns the doc into an ADR. Repo-specific rules, such as a 7-day cooldown, live in a rules file in karasu.

How it went

Kondo ran three triage rounds in the week of 10 to 17 October; 16 of the 88 PRs merged that week were Dependabot updates. A limit of 8 open Dependabot PRs delivered 24 cleared updates in three waves, each needing its own triage, so the limit went up to 25. In one replacement PR, rebuilding the lockfile moved knip to 6.41.0 instead of the reviewed 6.40.0; Kondo pinned it back and recorded the lesson in an ADR.

Worth knowing

The skill investigates patch releases too, since a tampered patch is an easy supply-chain route, and it never auto-merges. A rebuilt lockfile can quietly pull a version newer than the one reviewed, so check resolved versions after any rebuild.

Try it

With Claude Code· 3 parts to fill in

Triage every open Dependabot pull request in [my repo]. For each one, read the release notes and the code diff between the old and new tags, check for changes of publisher or repository owner, new install scripts, new transitive dependencies in the lockfile, known advisories, and how many days ago the version was published; treat anything newer than [7 days] as on hold. Write the findings to [a design doc path] with a merge, hold or reject recommendation for each PR. Do not merge or close anything: stop and wait for my decisions, then act on them and confirm the resolved versions match the ones reviewed.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related