Guide · Agent skill
How to use the Release Assistant agent skill (release)
Updated · written with AI from the project's own documentation and checked against our catalogue data
The Release Assistant is an agent skill from the oh-my-claudecode project that helps an AI agent cut a software release. The first time you ask it to release, it inspects your repo for version files, CI workflows, test commands, changelog style and publishing setup, then saves those findings to .omc/RELEASE_RULE.md so later releases go faster. This guide explains what the skill does, how to install it, how to trigger it, and what to check before letting it push.
Quick start
- 1Download and unzip the skill. Download the release skill ZIP from this page and unzip it into ~/.claude/skills/ for personal use, or into .claude/skills/ inside your project.
- 2Or upload it in the Claude apps. In the Claude apps, open Settings, go to Capabilities, then Skills, and upload the skill.
- 3Open your repository. Start the agent in the root of the git repository you want to release.
- 4Ask for a release. Say something like "cut a patch release" or run /oh-my-claudecode:release with a version such as patch, minor, major or 2.4.0.
- 5Review the rule file and checklist. Check the generated .omc/RELEASE_RULE.md and the pre-release checklist, then confirm the version.
- 6Confirm the commit, tag and push. Read the plan carefully, since the skill commits, tags and pushes to origin, then confirm.
- 7Verify the release. Check CI status and the registry, and confirm the GitHub Release if the gh tool is available.
What is an agent skill and what does the release skill do?
An agent skill is a folder containing a SKILL.md file that tells an AI agent how to handle a specific kind of task. The agent loads the skill when your request matches it. The release skill (skill name: release) covers the full release workflow for a repository.
On the first run, or when you pass --refresh, the skill analyses the repo and writes its findings to .omc/RELEASE_RULE.md. It then picks a version, runs a pre-release checklist, helps draft release notes, and executes the commit, tag and push steps. After that, CI or a manual publish command handles publishing.
- Finds version strings in files such as package.json, pyproject.toml, Cargo.toml, build.gradle or a VERSION file.
- Checks for release automation such as release-it, semantic-release, changesets, goreleaser or bump2version.
- Identifies how packages are published (npm, PyPI, Cargo, Docker, GitHub Packages) and which CI job does it.
- Reads the test gate, the release trigger, and the changelog convention.
- Flags setup gaps such as no release workflow, no git tags, or build artifacts not in .gitignore.
How do you install the release skill?
You can install the skill in one of two ways. Download the ZIP from this directory page and unzip it into your personal skills folder at ~/.claude/skills/, or into a project's .claude/skills/ folder to share it with one repository.
If you use the Claude apps, you can instead upload the skill under Settings → Capabilities → Skills.
- Personal install: unzip into ~/.claude/skills/ so it is available across your projects.
- Project install: unzip into .claude/skills/ inside the repository.
- Claude apps: upload the skill under Settings → Capabilities → Skills.
How do you trigger the release skill?
You can invoke the skill directly with its command, or describe the release in plain language and let the agent load it. The version argument is optional. If you leave it out, the skill shows the current version and what patch, minor and major would produce, then asks you to choose.
Accepted version values are patch, minor, major, or an explicit semver such as 2.4.0. Add --refresh to force a fresh analysis even when a cached rule file exists.
- Natural request: "Cut a patch release of this project."
- Natural request: "Prepare a minor release and draft the changelog."
- Natural request: "Re-analyse the release rules, the CI workflows changed."
/oh-my-claudecode:release [version]What happens during a release?
The skill works through a fixed sequence. It checks the cached rules and, if workflow files have changed since the last-analyzed timestamp, updates the affected sections and reports what changed. It then asks for the version, shows a pre-release checklist, and waits for your confirmation unless you say to go ahead.
During execution it bumps the version in each version file, runs the test gate, commits the version files and CHANGELOG.md, creates an annotated tag, and pushes the branch and tag. If the release trigger is a tag push, CI takes over. If there is no CI automation, the skill lists the manual publish command for your stack.
- Bump version in every version source file.
- Run the test gate command.
- Commit with a message in the form chore(release): bump version to vX.Y.Z.
- Create an annotated tag vX.Y.Z.
- Push the branch, then push the tag to origin.
- Verify CI status and the registry, and confirm a GitHub Release exists, if the gh tool is available.
git add <version files> CHANGELOG.md
git tag -a vX.Y.Z -m "vX.Y.Z"
git push origin <branch> && git push origin vX.Y.ZHow does the skill help with release notes?
The skill follows the changelog convention it detects in the repo. When none is detected, it uses a default format: user-facing changes first, grouped under New Features, Bug Fixes, Breaking Changes, Deprecations and Internal / Chores. Breaking changes come first and must include a migration path.
If the repo uses Conventional Commits, the skill can draft a changelog from git history between the previous tag and HEAD, group it by commit type, and show it to you to edit.
- Each item is one sentence, linked to its PR or issue, with the author credited if external.
- Refactors, CI tweaks and test-only changes are left out unless they affect build reproducibility.
git log <prev-tag>..HEAD --no-merges --format="%s"What do you need before you start, and what are the safety notes?
You need git, a repository with version files such as package.json, pyproject.toml or Cargo.toml, and push access to the origin remote. The skill runs inside the oh-my-claudecode environment. It runs scripts and uses the network.
The release steps commit, tag and push on your behalf. A wrong tag or push can be hard to undo, so read the plan before you confirm. The skill can also offer to scaffold a release workflow file. Review any generated workflow before you rely on it. The skill is not a fit where releases need sign-off from a formal process.
- Read the version bump, tag name and branch before confirming the push.
- Check that the test gate actually runs and passes.
- Review any CI workflow file the skill proposes before committing it.
- Decide whether .omc/RELEASE_RULE.md should be committed (shared with the team) or added to .gitignore (kept local).
Tips for getting better results
Run the skill once on a repo and read the generated .omc/RELEASE_RULE.md. If it has the wrong test command or publish job, correct the file or ask for a --refresh after fixing the workflows.
For monorepos or multi-package workspaces, the skill says it detects npm, pnpm and Cargo workspace patterns and adapts. Check the version sources it lists before confirming.
- Keep the rule file under review, since it drives later releases.
- Use an explicit version such as 2.4.0 when you already know the number.
- Use --refresh after changing CI workflow files if the delta check misses them.
What people use it for
- Cutting a patch or minor release of an npm package that has a tag-triggered CI publish job.
- Preparing a Python package release by bumping pyproject.toml and listing the manual twine upload command when no CI exists.
- Drafting release notes from commits between the previous tag and HEAD in a Conventional Commits repository.
- Auditing a project that has no git tags or no release workflow, and getting a list of setup gaps.
Frequently asked questions
How do I install the release agent skill?
Download the ZIP from this directory page and unzip it into ~/.claude/skills/ for personal use, or into a project's .claude/skills/ folder. In the Claude apps you can instead upload it under Settings → Capabilities → Skills.
What does the release skill need to run?
It needs git, a repository with version files such as package.json, pyproject.toml or Cargo.toml, and push access to the origin remote for the release steps. It runs inside the oh-my-claudecode environment and runs scripts and uses the network.
Is the release skill free to use?
The source identifies the project's licence as MIT. The source does not mention pricing, so check the project page for any cost details before relying on it.
What is the difference between --refresh and the cached rule file?
On the first run the skill analyses the repo and writes .omc/RELEASE_RULE.md. On later runs it reads that file and only re-analyses changed CI workflows, unless you pass --refresh to force a full re-analysis.
Will the release skill push to my repo without asking?
It asks you to confirm the checklist before proceeding, unless you tell it to go ahead. Because it commits, tags and pushes, review the plan first, since a wrong tag or push can be hard to undo.
Does it work with repos that have no tests or CI?
It can only guide those releases. The source says it may offer to scaffold a CI workflow file, which you should review before using.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
The release skill suits maintainers of npm, PyPI, Cargo or Docker projects who release irregularly and want a checklist, and teams with an existing CI release pipeline. It is a poor fit for projects that need formal sign-off, because it runs git commit, tag and push steps itself. Read the plan before you confirm each release.
Download the skill