🎯

release-skills

🎯Skill

from jimliu/baoyu-skills

VibeIndex|
What it does

Automatically detects and updates version files, changelogs, and git tags across multiple project types with multi-language support and intelligent version bumping.

release-skills

Installation

Install skill:
npx skills add https://github.com/jimliu/baoyu-skills --skill release-skills
1,127
Last UpdatedJan 26, 2026

Skill Details

SKILL.md

Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送".

Overview

# Release Skills

Universal release workflow supporting any project type with multi-language changelog.

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 |

Workflow

Step 1: Detect Project Configuration

  1. Check for .releaserc.yml (optional config override)
  2. 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)

  1. Scan for changelog files using glob patterns:

- CHANGELOG*.md

- HISTORY*.md

- CHANGES*.md

  1. Identify language of each changelog by filename suffix
  2. Display detected configuration

Language Detection Rules:

| Filename Pattern | Language |

|------------------|----------|

| CHANGELOG.md (no suffix) | en (default) |

| CHANGELOG.zh.md / CHANGELOG_CN.md / CHANGELOG.zh-CN.md | zh |

| CHANGELOG.ja.md / CHANGELOG_JP.md | ja |

| CHANGELOG.ko.md / CHANGELOG_KR.md | ko |

| CHANGELOG.de.md / CHANGELOG_DE.md | de |

| CHANGELOG.fr.md / CHANGELOG_FR.md | fr |

| CHANGELOG.es.md / CHANGELOG_ES.md | es |

| CHANGELOG.{lang}.md | Corresponding language code |

Output Example:

```

Project detected:

Version file: package.json (1.2.3)

Changelogs:

- CHANGELOG.md (en)

- CHANGELOG.zh.md (zh)

- CHANGELOG.ja.md (ja)

```

Step 2: Analyze Changes Since Last Tag

```bash

LAST_TAG=$(git tag --sort=-v:refname | head -1)

git log ${LAST_TAG}..HEAD --oneline

git diff ${LAST_TAG}..HEAD --stat

```

Categorize by conventional commit types:

| Type | Description |

|------|-------------|

| feat | New features |

| fix | Bug fixes |

| docs | Documentation |

| refactor | Code refactoring |

| perf | Performance improvements |

| test | Test changes |

| style | Formatting, styling |

| chore | Maintenance (skip in changelog) |

Breaking Change Detection:

  • Commit message starts with BREAKING CHANGE
  • Commit body/footer contains BREAKING CHANGE:
  • Removed public APIs, renamed exports, changed interfaces

If breaking changes detected, warn user: "Breaking changes detected. Consider major version bump (--major flag)."

Step 3: Determine Version Bump

Rules (in priority order):

  1. User flag --major/--minor/--patch → Use specified
  2. BREAKING CHANGE detected → Major bump (1.x.x → 2.0.0)
  3. feat: commits present → Minor bump (1.2.x → 1.3.0)
  4. Otherwise → Patch bump (1.2.3 → 1.2.4)

Display version change: 1.2.3 → 1.3.0

Step 4: Generate Multi-language Changelogs

For each detected changelog file:

  1. Identify language from filename suffix
  2. Generate content in that language:

- Section titles in target language

- Change descriptions written naturally in target language (not translated)

- Date format: YYYY-MM-DD (universal)

  1. Insert at file head (preserve existing content)

Section Title Translations (built-in):

| Type | en | zh | ja | ko | de | fr | es |

|------|----|----|----|----|----|----|-----|

| feat | Features | 新功能 | 新機能 | 새로운 기능 | Funktionen | Fonctionnalités | Características |

| fix | Fixes | 修复 | 修正 | 수정 | Fehlerbehebungen | Corrections | Correcciones |

| docs | Documentation | 文档 | ドキュメント | 문서 | Dokumentation | Documentation | Documentación |

| refactor | Refactor | 重构 | リファクタリング | 리팩토링 | Refactoring | Refactorisation | Refactorización |

| perf | Performance | 性能优化 | パフォーマンス | 성능 | Leistung | Performance | Rendimiento |

| breaking | Breaking Changes | 破坏性变更 | 破壊的変更 | 주요 변경사항 | Breaking Changes | Changements majeurs | Cambios importantes |

Changelog Format:

```markdown

{VERSION} - {YYYY-MM-DD}

Features

  • Description of new feature

Fixes

  • Description of fix

Documentation

  • Description of docs changes

```

Only include sections that have changes. Omit empty sections.

Multi-language Example:

English (CHANGELOG.md):

```markdown

1.3.0 - 2026-01-22

Features

  • Add user authentication module
  • Support OAuth2 login

Fixes

  • Fix memory leak in connection pool

```

Chinese (CHANGELOG.zh.md):

```markdown

1.3.0 - 2026-01-22

新功能

  • 新增用户认证模块
  • 支持 OAuth2 登录

修复

  • 修复连接池内存泄漏问题

```

Japanese (CHANGELOG.ja.md):

```markdown

1.3.0 - 2026-01-22

新機能

  • ユーザー認証モジュールを追加
  • OAuth2 ログインをサポート

修正

  • コネクションプールのメモリリークを修正

```

Step 5: Group Changes by Skill/Module

Analyze commits since last tag and group by affected skill/module:

  1. Identify changed files per commit
  2. Group by skill/module:

- skills//* → Group under that skill

- Root files (CLAUDE.md, etc.) → Group as "project"

- Multiple skills in one commit → Split into multiple groups

  1. For each group, identify related README updates needed

Example Grouping:

