How do I install the Release skill?

Run npx skillmds add yoshiko-pg/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. Capability flags: docs only. 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?

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

Release by yoshiko-pg — Agent Skill

Name: Release
Rating: 4.5 (4 reviews)
Author: yoshiko-pg

Release

Execute the difit release workflow when the user says "リリース" or asks to cut a release. Update CHANGELOG Unreleased from commits since latest tag, ask for explicit OK confirmation in Japanese, then release by moving the confirmed Unreleased section verbatim as the exact source of truth.

yoshiko-pg 70534ba 2 files · 2.9 KB Updated Sep 10, 2026

File contents

Release Workflow

Follow this workflow for the current repository.

Prepare changelog draft

Run ./scripts/get-changes-since-tag.sh.
Categorize changes into these sections as needed: Added, Changed, Deprecated, Removed, Fixed, Security, Thanks.
Use script output rules:
- Use GitHub username from script output.
- Exclude yoshiko-pg and renovate[bot] from Thanks.
- Include PR numbers when available.
- Order bullets with PR numbers by ascending PR number within each section, and list multiple PR numbers within a bullet in ascending order.
- Use commit subject and body for categorization.
- Consolidate routine dependency-only updates, including grouped dependency updates, package manager bumps, and ordinary individual dependency bumps, into a single Changed bullet formatted as - Update dependencies (#123 #124 #125); keep a separate bullet only when the dependency change is clearly user-facing beyond routine maintenance.
Write the categorized content into CHANGELOG.md under ## [Unreleased].
Ask for user confirmation in Japanese.

Release after explicit OK

The only allowed CHANGELOG.md edits after OK are:
- insert the new version heading with today's date directly below ## [Unreleased]
- place the captured Unreleased body under that new heading unchanged
- leave ## [Unreleased] empty
- update the bottom compare links for Unreleased and the new version

Run npm version --no-git-tag-version patch.
Move current Unreleased content into a new version section with today's date.
Update bottom links:
- Update Unreleased compare link to new version tag.
- Add compare link for the new version.
Commit CHANGELOG.md and package.json with an English message: chore: release vX.Y.Z.
Create tag vX.Y.Z.
Push main and tags: git push origin main --tags.
If push is rejected by non-fast-forward:
- Run git pull --rebase origin main.
- Retry git push origin main --tags.
Build release notes from the new version section text in CHANGELOG.md.
Create GitHub release on origin:
- gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <notes-file>

Output to user

Respond in Japanese.
Report updated files, created tag, and GitHub release URL.
Mention if any recovery step was required (for example, rebase due to non-fast-forward).

---name: releasedescription: Execute the difit release workflow when the user says "リリース" or asks to cut a release. Update CHANGELOG Unreleased from commits since latest tag, ask for explicit OK confirmation in Japanese, then release by moving the confirmed Unreleased section verbatim as the exact source of truth.---# Release WorkflowFollow this workflow for the current repository.## Prepare changelog draft1. Run `./scripts/get-changes-since-tag.sh`.2. Categorize changes into these sections as needed: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`, `Thanks`.3. Use script output rules: - Use GitHub username from script output. - Exclude `yoshiko-pg` and `renovate[bot]` from `Thanks`. - Include PR numbers when available. - Order bullets with PR numbers by ascending PR number within each section, and list multiple PR numbers within a bullet in ascending order. - Use commit subject and body for categorization. - Consolidate routine dependency-only updates, including grouped dependency updates, package manager bumps, and ordinary individual dependency bumps, into a single `Changed` bullet formatted as `- Update dependencies (#123 #124 #125)`; keep a separate bullet only when the dependency change is clearly user-facing beyond routine maintenance.4. Write the categorized content into `CHANGELOG.md` under `## [Unreleased]`.5. Ask for user confirmation in Japanese.## Release after explicit OK- The only allowed `CHANGELOG.md` edits after OK are: - insert the new version heading with today's date directly below `## [Unreleased]` - place the captured `Unreleased` body under that new heading unchanged - leave `## [Unreleased]` empty - update the bottom compare links for `Unreleased` and the new version1. Run `npm version --no-git-tag-version patch`.2. Move current `Unreleased` content into a new version section with today's date.3. Update bottom links: - Update `Unreleased` compare link to new version tag. - Add compare link for the new version.4. Commit `CHANGELOG.md` and `package.json` with an English message: `chore: release vX.Y.Z`.5. Create tag `vX.Y.Z`.6. Push `main` and tags: `git push origin main --tags`.7. If push is rejected by non-fast-forward: - Run `git pull --rebase origin main`. - Retry `git push origin main --tags`.8. Build release notes from the new version section text in `CHANGELOG.md`.9. Create GitHub release on origin: - `gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <notes-file>`## Output to user- Respond in Japanese.- Report updated files, created tag, and GitHub release URL.- Mention if any recovery step was required (for example, rebase due to non-fast-forward).

Frequently asked questions