Best release and upgrade skills for AI agents

Shipping a change is the part of the job an agent gets confidently wrong. Ask it to upgrade a dependency and cut a release, and it will perform the shape of the work: edit the version string, run whatever test command it can find, commit, tag, push. Every step is real. The release still breaks — because the checks that run on your machine are not the checks that run in the pipeline, and nothing in the repository tells an agent where the two diverge.

That divergence is what the skills worth installing are actually about. None of them are teaching semantic versioning; your agent already knows that. What they encode is the asymmetry: a checksum your own machine never verifies because it doesn't need to, a lint run that CI only performs on the tip of a branch, a file copy that kills a binary before it executes a single line. Each one fails somewhere nobody was looking: the first on a CI runner, the second in a git history that looks fine right up until the day you bisect it, the third on your own machine, silently, with no output at all.

Top picks

skill	publisher	license	verdict	updated
helmor-bump-vendors	dohooo	Apache-2.0	Best model for a pinned-dependency bump	2026-07
anthropic-sdk-upgrader	microsoft	MIT	Best model for an SDK upgrade	2026-07
check-sdk-updates	tony1223	MIT	Read-only pre-check; stops before installing	2026-07
cargo-release	bobmatnyc	MIT	Best release protocol for Rust crates	2026-07
release-app	K9i-0	MIT	Best tag-triggered app release	2026-07
tdd	frankify-app	MIT	The enforceable version of test-first	2026-07
Test-Driven Development (TDD)	obra	MIT	The argument, without the machinery	2025-10
worktrunk	jjmartres	MIT	Clearest parallel-agent setup; one gap	2026-04
Worktrunk	max-sixty	NOASSERTION	The copy that documents the approval gate	2026-07

Bump the version in both places: helmor-bump-vendors

helmor-bump-vendors treats a version bump as a change-set rather than an edit. It sorts every bundled tool into a class — plain npm dependency, npm-distributed binary, binary pulled from a GitHub release — and each class tells you which files you touch and whether a checksum table needs a new entry. It also refuses to let the agent name a target version from memory: check the registry live, because a tag can be promoted from prerelease to stable within hours.

The detail that earns it the spot is the cross-architecture rule. Both architectures' checksums are mandatory, because a build on a native-architecture host uses the installed package directly and never verifies the hash — so a wrong entry sails through locally and only detonates on the cross-building CI runner. The skill is written against one repository's file layout, so expect to translate paths. The discipline transfers intact.

Diff the types, not the version number: anthropic-sdk-upgrader

anthropic-sdk-upgrader does the thing almost no upgrade instruction does: it snapshots the installed type declarations to a temp directory before the install, then diffs them afterwards and sorts the result into new exports, new parameters, changed signatures, removals, and fresh deprecations. Then it greps the codebase for each affected API. Compilation errors are the easy half of an SDK upgrade; this is the other half — the parameter that quietly became optional, the method that gained an overload.

The ordering is the trap. Take the snapshot after the install and you are diffing a package against itself, getting a clean report and a false sense of safety. Caveats: it names one project's files as the places type errors land, and it stops at fixing errors and writing a detailed commit message. Pair it with check-sdk-updates, which reads the registry, counts how many versions you skipped, and hands you the install command without running it.

The release step that isn't in your release script: cargo-release

cargo-release is a stop-on-failure sequence: bump, propagate the new version to every dependent crate's pin, then tests, clippy, formatting, commit, tag, push, publish in dependency order — waiting for the registry index to catch up before publishing anything that depends on what you just pushed.

Then it spends a whole section on something no release script of mine ever had. Never copy a freshly built binary over the one already on your PATH on macOS: the kernel caches code-signing identity by hash, so the next invocation is killed before it runs, printing nothing. It looks exactly like an out-of-memory kill and is completely unrelated. Install through the package manager, which writes and renames atomically. Two caveats: the crate names are one monorepo's, and the front matter marks it non-invocable — you are reading a protocol, not calling a command.

Test-first you can actually enforce: frankify-app's tdd

Most test-first instructions are exhortation. tdd is a commit protocol. One behavior becomes a RED commit that touches only test files, then a GREEN commit with the implementation. Because a RED commit still has to pass lint and type checks, there's a sanctioned exception: when the new test calls a function that doesn't exist, you first land a signature-only stub commit with no logic in it. The marker table is honest about how far that goes: Python, vitest and jest get strict expected-failure markers, so a "failing" test that actually passes fails the suite instead of sneaking through. Go and Rust only enforce in aggregate — a dedicated job runs the marked tests and expects failure, but its exit code can't tell two red tests from one red and one wrongly passing — and any other language commits unmarked, with a note to the human that the repository has no red enforcement at all.