```

baoyu-cover-image:

- feat: add new style options

- fix: handle transparent backgrounds

→ README updates: options table

baoyu-comic:

- refactor: improve panel layout algorithm

→ No README updates needed

project:

- docs: update CLAUDE.md architecture section

```

Step 6: Commit Each Skill/Module Separately

For each skill/module group (in order of changes):

  1. Check README updates needed:

- Scan README*.md for mentions of this skill/module

- Verify options/flags documented correctly

- Update usage examples if syntax changed

- Update feature descriptions if behavior changed

  1. Stage and commit:

```bash

git add skills//*

git add README.md README.zh.md # If updated for this skill

git commit -m "(): "

```

  1. Commit message format:

- Use conventional commit format: ():

- : feat, fix, refactor, docs, perf, etc.

- : skill name or "project"

- : Clear, meaningful description of changes

Example Commits:

```bash

git commit -m "feat(baoyu-cover-image): add watercolor and minimalist styles"

git commit -m "fix(baoyu-comic): improve panel layout for long dialogues"

git commit -m "docs(project): update architecture documentation"

```

Common README Updates Needed:

| Change Type | README Section to Check |

|-------------|------------------------|

| New options/flags | Options table, usage examples |

| Renamed options | Options table, usage examples |

| New features | Feature description, examples |

| Breaking changes | Migration notes, deprecation warnings |

| Restructured internals | Architecture section (if exposed to users) |

Step 7: Generate Changelog and Update Version

  1. Generate multi-language changelogs (as described in Step 4)
  2. Update version file:

- Read version file (JSON/TOML/text)

- Update version number

- Write back (preserve formatting)

Version Paths by File Type:

| File | Path |

|------|------|

| package.json | $.version |

| pyproject.toml | project.version |

| Cargo.toml | package.version |

| marketplace.json | $.metadata.version |

| VERSION / version.txt | Direct content |

Step 8: User Confirmation

Before creating the release commit, ask user to confirm:

Use AskUserQuestion with two questions:

  1. Version bump (single select):

- Show recommended version based on Step 3 analysis

- Options: recommended (with label), other semver options

- Example: 1.2.3 → 1.3.0 (Recommended), 1.2.3 → 1.2.4, 1.2.3 → 2.0.0

  1. Push to remote (single select):

- Options: "Yes, push after commit", "No, keep local only"

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

Ready to create release commit and tag.

```

Step 9: Create Release Commit and Tag

After user confirmation:

  1. Stage version and changelog files:

```bash

git add

git add CHANGELOG*.md

```

  1. Create release commit:

```bash

git commit -m "chore: release v{VERSION}"

```

  1. Create tag:

```bash

git tag v{VERSION}

```

  1. Push if user confirmed (Step 8):

```bash

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.

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

Status: Pushed to origin # or "Local only - run git push when ready"

```

Configuration (.releaserc.yml)

Optional config file in project root to override defaults:

```yaml

# .releaserc.yml - Optional configuration

# Version file (auto-detected if not specified)

version:

file: package.json

path: $.version # JSONPath for JSON, dotted path for TOML

# Changelog files (auto-detected if not specified)

changelog:

files:

- path: CHANGELOG.md

lang: en

- path: CHANGELOG.zh.md

lang: zh

- path: CHANGELOG.ja.md

lang: ja

# Section mapping (conventional commit type → changelog section)

# Use null to skip a type in changelog

sections:

feat: Features

fix: Fixes

docs: Documentation

refactor: Refactor

perf: Performance

test: Tests

chore: null

# Commit message format

commit:

message: "chore: release v{version}"

# Tag format

tag:

prefix: v # Results in v1.0.0

sign: false

# Additional files to include in release commit

include:

- 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)

```

When to Use

Trigger this skill when user requests:

  • "release", "发布", "create release", "new version", "新版本"
  • "bump version", "update version", "更新版本"
  • "prepare release"
  • "push to remote" (with uncommitted changes)

Important: If user says "just push" or "直接 push" with uncommitted changes, STILL follow all steps above first.

More from this repository10

🎯
baoyu-slide-deck🎯Skill

Generates professional slide decks automatically from markdown content, transforming written text into visually structured presentation slides.

🎯
baoyu-article-illustrator🎯Skill

Generates illustrations and visual graphics to accompandany and enhance the visual storytelling of a written article, points, automatically creating contextually relevant images that that complem...

🎯
baoyu-cover-image🎯Skill

Generates professional and visually appealing cover images for content, optimized for social media and publishing platforms.

🎯
baoyu-xhs-images🎯Skill

Generates cartoon-style infographic images for Xiaohongshu (RedNote) posts by breaking down markdown content into a series of 1-10 visually engaging graphics with customizable styles and layouts.

🎯
baoyu-comic🎯Skill

Generates comic-style illustrations or comic strips based on text input, likely transforming written content into visual storytelling through sequential art.

🎯
baoyu-post-to-wechat🎯Skill

Publishes content directly to WeChat Official Account platform from Claude Code.

🎯
baoyu-post-to-x🎯Skill

Automatically posts content to X (formerly Twitter) from a specified markdown file or text.

🎯
baoyu-compress-image🎯Skill

Compresses images to reduce file size while maintaining visual quality, optimizing images for web and storage purposes.

🎯
baoyu-danger-gemini-web🎯Skill

Generates web content or web-related artifacts using Google's Gemini AI model with potential experimental or advanced capabilities.

🎯
baoyu-danger-x-to-markdown🎯Skill

Converts dangerous or complex X (Twitter) posts into clean, structured Markdown format for easier reading and processing.