How do I install the Release skill?

Run npx skillmds@latest add dyoshikawa/release in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release?

dyoshikawa (@dyoshikawa) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release by dyoshikawa — Agent Skill

Name: Release
Author: dyoshikawa

File contents

First, let's work on the following steps.

Confirm that you are currently on the main branch. If not on the main branch, abort this operation.
Compare code changes between the previous version tag and the latest commit to prepare the release description.

Write in English.
Do not include confidential information.
Sections What's Changed, Contributors and Full Changelog are needed.
./tmp/release-notes.md will be used as the release notes.

Then, get the requested new version from the user's request without the v prefix and assign it to $new_version. For example, if the request specifies "v1.0.0", the new version is "1.0.0".

Unless the user explicitly specifies the new version, determine $new_version from the release description by applying the general semantic-versioning rules (a breaking change bumps the major, a new feature bumps the minor, and a bug fix bumps the patch).

Let's resume the release process.

Run git pull.
Run git checkout -b release/v${new_version}.
Bump the version in package.json to ${new_version} with pnpm version ${new_version} --no-git-tag-version. The CLI reads its version from package.json, so no other file needs to change.
Run pnpm cicheck. If the checks fail, fix the code until they pass.
Execute git add, git commit and git push.
As a precaution, verify that pnpm dev --version reports ${new_version}.
Run gh pr create targeting the main branch, then gh pr merge --admin --merge to merge the release branch into main.
Create a GitHub release with gh release create v${new_version} --title v${new_version} --notes-file ./tmp/release-notes.md on the github.com/dyoshikawa/ghactivities repository. Creating the release triggers the Release workflow (.github/workflows/release.yml), which builds the project and publishes it to npm.
Wait for the Release workflow to complete successfully. Use gh run list --workflow=Release --limit 1 --json status,conclusion,databaseId to check the status. Poll until the workflow completes (status is "completed"). If it fails, report the failure.
Clean up the branches. Run git checkout main, git branch -D release/v${new_version} and git pull --prune.

---name: releasedescription: Release a new ghactivities version end to end, including version selection, checks, release PR, GitHub release, workflow monitoring, and branch cleanup. Use when asked to publish or perform a production release.---First, let's work on the following steps.1. Confirm that you are currently on the `main` branch. If not on the `main` branch, abort this operation.2. Compare code changes between the previous version tag and the latest commit to prepare the release description.- Write in English.- Do not include confidential information.- Sections `What's Changed`, `Contributors` and `Full Changelog` are needed.- `./tmp/release-notes.md` will be used as the release notes.Then, get the requested new version from the user's request without the `v` prefix and assign it to `$new_version`. For example, if the request specifies "v1.0.0", the new version is "1.0.0".Unless the user explicitly specifies the new version, determine `$new_version` from the release description by applying the general semantic-versioning rules (a breaking change bumps the major, a new feature bumps the minor, and a bug fix bumps the patch).Let's resume the release process.3. Run `git pull`.4. Run `git checkout -b release/v${new_version}`.5. Bump the version in `package.json` to `${new_version}` with `pnpm version ${new_version} --no-git-tag-version`. The CLI reads its version from `package.json`, so no other file needs to change.6. Run `pnpm cicheck`. If the checks fail, fix the code until they pass.7. Execute `git add`, `git commit` and `git push`.8. As a precaution, verify that `pnpm dev --version` reports `${new_version}`.9. Run `gh pr create` targeting the `main` branch, then `gh pr merge --admin --merge` to merge the release branch into `main`.10. Create a GitHub release with `gh release create v${new_version} --title v${new_version} --notes-file ./tmp/release-notes.md` on the `github.com/dyoshikawa/ghactivities` repository. Creating the release triggers the `Release` workflow (`.github/workflows/release.yml`), which builds the project and publishes it to npm.11. Wait for the `Release` workflow to complete successfully. Use `gh run list --workflow=Release --limit 1 --json status,conclusion,databaseId` to check the status. Poll until the workflow completes (status is "completed"). If it fails, report the failure.12. Clean up the branches. Run `git checkout main`, `git branch -D release/v${new_version}` and `git pull --prune`.

Frequently asked questions

Release