Release Skills

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

Options

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:

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

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:

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. Detect third-party contributors:

• Check merge commits: git log ${LAST_TAG}..HEAD --merges --pretty=format:"%H %s"
• For each merged PR, identify the PR author via gh pr view <number> --json author --jq '.author.login'
• Compare against repo owner (gh repo view --json owner --jq '.owner.login')
• If PR author ≠ repo owner → third-party contributor

1. 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)
• Third-party contributions: Append contributor attribution (by @username) to the changelog entry

1. Insert at file head (preserve existing content)

Section Title Translations (built-in):

Changelog Format:

## {VERSION} - {YYYY-MM-DD}

### Features
- Description of new feature
- Description of third-party contribution (by @username)

### Fixes
- Description of fix

### Documentation
- Description of docs changes

Only include sections that have changes. Omit empty sections.

Third-Party Attribution Rules:

• Only add (by @username) for contributors who are NOT the repo owner
• Use GitHub username with @ prefix
• Place at the end of the changelog entry line
• Apply to all languages consistently (always use (by @username) format, not translated)

Multi-language Example:

English (CHANGELOG.md):

## 1.3.0 - 2026-01-22

### Features
- Add user authentication module (by @contributor1)
- Support OAuth2 login

### Fixes
- Fix memory leak in connection pool

Chinese (CHANGELOG.zh.md):

## 1.3.0 - 2026-01-22

### 新功能
- 新增用户认证模块 (by @contributor1)
- 支持 OAuth2 登录

### 修复
- 修复连接池内存泄漏问题

Japanese (CHANGELOG.ja.md):

## 1.3.0 - 2026-01-22

### 新機能
- ユーザー認証モジュールを追加 (by @contributor1)
- 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/<skill-name>/* → 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:

canghe-cover-image:
  - feat: add new style options
  - fix: handle transparent backgrounds
  → README updates: options table

canghe-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/<skill-name>/* git add README.md README.zh.md # If updated for this skill git commit -m "<type>(<skill-name>): <meaningful description>" ``

1. Commit message format:

• Use conventional commit format: <type>(<scope>): <description>
• <type>: feat, fix, refactor, docs, perf, etc.
• <scope>: skill name or "project"
• <description>: Clear, meaningful description of changes

Example Commits:

git commit -m "feat(canghe-cover-image): add watercolor and minimalist styles"
git commit -m "fix(canghe-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) |