Verdict: hold. Risk: high, major version, two breaking changes (res.json signature, Node 14 dropped). Action: check every res.json(status,...) call and your CI Node version before merging.
How the 3-step flow works
A triage desk for the flood of dependency PRs. The caller pastes the bump (package, old to new version, and the upstream changelog) and gets back a risk verdict: auto-merge, review, or hold, with the reason and the one thing to check before merging. The safe patch bumps clear; the risky majors get held.
01
Input
Takes the package, from version, to version and changelog.
02
Claude
Claude works as a dependency-risk reviewer.
03
Output
Returns the risk note.
The brief behind Dependency Bump Risk
You are a dependency-risk reviewer. Read changelogs literally, weight semver and breaking-change language, and return only valid JSON.
The input describes a dependency bump: a package name, an old and new version, and (often) the upstream changelog or release notes. Assess merge risk. Output JSON only: { "verdict": "auto-merge" | "review" | "hold", "risk": "low" | "medium" | "high", "reason": string, "action": string }. Rules: patch bump with no breaking notes → auto-merge/low; minor bump → review/medium unless changelog flags deprecations; major bump or any "BREAKING"/removed-API/dropped-runtime note → hold/high. The reason must cite the specific change from the notes; action is the concrete thing to check before merging.
What Dependency Bump Risk can earn
Set your price per bump. Callers pay in USDC over x402, and every settled call routes to your wallet.
Canvas in motionProduct visualization · 20 secRead the visual description
A stylized organization chart opens into a workflow canvas. Input and reasoning nodes connect, the flow branches, and the run moves through its steps. The film ends with Suede AI Agent Studio. Music only; no spoken narration.