It ships a script to check that structure, and it is candid about the limit: hooks verify the shape of your commits, not that you watched the test fail for the right reason. It also names the two upstream skills it was merged from, citing one of them as obra's test-driven-development in a repository called superpowers; obra's copy here is Test-Driven Development (TDD), published from superpowers-skills, and it is the better read if you want the argument against testing after the fact rather than the machinery. The protocol is heavy, and heaviest in exactly the languages whose markers are weakest.

Let the tag do the shipping: release-app

release-app opens by asking two questions instead of guessing: which bump, with the recommendation derived from the commit types since the last tag, and which platforms. Then changelog, version bump, and — the part worth stealing — it runs the pipeline's own static analysis and test commands locally and refuses to proceed if either fails. Only then does it tag. Tags are per-platform, so pushing one starts exactly one workflow.

It also tells the agent how to wait: poll the runs every few minutes rather than streaming logs, because a signed, notarized, store-bound build takes a while and the output is enormous. Caveats worth knowing before you install: the instructions are written in Japanese, and the workflows, signing setup and store steps are one project's. The pattern — run CI's checks before you create the tag that triggers CI — is universal.

Parallel branches, minus one gate: worktrunk

worktrunk is the cleanest short guide to running several agents at once, each in its own worktree: create-and-switch in one command, launch the agent inside the new tree, read status markers from the listing, then merge and clean up. The hook table is the useful part — a pre-merge hook is a local CI gate, and a template filter derives a stable port from the branch name so three dev servers don't fight over one.

What it does not mention is the gate you will hit first. As documented in the Worktrunk skill published in the tool's own repository, the CLI will not execute a project's hooks until the user has reviewed and approved them, and an agent running non-interactively simply stops there. That copy is explicit that approving arbitrary shell commands from a freshly cloned repository is the user's decision, not the agent's, and that the skip-prompts flag exists for pipelines rather than as a way to silence the prompt. Install the guide, and go in knowing the gate is there.

How do you tell two skills with the same name apart?

You can't, from the name. Skill names aren't namespaced, so the same name routinely covers different documents — occasionally different tools entirely. The publisher and the body are a skill's identity; the name only tells you the topic.

Here's the check, using a real case. A skill called ultraqa runs the same loop in either copy: run the gate, diagnose, fix, repeat, with the same exit conditions. Yeachan-Heo's ultraqa explains how to anchor its state file across a multi-repository workspace — a marker file at the parent directory, with a documented resolution order behind it — and invokes its diagnosis and fix agents by their fully-qualified plugin names. zereight's ultraqa is a one-page version of the same workflow that refers to those agents by bare handles — which resolves only if you already happen to have agents by those names installed. Neither document is wrong. Only one is self-contained.

So: open the body before you install. Look for what it writes to disk, what it shells out to, and what it assumes you already have. A skill that names its dependencies is telling you the truth about its cost; one that doesn't will find out on your machine.

What to check before you hand a release skill to an agent

Three things, in order.

License. A permissive license is what lets you fork the skill and rewrite the paths — and you will be rewriting paths, since every good release skill is specific to a repository. Run that check against the table above and one row fails it. The Worktrunk copy from the tool's own repository shows NOASSERTION: its own front matter declares a permissive dual license, but the metadata on its page doesn't confirm it, and the metadata is what you have. That gap is precisely what the check exists to surface.

Where it stops. The strongest ones stop before the irreversible step: the SDK checker reports and suggests but does not install; the Rust protocol tags only after the gates are green; the app release asks before it bumps. A skill that runs a publish command without a gate in front of it is a liability, no matter how well written.

What it assumes about your CI. That's where the local/remote asymmetry lives: which checks CI runs that you don't, and which checks you run that CI silently skips.

What to install

The failure you started with — a change that is green locally and broken in the pipeline — is not a discipline problem. It is missing knowledge, and it is exactly the knowledge these skills contain. For dependency and SDK work, take helmor-bump-vendors for the change-set discipline and anthropic-sdk-upgrader for the type-surface diff, with check-sdk-updates in front as the read-only pass. For cutting the release itself, cargo-release if you publish crates, release-app if you ship an app behind per-platform tags. Put frankify-app's tdd underneath both if you want the gate to be verifiable rather than aspirational, and worktrunk if several of these are running at once — with the hook-approval gate in mind before you point an agent at it.

None of that makes a bad release impossible. It makes the specific bad releases described above impossible, which is the whole trade: someone already lost the afternoon to a stale signing cache and wrote it down, so your agent doesn't have to.