Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, GitHub Releases, annotated tags, historical release backfill, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送", "release notes", "GitHub Release", or "回填 Release".
Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, GitHub Releases, annotated tags, historical release backfill, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送", "release notes", "GitHub Release", or "回填 Release".
Release Skills
Universal release workflow supporting any project type with multi-language changelog.
User Input Tools
When this skill prompts the user, follow this tool-selection rule (priority order):
Prefer built-in user-input tools exposed by the current agent runtime — e.g., AskUserQuestion, request_user_input, clarify, ask_user, or any equivalent.
Fallback: if no such tool exists, emit a numbered plain-text message and ask the user to reply with the chosen number/answer for each question.
Batching: if the tool supports multiple questions per call, combine all applicable questions into a single call; if only single-question, ask them one at a time in priority order.
Concrete AskUserQuestion references below are examples — substitute the local equivalent in other runtimes.
Quick Start
Just run /release-skills - auto-detects your project configuration.
Supported Projects
Project Type
Version File
Auto-Detected
Node.js
package.json
✓
Python
pyproject.toml
✓
Rust
Cargo.toml
✓
Claude Plugin
marketplace.json
✓
Generic
VERSION / version.txt
✓
Options
Flag
Description
--dry-run
Preview changes without executing
--major
Force major version bump
--minor
Force minor version bump
--patch
Force patch version bump
--backfill-releases
Create missing GitHub Releases for existing tags from changelog sections
Workflow
Step 1: Detect Project Configuration
Check for .releaserc.yml (optional config override)
If present, inspect whether it defines release hooks
Auto-detect version file by scanning (priority order):
package.json (Node.js)
pyproject.toml (Python)
Cargo.toml (Rust)
marketplace.json or .claude-plugin/marketplace.json (Claude Plugin)
VERSION or version.txt (Generic)
Scan for changelog files using glob patterns:
CHANGELOG*.md
HISTORY*.md
CHANGES*.md
Identify language of each changelog by filename suffix
Detect GitHub release support:
Check whether origin points to GitHub
Check whether gh is installed and authenticated
Check existing releases with gh release list --limit 5 when available
Display detected configuration
Project Hook Contract:
If .releaserc.yml defines release.hooks, keep the release workflow generic and delegate project-specific packaging/publishing to those hooks.
Supported hooks:
Hook
Purpose
Expected Responsibility
prepare_artifact
Make one target releasable
Validate the target is self-contained, sync/embed local dependencies, optionally stage extra files
publish_artifact
Publish one releasable target
Upload the prepared target (or a staged directory if the project uses one), attach version/changelog/tags
Supported placeholders:
Placeholder
Meaning
{project_root}
Absolute path to repository root
{target}
Absolute path to the module/skill being released
{artifact_dir}
Absolute path to a temporary staging directory for this target, when the project uses one
{version}
Version selected by the release workflow
{dry_run}
true or false
{release_notes_file}
Absolute path to a UTF-8 file containing release notes/changelog text
Execution rules:
Keep the skill generic: do not hardcode registry/package-manager/project layout details into this SKILL.
If prepare_artifact exists, run it once per target before publish-related checks that need the final releasable target state.
Write release notes to a temp file and pass that file path to publish_artifact; do not inline multiline changelog text into shell commands.
If hooks are absent, fall back to the default project-agnostic release workflow.
Language Detection Rules:
Changelog files follow the pattern CHANGELOG_{LANG}.md or CHANGELOG.{lang}.md, where {lang} / {LANG} is a language or region code.
Pattern
Example
Language
No suffix
CHANGELOG.md
en (default)
_{LANG} (uppercase)
CHANGELOG_CN.md, CHANGELOG_JP.md
Corresponding language
.{lang} (lowercase)
CHANGELOG.zh.md, CHANGELOG.ja.md
Corresponding language
.{lang-region}
CHANGELOG.zh-CN.md
Corresponding region variant
Common language codes: zh (Chinese), ja (Japanese), ko (Korean), de (German), fr (French), es (Spanish).
Options: "Yes, push after commit", "No, keep local only"
Publish GitHub Release (single select):
Offer this only when GitHub release support is available
Default to "Yes, publish after tag push" when the user also chose push
If the user keeps the release local, do not create or edit a GitHub Release
Example Output Before Confirmation:
Commits created:
1. feat(baoyu-cover-image): add watercolor and minimalist styles
2. fix(baoyu-comic): improve panel layout for long dialogues
3. docs(project): update architecture documentation
Changelog preview (en):
## 1.3.0 - 2026-01-22
### Features
- Add watercolor and minimalist styles to cover-image
### Fixes
- Improve panel layout for long dialogues in comic
Release notes source: CHANGELOG.md#1.3.0
Ready to create release commit, annotated tag, and GitHub Release.
Step 9: Create Release Commit and Annotated Tag
After user confirmation:
Stage version and changelog files:
git add <version-file>
git add CHANGELOG*.md
Create release commit:
git commit -m "chore: release v{VERSION}"
Create annotated tag:
git tag -a v{VERSION} -F <release-notes-file>
If .releaserc.yml sets tag.sign: true, use git tag -s with the same notes file.
Push if user confirmed (Step 8):
git push origin main
git push origin v{VERSION}
Note: Do NOT add Co-Authored-By line. This is a release commit, not a code contribution.
Step 10: Publish Release Artifacts and GitHub Release
Project artifact publishing and GitHub Releases are separate outputs:
Project artifacts:
If release.hooks.publish_artifact exists, run it once per prepared target
Pass the same {release_notes_file} used for the tag and GitHub Release
In dry-run mode, pass {dry_run}=true and report what would be published
GitHub Release:
Run only if the user confirmed remote publishing and GitHub support is available
Ensure the tag exists on the remote before creating the release
Create or update using the extracted notes:
if gh release view v{VERSION} >/dev/null 2>&1; then
gh release edit v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file>
else
gh release create v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file> --verify-tag
fi
Never inline multiline release notes into shell commands
Post-Release Output:
Release v1.3.0 created.
Commits:
1. feat(baoyu-cover-image): add watercolor and minimalist styles
2. fix(baoyu-comic): improve panel layout for long dialogues
3. docs(project): update architecture documentation
4. chore: release v1.3.0
Tag: v1.3.0
Tag type: annotated
GitHub Release: published # or "skipped/local only"
Status: Pushed to origin # or "Local only - run git push when ready"
Backfill Existing GitHub Releases
Use this mode when the user asks to backfill historical releases or passes --backfill-releases.
Do not bump versions, edit changelogs, or create release commits.
List existing tags in version order and detect missing releases:
git tag --sort=v:refname
gh release view <tag>
For each tag without a GitHub Release:
Normalize the changelog lookup by stripping the configured tag prefix, e.g. v1.2.3 -> 1.2.3
Extract the matching section from CHANGELOG.md; fall back to the first matching changelog file
Skip or ask before publishing if no matching changelog section exists
Detect lightweight tags with git cat-file -t <tag> (commit means lightweight, tag means annotated).
Do not rewrite public lightweight tags by default. Converting an existing remote tag to an annotated tag requires explicit user confirmation because it rewrites a published reference.
Configuration (.releaserc.yml)
Optional config file in project root to override defaults:
# .releaserc.yml - Optional configuration# Version file (auto-detected if not specified)version:file:package.jsonpath:$.version# JSONPath for JSON, dotted path for TOML# Changelog files (auto-detected if not specified)changelog:files:-path:CHANGELOG.mdlang:en-path:CHANGELOG.zh.mdlang:zh-path:CHANGELOG.ja.mdlang:ja# Section mapping (conventional commit type → changelog section)# Use null to skip a type in changelogsections:feat:Featuresfix:Fixesdocs:Documentationrefactor:Refactorperf:Performancetest:Testschore:null# Commit message formatcommit:message:"chore: release v{version}"# Tag formattag:prefix:v# Results in v1.0.0sign:false# Additional files to include in release commitinclude:-README.md-package.json
Dry-Run Mode
When --dry-run is specified:
=== DRY RUN MODE ===
Project detected:
Version file: package.json (1.2.3)
Changelogs: CHANGELOG.md (en), CHANGELOG.zh.md (zh)
Last tag: v1.2.3
Proposed version: v1.3.0
Changes grouped by skill/module:
baoyu-cover-image:
- feat: add watercolor style
- feat: add minimalist style
→ Commit: feat(baoyu-cover-image): add watercolor and minimalist styles
→ README updates: options table
baoyu-comic:
- fix: panel layout for long dialogues
→ Commit: fix(baoyu-comic): improve panel layout for long dialogues
→ No README updates
Changelog preview (en):
## 1.3.0 - 2026-01-22
### Features
- Add watercolor and minimalist styles to cover-image
### Fixes
- Improve panel layout for long dialogues in comic
Changelog preview (zh):
## 1.3.0 - 2026-01-22
### 新功能
- 为 cover-image 添加水彩和极简风格
### 修复
- 改进 comic 长对话的面板布局
Commits to create:
1. feat(baoyu-cover-image): add watercolor and minimalist styles
2. fix(baoyu-comic): improve panel layout for long dialogues
3. chore: release v1.3.0
No changes made. Run without --dry-run to execute.
Example Usage
/release-skills # Auto-detect version bump
/release-skills --dry-run # Preview only
/release-skills --minor # Force minor bump
/release-skills --patch # Force patch bump
/release-skills --major # Force major bump (with confirmation)
/release-skills --backfill-releases # Create missing GitHub Releases for existing tags
When to Use
Trigger this skill when user requests:
"release", "发布", "create release", "new version", "新版本"
"bump version", "update version", "更新版本"
"prepare release"
"release notes", "GitHub Release", "回填 Release"
"push to remote" (with uncommitted changes)
Important: If user says "just push" or "直接 push" with uncommitted changes, STILL follow all steps above first.
