Release cut

Skill zakelfassi/skills-driven-development/examples/cli-tool/skills/release-cut

Agents that learn by doing — and remember how they did it. A methodology for AI agents to create, evolve, and share reusable skills.

Install

npx -y skills add zakelfassi/skills-driven-development --skill release-cut

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

17 stars17 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Cut a versioned release for shipctl — bump the version, generate a changelog from conventional commits, create and push the git tag, and draft a GitHub release with cross-compiled binaries attached. Use when preparing a new release, when asked to "cut a release", or when the version needs bumping after a sprint.

SKILL.md

3.5 KB, as published. Nobody here has run it

Release Cut

Bump the version, generate a changelog, tag, and publish a GitHub release for shipctl.

Inputs

Target version (semver, e.g. 1.2.0 or patch/minor/major)
Release channel (defaults to stable; pre for release candidates)
Skip binary attach? (boolean, defaults to false)

Steps

Verify the working tree is clean
```
git status --porcelain
```
If dirty, commit or stash before proceeding.
Run the full test suite
```
cargo test --workspace
```
Abort if any test fails.
Run the breaking-change audit (invoke the breaking-change-audit skill) Confirms no accidental public-interface regressions before tagging.

Bump the version

# For Rust:
cargo set-version {version}   # or edit Cargo.toml manually
# For Go:
# Update version constant in cmd/root.go

Commit the version bump:

git commit -am "chore(release): bump version to {version}"

Generate the changelog
```
scripts/release-cut.sh --changelog-only {version}
```
Review CHANGELOG.md — edit entries if the generated text is unclear. Commit: git commit -am "docs(changelog): {version} release notes"

Create and push the tag

git tag -a "v{version}" -m "Release v{version}"
git push origin "v{version}"

Trigger cross-compile and attach binaries The CI matrix builds all registered target triples (see cross-compile-matrix skill). Wait for the release workflow to complete:
```
gh run watch --exit-status
```

Draft the GitHub release

gh release create "v{version}" \
  --title "v{version}" \
  --notes-file CHANGELOG.md \
  --draft

Review the draft, then publish:

gh release edit "v{version}" --draft=false

Announce (if applicable) Post in the team channel: title, key changes, install command:
```
cargo install shipctl --version {version}
```

Conventions

Version tags always use the v prefix: v1.2.0, not 1.2.0
Changelog entries follow the Keep a Changelog format (Added / Changed / Deprecated / Removed / Fixed / Security)
Release candidates are tagged v1.2.0-rc.1
Binary naming: shipctl-{version}-{target}.tar.gz
Dry-run: scripts/release-cut.sh --dry-run {version} prints the plan without side effects

Edge Cases

Tag already exists: Delete the local tag, investigate what was released, never force-push a tag that CI has already processed.
Changelog is empty: Check that commits follow conventional format (feat:, fix:, etc.); if the log is legitimately empty, write a manual entry.
Binary attach fails: Re-run gh release upload "v{version}" dist/*.tar.gz; check that the CI artifact paths match what the release workflow uploads.
Yanked release: Use gh release delete "v{version}" + git push origin --delete "v{version}"; never publish a replacement under the same tag.